这是一个创建于 2164 天前的主题，其中的信息可能已经有所发展或是发生改变。
基本上一首歌评论数越多，代表越火，相应的歌也越好听（并非绝对，大体上符合），然而每次私人 FM 看到评论数"999+"、"1W+"，完全不知道真实评论数，我就不知道你们这样设计到底是出于什么目的？多一个 if else 判断数量会让 APP 运行更流畅？“9427”条评论和"999+"条评论，多 1 位数能多占多大空间？就溢出屏幕了？
 | 1 pakro888 2020 年 5 月 20 日 电脑上直接就可以看到具体评论数，手机上点击评论也会在上方显示实际评论数。 |
| 2 pakro888 2020 年 5 月 20 日 @pakro888 #1 一不小心发出去了。 显示 999+和 1w+应该是为了美观然后降低美工工作量吧。毕竟直接在评论图标上显示实际评论数可能会很丑。如果想看实际的点击去不就好了。999+已经能够让你对这首歌火爆程度有个初步判断了。 |
 | 3 wellsc 2020 年 5 月 20 日  7 这属于产品设计问题，不属于技术实现问题吧 |
 | 4 xiexingjia 2020 年 5 月 20 日 大概 999+ 或 1W+ 从缓存获取。 |
 | 5 sprite82 2020 年 5 月 20 日 via Android 这和开发者无关，都是产品和美工决定的 |
 | 6 U7Q5tLAex2FI0o0g 2020 年 5 月 20 日 这应该是产品决定的，跟技术无关 |
 | 7 janda 2020 年 5 月 20 日 要么就都出现：1k+、2k+、1w+、2w+ 满了一个基数就累加、如：1000 （自定义） 这个也不用每首歌每次评论都计算一下、用定时的方法就行了！ 具体点开：1k+ 这样的就显示下面这个具体数字 就不会出现这种当个了吧：9343 、2343 什么的！ 这种是每评论一次就计算一次、尤其是网易云这么大的数据量、 没必要浪费这个计算吧！ 非网易云相关工作人员，只是说下我的想法，纯个人建议！勿喷 |
 | 8 JerryCha 2020 年 5 月 20 日  11 那么 1145141919810 要怎么显示呢 |
 | 9 Chihaya0824 PRO @JerryCha 太臭了草 |
 | 10 zsdroid 2020 年 5 月 20 日 5 999+表示很多，一个用户只要知道很多就行了啊。你要知道具体的真实评论数干嘛？爬虫吗？ 再说了，就算显示“9427”条评论也会有人出来指责为什么不显示成"999+"。 |
 | 11 wvitas 2020 年 5 月 20 日 数字太多主要不好展示，反正都是解析成字符串，你再多都不会溢出 |
 | 12 reus 2020 年 5 月 20 日 别用啊，唧唧歪歪。 |
 | 13 delectate 2020 年 5 月 20 日 这东西就是蠢，蠢透了。自以为好看，实际上蠢到家。 就像几秒前，几分钟前，几小时前，还有一周前，具体哪天的根本不知道（还见过 “两天 s ago” 这种用法，服了服了）。 对，我说的就是薇信。 |
 | 14 Takuron 2020 年 5 月 20 日 via Android 因为这个评论数不是告诉你你还有多少评论没看，而是表示歌曲的热度，这样的话数量级才是最好选择 |
 | 15 FaustinaD 2020 年 5 月 20 日 via iPhone 2 抖音也是这样的设计啊，产品经理出于视觉效果的考量而已，不然上百万的评论你要怎么在歌曲播放页面显示？ 2582349 吗？直接撑破页面？ |
