自己看看 API 文档就能写了，支付宝的不复杂。

阿里云镜像好评，最大的好处其实是服务器是阿里云的时候，走内网速度简直飞起来。

@anewg 如果发现错误可以联系我，或者自己提交补丁。因为手册量实在太大了，但翻译的人非常少。
一般有错误我会及时更新；补丁会定期审核；如果是文件过期不一定能顾得上，现在就有 1700 个文件等着更新。大多数情况下，原译者开了坑之后就不管了。

@amery2010 PHP 手册对多语言非常友好（当然 XML 格式也蛮难懂）

PHP 手册的经验是，可以在翻译后在文件头部注释 en 的版本号，更新起来就会容易很多，可以追踪到对应的 diff 。

格式方面，中英文要有空格；中译要用中文标点；特殊名词可以不翻译。

还有刚翻译的时候喜欢把英文惯用表达方式翻译出来，比如「你可以」，「一个」。
像这个句子「停止一个之前通过 setTimeout() 创建的定时器。」可以把「一个」去掉，也不影响意思。
参考「余光中：怎样改进英式中文？——论中文的常态与变态」 http://open.leancloud.cn/improve-chinese.html

有需要帮忙翻译的也可以找我。

我在腾讯开个工单，马上就有电话打过来解释；我在阿里云开个工单，得等几个小时文字回复，有时候还回答不到点上。

让人开始怀疑账户是否安全的，居然是账户安全险 😸

天猫超市卖假货——这是个大新闻呐，有报道价值。

LZ 厉害。我在维护 PHP 手册中文版，可以多多交流经验。

能拿到上个月的工资就不错了

@boyhailong 小公司的话，建议团队最熟什么就用什么。随便举个例子，比如团队都熟悉 PHP ，那首选 PHP 同步来写了。比如都能 hold 住 Node.js ，对 es6/es2015 都了解，有异步编程的经验，知道如何用 Async/Await 、 Promise 来解决 callback hell 问题，那用 Node.js 写异步也没有什么问题。

很多时候，找一个人人夸奖的方案其实是自己对驾驭项目不够自信。
几年前，我在仓促之下想找个银弹，就选了据说很牛逼的 MongoDB + 异步的 Python 框架： Tornado （就是 V2EX 用的框架），因为自己不熟，掉进了一个又一个坑。回过头来才发现，解决方案其实是用好你熟悉的语言和数据库，做好 profiling ，找到最关键的点去改善，胜过你仓促之下的技术选型。


技术选型，很多时候考虑的不是技术因素。对于大公司，人才多，资源多，能够去选技术上最理想的方案；小公司更应该考虑现实问题。

刚刚 MySQL 的版本显示 30 块钱，犹豫了下就变 68 了。但还是很便宜。

记得一两年前统计系统可以获取访客的 QQ 号码，不知道现在有没有补上漏洞。

@boyhailong 再比如，如果读取数据库为主，而且有热点内容，缓存命中率高，这个时候磁盘 I/O 可能不会是瓶颈，可以不上异步；如果读取的数据分布均匀，缓存命中率太低，而且读的数据量比较大，那么就需要用异步方案了，必要时候还要做 sharding 。

@boyhailong 这就需要架构者的经验了。从需求到系统设计，然后大致就能想到哪几个开销比较大的场景，压力来自哪里。
比如密集 update ，往往 I/O 是瓶颈。
如果能把多次 update 放到内存里，合并成单次写入， I/O 压力就会下降，内存开销增大，处理数据时候 CPU 占用上升； I/O 能优化到极致的时候， CPU 可能会成为下一个瓶颈，异步就无法带来显著的性能改善。

1 楼 +1 ，怎么设计一个系统是看需求的。用户量小的情况下，尽量直接简单，开发效率优先，同步是个不错的选择；用户量大而且资金紧张，硬件资源有限的时候需要用最少的硬件达到最高的吞吐量，异步是个很好的选择。
同时还要关注业务系统的瓶颈，有时候瓶颈不在 io ，异步并不能带来多少吞吐量的提升。

我是自己问小孩子想要什么的，结果想要的都是些玩的。还有想要 U 盘的，因为可以存自己的文件。