shi 山大魔王作死啊，把盛 shi 的碗换成黑底蓝点的了，真是看着难受。/狗头

var flag = true;
if coder.hasGF { // 所有人都 false
return flag; // test 方法返回 true

真实的故事.gif

@zhuangzhuang1988 买过就是读过，有什么问题？/机智

"Backup": [
硕大一个 [ 号已经说明这是一个数组了。

你这测试。。。根本没测到点子上吧？业务逻辑设计思路也有问题。

先来梳理一下上传文件有哪些瓶颈。

客户端磁盘读 - 浏览器单站点连接数 - 客户端网络速度 - 服务端网络速度 - 服务端应用处理速度 - 服务端磁盘写
对于单客户端来说，磁盘读一般不会造成瓶颈，更多的瓶颈是网络传输上。
对于服务端来说，网速很重要，但磁盘写入也重要了，因为它要并行处理多个客户端。

所以单机测试的话，最大瓶颈容易出在网速。这时候分多个协程是没有任何帮助的。
多机测的时候，客户端网速一般可以不考虑了，带宽窄但人多啊。这时候瓶颈容易出现在服务端网速 和 服务端磁盘。

真实压测，当然要用多 client 一起测，尤其对于上传文件这种场景来说。

但是多机天然就多连接，服务端伺服多个连接天然就并发了。有没有必要把 n*client 个上传过程再拆一步，n 个 client 每 client m 个文件变成 n*m 个连接 /goroutine 呢？这才是业务逻辑需要考虑的。

因为这直接影响到一个重要因素：传输失败率。
很多真实场景下，和服务端维持长期稳定传输是一件容易失败的事情。多个大文件捏一起，总时间更长，失败几率更高，无效传输时长更多，整体来看有效上传速度是降低了。文件越大越明显。
常见的办法就是多文件分开多个链接传输。甚至对于巨大文件，客户端直接分片给服务端。
优点是失败率降低吞吐率提高。缺点是上传逻辑更复杂，占用服务端连接数更多。

以上都是单点 server 的情况。多点的话又是另一种思路。

另外吐槽一点，MultipartForm 上传多文件已经是古代技术了。应用层处理需要的请求缓存和内存占用都会大一些。偶尔场景少量小文件传输无所谓，大量的，体积大的文件，我更倾向于 rest 风格的单文件直接 PUT。

一项事物，如果足够小众足够专业，那 Trending 一定都干货满满。比如知乎刚上线那会。
当它拥有了一定知名度，引起大量小白疯狂涌入，那 Trending 一定难看的要死。倒不是专家都死了，而只是被淹没了而已。比如现在的知乎，现在的 github 等。
当它进一步发展为吃喝拉撒一样的日常，那 Trending 又会好看一些。那时候受众大到稍微内聚能量不足的玩意根本爆不出来，而能从浩淼的信息里爆出来的无一不是真正的内容炸弹。比如现在的微博、微信。

万事万物皆通此理，某项技术也是。

这么通用的事物发展规律都看不出来，浮躁啊。。。悲哀啊。。。/自动狗头

前置一个 nginx 反代专做过滤。

我来举几个稍微恰当一咪咪的例子吧。
Google Reader，心中永远的遗憾，下线后世界范围内哀鸿遍野。在这点上绝不原谅 Google。
Picasa，前面的同学提过了。
G+，挺可惜的，环的概念稍显复杂，但其实工程师们准确描述了真实社交的数学模型。成也萧何败也萧何，工程文化真的没有社交基因。
Delicious，书签+社交的王者，和 GR 在细分社交领域几乎同等。商业化运作失败（ Yahoo 收购的就没一个好下场，当然 Yahoo 自己也可以在这个榜单内）。
FlashGet，一统江湖的优秀下载工具，开发者玩魔兽去了。。。否则下载工具领域也许根本没有迅雷什么事。
饭否，因为不可描述的原因。。。
快播，因为众所周知的原因。。。
MSN，微软的傲慢玩残了这个曾经世界级的 IM 工具。
WPS，没跟得上 windows 时代的王者。再跟上来已经成了边缘小透明。现在仅靠政策倾斜活着。
ACDSee，特指 3.2 版本。后来的越来越屎，在我心中早就死了。
Flash，为互联网带来丰富多样性的技术，死于自己的坑。当年那些闪客们现在都去哪里了？
飞信，手握巨大资源，胸藏宏伟蓝图，脚下时代机遇，打出一手烂牌。鄙视。

再追加一个：
艾德·史塔克，卧槽！纳尼！什么鬼！不会吧！/狗头

英文：程序员专用翻译
bug: bug
IP: IP
MAC: MAC
web: web
Java: Java
摔！这什么破词典！

我猜是图标缓存出错了。
搜一下 mac 清除图标缓存试试。

噗嗤。。。不留意还真没发现是 3 个应用。。。

我司小服务直接海外 DNS 解析到香港，香港转发国内速度还行。

我的虚拟机从来不开桌面。。。命令行跑跑可以了。

如果非要虚拟机跑桌面的话。。。

话说槽点难道不是 8G 跑 chrome+JB 系内存大户还要上虚拟机太勉强了点吗？

这。。。为啥必须二元论单选题？
就像问“你们吃饭是用筷子还是用勺子”一样，难道不是同时右手筷子吃面左手勺子喝汤吗？

一边给相对他能力来说较复杂的有挑战的题目，一边时刻关注进度把控方向必要时亲手协助突破瓶颈，这应该是更常见更合理的路子。
有挑战是相对的，点拨方式也是视情况而定的，手段选择灵活一些嘛。

1，版本强迫症不是玄学，是经验，是历史教训，是血泪史，是成本和效用之间的妥协。
2，你家公司这是伪强迫症，是人云亦云的教条主义，是不求真理但求合规的本本主义。

我一直强调，爱心不等于免责。

爱心要积极，责任要承担。这两点要同时兼顾不能顾此失彼。

我小区有 100 栋楼，垃圾分类政策后分类的落地实施和监督检查非常困难。
业委会说我们组织义务劳动者负责监督、协助分拣吧！居民表示非常赞同。毕竟自己的小区要自己爱。
✅对门大户说我忙我懒我不够热心，我只负责付出 1%的爱心，也就每年一百万左右吧。20 栋楼我雇人包了。
❌楼下狗三说我穷但我热心啊！我付出我的 80%业余时间，负责一栋楼！但实际上落地的时候发现，狗三一个人累死累活负责一栋楼真的完全不足，这栋楼住户从此享受着平均三天轮到一次的热心服务，臭气冲天，怨声载道，又看着狗三热心人也辛苦，都不好意思说。恰巧，你在这栋楼。
✅楼上小红说我也不富裕能力也有限，我付出我 20%的业余时间来帮大家。也负责不了一栋楼，就负责我楼上的孤寡老人张大爷一家好了。平时帮大家发发传单做做宣传之类的吧。小红的付出虽然不多，但尽责，做的到位，收到了大家的好评。

从道德 /热心 /付出比例 /群众情感来看，狗三>小红>大户。大户对这事真是不怎么上心。
从贡献量角度来看，大户>狗三>小红。狗三真的很尽力了。
从对大家的伤害来看，其他人的尽责确实提供了或多或少的帮助，只有狗三造成了实质性的伤害。
从对最终事情的影响来看，大户>小红>0>狗三，只有狗三的综合结果是负面的，把一部分人的生活拖入了比分类之前更糟糕的境况。最终忍了三个月之后，大家不得不叫停了狗三的行为。

狗三问题在哪里？不是不够热心，不是风格不高，是爱心和能力和责任的严重不匹配，最终坏了事。
而小红的方式，才是更值得鼓励的，哪怕它看起来更微薄更不足道一些。

不要运动，不要虚假，不要伤害。

@matsuz 你还是站在道德的角度上单因子的评估这件事情。
道德角度，贡献者无疑是伟大的。这个毋庸置疑。
但一旦考虑到现实，考虑到使用体验，考虑到对整件事情的成本收益，很容易得出结论：并不是每一件道德层面正价值的事情在经济层面或者其他层面都是正价值。
那么对于负价值的事情怎么办？
道德上肯定他，经济上、事实上否定他。
这才是最合理最现实最符合逻辑的态度。不能因为他在道德上占据制高点就纵容他的负面性，否则就是圣女心道德婊。也不能因为他在经济上负价值就忘了他在道德上的闪光。
对于一个温情有人性的理性经济人，合理的办法就是发一封表扬信然后无情的从列表里删掉。

至于你的一些观点，我觉得能杠的点还是有好几个的。
投毒，你觉得“阻碍 6.7%用户顺利安装甚至导致劝退”不算毒吗？
合格，什么叫做合格？官方没有明确硬性标准，那么民间默认期望求平均可以作为软性标准。如果在当今互联网环境下充满爱意的 40k 不算不合格，那充满爱意的 4k 呢？ 4b 呢？合格吗？
索取者，很难存在纯粹的索取者。即使有的人不爱分享，那他也有很大概率去推广、去影响、去制造既成事实的项目、去纵容系统和软件的自动上报、去组成用户数的那个增量 1、去组成生态圈芸芸众生中的一个。有的软件和系统和书籍等正向反馈为什么要选择发行版 A 不选择发行版 B ？有时候真的只是因为生态圈大用户多好赚钱而已。
索取者能不能批评贡献者？当然能，只要批评的对（比如经济学角度批评其负面性）。真理会考虑发言人身份问题吗？
留下质量最好干掉所有其他？这算是理性策略吗？这时候已经被愤怒掩盖了理性了。所有用户失去分流涌向单点，那质量最好不也就 40k 了吗。。。