16 fxy739371 2020 年 5 月 20 日 11 不用就滚 |
 | 17 ByteRan 2020 年 5 月 20 日 中文显示多好，参考游戏里面各种上亿伤害的显示 1 亿 2 千 |
 | 18 speculatorA 2020 年 5 月 20 日 @delectate 《我是写代码的但我干的过腾讯的产品经理和交互设计师》 |
 | 19 stoneabc 2020 年 5 月 20 日 8 典型程序员思维。 显示完整数字丑的要死。 |
 | 20 xingshu1990 2020 年 5 月 20 日 这个准确来说 应该要怼产品经理，比如界面按钮大一点，还是小一点，评论人数展现多少，以什么方式展示，都是产品经理把控的。比如 999 和 1024520，网易云初期，一些文艺小年轻，就是想要在网易云的评论里 找到拥有共同语言的网络朋友，999+已经表示很多，我点开评论，查看里面的前 10 个评论 前 100 个评论，然后小心翼翼的回复一个个评论，内心有一个小心动。1024520 是什么鬼？ 101010011100101 更是什么鬼？ |
 | 21 icyalala 2020 年 5 月 20 日 完整数字太大的话，数量级就不能一眼看出来啊。。 不过我觉得多保留几位更好一些。。 |
 | 22 Juszoe 2020 年 5 月 20 日 完整大数字不好看，我站 999+党 |
 | 23 < href="/member/liuzhaowei55" class="dark">liuzhaowei55 2020 年 5 月 20 日 我觉得这样挺好的，方便阅读。 |
 | 24 Lin0936 2020 年 5 月 20 日 15 可能害怕出现 8964 这种数字 |
 | 25 binjoo 2020 年 5 月 20 日 1 有时候根本不需要知道具体的时间，比如我现在看到你的这个回复，写着 32 分钟前。 一幕了然的知道是半小时前写的。。。 如果写着 2020-05-20 10:50:xx，我还要看下自己的时间，才能知道是多久写的。。 所以这种 xx 前 的方式，因人而异吧，我觉得挺好的。 |
 | 26 oubfgiar 2020 年 5 月 20 日 via iPhone 我基本不怎么看评论数，有好多我收藏的歌，都仅有几十或几百的评价，但这不影响我听歌，也不影响这些歌是经典的事实。就像唐朝的《童年》、《你的幻境》。 |
 | 27 hbolive 2020 年 5 月 20 日 其实这个具体数值不重要，重要的是体现量级就行了。。999+表示这歌人气还行，1W+表示这歌很火。 至于具体 3523 还是 7635，没啥实际意义（至少对我如此）。。 |
 | 28 taaaang 2020 年 5 月 20 日 产品设计而已，一大串数字真的好看？ |
 | 29 zhangchioulin 2020 年 5 月 20 日 也有可能是“安全”原因 |
 | 30 ChillyPrince 2020 年 5 月 20 日 我觉得知乎的赞数设计的挺好的，1.2k 、14k，不那么精确也不那么模糊 |
 | 31 Spaike 2020 年 5 月 20 日 你得说一下，自己想看具体数字的核心诉求是什么，回头想想好像没什么需要看数字？ 手机上排版优先，点赞数量不阶梯显示的话，手机页面都排不下，比如 999+和 10398349，这样长度的数字要挤走评论按钮还是头像，具体显示 10398349 、10398350 又有什么区别？ |
 | 32 kop1989 2020 年 5 月 20 日 这个就是 ui 设计上的考量。跟技术没任何关系。 大概意图是减少同一个页面大脑需要处理的信息量。 10832 和 1w+或者 999+相比，肯定是后者给大脑带来的负担更小。显得界面更精致、轻盈。 反例就是过去的 pc 炒股软件，大智慧、同花顺啥的。 |
 | 36 cjpjxjx 2020 年 5 月 20 日 via iPhone 不然怎么骗你点进去 |
 | 37 letking 2020 年 5 月 20 日 via Android 3 9746 要不要完整展示？ 643443 要不要完整展示？ 27546334 要不要完整展示？ 你觉得缩略显示的分界点应该在哪？什么不该缩略？你以为别的 app 都跟你博客一样两三个评论？ |
 | 38 asvencoop 2020 年 5 月 20 日 via Android 这个不是实现问题，是设计问题 我个人觉得设计很合理啊，一般看到 999 ＋，我下意识会觉得这首歌有点，然后有想点进去看评论的冲动。 |
 | 39 ryh 2020 年 5 月 20 日 过多位的数字确实没有精确显示的意义， 您知道了精确数字又有什么用呢 |
 | 40 HansLee 2020 年 5 月 20 日 我不太理解时刻知道具体评论数有什么意义；既然你提到了开发者， 那你留意过 GitHub 的 star count 是怎么的设计的吗？ |
 | 41 ww940521 2020 年 5 月 20 日 如果有 146248614878234 条评论你是不是还要花一段时间数一下位数。 |
 | 42 xiangR 2020 年 5 月 20 日 只是一个产品规范而已，没有必要去追究细节。 很多东西做都可以做，只是不想做成某个样子。 |
 | 43 Attenuation 2020 年 5 月 20 日 2 还有网易云因为安卓版为何注册 scheme 给我注册所有的 http 和 https???? |
 | 44 omph 2020 年 5 月 20 日 小众需求，不怪网易 |
 | 45 kiroter 2020 年 5 月 20 日 数字长， 废脑， 还要去数多少位。 然后大多数并关心具体数字。知道了又有个 p 用啊。 知道个大概就行了。 |
 | 46 qsmd42 2020 年 5 月 20 日 via iPhone 楼主认为网易云音乐这个体量的产品细节是“开发者”决定的。。。我还以为这里是程序员论坛呢 |
 | 47 ShundL 2020 年 5 月 20 日 因为你听歌根本不用在意它的评论数是 996 条还是 997 条 |
 | 48 raistlin916 2020 年 5 月 20 日 当然是骗你进去看到底是多少评论，设计很鸡贼 |
 | 49 Cielsky 2020 年 5 月 20 日 听歌的会在意评论数吗？ 可以对这首歌的火爆程度有个大致的了解就好了 真显示一串数字，不说美观问题了，用户还得数数这有几个数，到哪一位 |
 | 50 wa143825 2020 年 5 月 20 日 具体数字有视觉负担吧 |
 | 52 libasten 2020 年 5 月 20 日 这是美工设计的问题吧，我觉得挺好的，上面很多朋友也说了，数字很长的话，布局方面又要动心思了，只有 100 多个评论的 123 这样的和 100 万的 1234567 显示宽度明显有差异，界面想要好看，得花点心思，而且位数多了，用户也会晕。 |
 | 53 real3cho 2020 年 5 月 20 日 所有题主能拿出解决在 badge 上显示大数字而不破坏布局的好方案吗？ |
 | 54 FringJX 2020 年 5 月 20 日 这是布局优化，动态数字长度是不能控制的，会导致布局变化。 |
 | 55 CoderGeek 2020 年 5 月 20 日 布局考虑 |
