你不觉得应该先display cu, 然后贴出来么?

很明显，这样的算法太弱了，搞那么复杂干嘛，直接像显示器那样，逐行扫描好了。来来回回，随便怎么搞了。

CloudXNS，目前也正在官网中。

先mark一下，等有钱了在看看。

注册的地方，一堆堆啊。

宇宙最强的PHP，必须配置宇宙最强的CPU啊，这样的CPU，岂是DoS能搞定的？

红茶的教程，还是很赞的。

“因为连续5天滥用流量，导致我们的母鸡流量已被用完” 看到这个，不禁让人思考万千呐。

搞笑了，如果没有导师的研究课题，你丫怎么会想到这个程序的？

如果是你想到这个点子，然后你导师受到启发然后有了课题的，那么你厉害，随你开源。

否则，你就是打着开源的名义，为自己获利（不局限于金钱）

这个时候，你应该抓包看一下发生了什么事情。

风气已经被小米带坏了，哈哈。

之前关于其他内容吐槽过。

@schemacs 状态码不能满足的情况下，用错误代码，那不是得两套逻辑了？那何必搞那么复杂呢？

@schemacs 你真应该好好读下 @way2exluren 的回复。

你刚才引用的 "v2 will always return a 409 status code with a stable and documented error identifier in the body." 人家也是有错误ID返回的。 按你之前的意思，这是不是也算 “自己造” 了？

@schemacs 如果你硬要这么说，那也没办法了。等那天觉得状态码不够用了，你就自己在协议上扩展吧，杂交一下未必不可。

不过这里还是想说一下，接口逻辑与HTTP协议本身分开，是有利于接口脱离HTTP而存在的的，否则后续如果不走RESTful了，接口代码又得变了。因此，个人还是建议在接口中返回相应的数据，这样即使改成其他方式了，端到端的业务都不会有任何影响。

@schemacs 果然，你说到框架了，哈哈。框架不多说了，每个人有自己的喜好。至于github没有业务状态，那请问如果错误类型较多，怎么办？光靠他返回的英文内容？那国际化问题怎么办？还得配合Google翻译啊？

markdown.org.cn 发来贺电

补充一点，用HTTP状态码判断，这个方案让人想起了之前那个 @CloudXNS 的API，居然还得用不同的HTTP方法，神一般的设计。