站在面试官的角度想问题。

——你喜欢受试者叨逼叨滔滔不绝吗？
——不喜欢。面试节奏应由我控制。
——那受试者讲太简略讲不清楚怎么办？
——没什么讲不清楚的。你说线程池我自然知道并发和必要的同步手段，你说 https 我自然知道证书、服务器配置等细节。我不问太细，只有几种可能：
1，我觉得没必要。
2，我心虚不敢问太细。
3，我想问更多可是真的没时间了等下还有会。
——会不会担心遗漏了关键信息？
——首先，受试者应该充分梳理并概括自己的亮点和优势，这也是能力。连主次都分不清，连信息传达都做不好，逻辑能力有问题。其次，真正必要的信息即使受试者不讲我也会详细问，这样才能挖到受试者的能力边界（也就是为什么总要面试造火箭的原因），还能打击假冒伪劣（只会嘴炮的云程序员真的不少）。


站在受试者的角度，只有一条：
投面试官所好，赢得认同。
之后才是自己了解和抉择的过程。

只有一种例外，受试者才需要主动说更多：
面试官不合格，是既不会面试又不会聊天的半封闭技术男。你不说话，他都不知道该问什么，动不动场面就寂静得尴尬，问的问题也没有目的性。这时候目标就变了：你不但要表达自己，还要担负起控制面试节奏的责任。。。

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

另外，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，你家公司这是伪强迫症，是人云亦云的教条主义，是不求真理但求合规的本本主义。