| 56 wa143825 2020 年 5 月 20 日 不会是布局考虑，布局只需要控制超出多少位才显示多少＋ |
 | 57 sweat89 2020 年 5 月 20 日 3 楼说的对，产品设计问题 |
 | 58 Still4 2020 年 5 月 20 日 过多的信息等于没有信息 |
 | 59 skylancer 2020 年 5 月 20 日 我觉得要是卤煮做产品，出来的十有八九是个屑... |
| 60 4263Ad06Awk3b1Do 2020 年 5 月 20 日 恕我直言，网易云的问题实在太多 999 这个根本排不上号的 |
 | 61 zooo 2020 年 5 月 20 日 用户只关心大概的评价数吧 99+ 其实够了 qq 群也显示 99+ |
 | 62 HeiGc 2020 年 5 月 20 日 有人喜欢有人讨厌，这种问题我觉得没有绝对 |
 | 63 soulmt 2020 年 5 月 20 日 999+ 给够了用户想想的空间，就觉得挺火的这东西， 但是如果每一条都是 1001 3405 用户就更关心数字，也可能会觉得 1001 的好垃圾，但是都磨平的话，你就不会在乎具体是多少。 |
 | 64 crz 2020 年 5 月 20 日 科学记数法吧 __1 _12 123 1e3 9e9 |
 | 65 XanderChen 2020 年 5 月 20 日 简略的格式更易于阅读以及统一的整体布局， 说句不好听的，具体的数字和你也无关，你不用关心具体是多少。 |
 | 66 dioxide 2020 年 5 月 20 日 我好奇地不是这个, 而是网易是如何将 Mac 版客户端做到那么卡的? PPT 级的动画体验, 界面响应速度慢到我忘了曾经点过某个按钮. 希望网易能分享如何做到极致地负优化. |
 | 67 secretman 2020 年 5 月 20 日 一看就是非 APP 开发，没做过就不知道这样处理的好处 |
 | 68 Edsivan 2020 年 5 月 20 日 “又不是不能用” |
 | 69 maxxfire 2020 年 5 月 20 日 1 以 LZ 的偏好，我觉得给个随机数给 LZ 最好了 |
 | 70 banliyaya 2020 年 5 月 20 日 via iPhone 展示具体数据没必要，也没多少人会关注你究竟有多少，知道了干啥。 |
 | 71 Tink PRO 和开发无关 |
 | 72 wovfeng 2020 年 5 月 21 日 难道大家都没有在意过 YouTube 怎么展示的么... |
 | 73 lynan 2020 年 5 月 21 日 这标题，非常像是 “xxx，你不 xxx 会死吗？” |
 | 74 Flywith24 2020 年 5 月 21 日 这个问题可以用「设计如此」打回 |
 | 75 Mindjet 2020 年 5 月 21 日 感觉这样的顶格显示，很可能是产品设计考虑，比单纯数字冲击力还大，当数字已经超过了我们日常能理解的范围时，就没有那种冲击感了，这个比喻很难理解 10000000 和 100000000 的区别 |
 | 76 fueen 2020 年 5 月 21 日 你到底做没做过开发啊，产品经理叫你这样做，你不这样做？ |
 | 77 IanHo 2020 年 5 月 21 日 我站网易云 |
 | 78 SteveAlan 2020 年 5 月 21 日 要是评论一个亿，你数得清几个零不？ |
 | 79 lefer 2020 年 5 月 21 日 我站 999+ ... 如果一首歌的评论数真的超过 999 条了，就说明这首歌很火。 对于绝大多数人，只需要感受到“这首歌很火”就行了。 |
 | 80 skys215 2020 年 5 月 21 日 这个是设计的问题，尤其对于移动端，屏幕空间受限，如果太长就会导致换行或溢出隐藏，所以用了 xx+的形式 和技术没有半毛钱关系。你后端返回实际数字也好，返回 99+也好，前端都可以决定具体怎么显示。 你说评论太多统计评论数会影响数据库性能？那可以用 redis 啊。 |
 | 81 timothyye 2020 年 5 月 21 日 开发：这锅我不背 |
 | 82 hikarugo 2020 年 5 月 21 日 思维定式，你这就是典型的程序员思维，一直抱有这种思维的人永远只能是流水线的最后一层 |
 | 83 magicZ 2020 年 5 月 21 日 这种设计我感觉挺好的，没毛病。有问题，你找产品经理啊！！！ |
 | 86 daozhihun 2020 年 5 月 21 日 大部分人都会接受这个设计吧。设计师肯定是考虑大多数人的需求的，楼主的小众需求有时候只能舍弃了。 就好比两首歌曲分别是 38948230948 和 372857438589 评论，对于大部分人来说还不如都显示 1w+ |
 | 87 ryanlid 2020 年 5 月 21 日 10000 1000 1000000 100000 写这些，分得清楚吗？ |
 | 88 daniaoren 2020 年 5 月 21 日 看到这种问题，但凡有个 1 年工作经验也不会觉得是开发或者逻辑问题吧？ 不如好好想想为什么云音乐的产品要这么设计，有什么好处和坏处。真以为大厂都是闭着眼睛做产品不看数据不做调研的？ |
 | 89 weixiangzhe 2020 年 5 月 21 日 不要你觉得，我觉得都行.jpg |
 | 90 SteveZou 2020 年 5 月 21 日 via Android 哭笑不得，问号用的多可能会显得咄咄逼人，但不是问号多就能显得有理呀 |
Select Language