直接把域名放出来好了。。。

另外，curl -v 一下把日志贴上来也可以看出一些信息。

另外，win 电脑的话去 ie 的设置里勾上“使用 TLS1.1、1.2”试试。

总之看起来像兼容性问题。

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>狗三，只有狗三的综合结果是负面的，把一部分人的生活拖入了比分类之前更糟糕的境况。最终忍了三个月之后，大家不得不叫停了狗三的行为。

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

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