IOS 的软件就属于典型的高内聚，低耦合，依赖的东西，都装在软件包里，对外没依赖，缺点就是软件体积贼大。反例就是 windows 程序， dll 运行库，彼此高度依赖

@denghongcai 66666 ，我就说应该有轮子，但是始终找不到

让用户装 360 浏览器的目的最主要就是因为这玩意几乎是唯一的 XP 下可运行的 chrome 浏览器，还用兼容模式是什么鬼。我们都是直接在页面上要求用户使用急速模式的

定时器啊，这很简单好吗，定时触发事件，清空关键数据就行儿女

@msg7086 哪家是免费又专业？

@ss098 这个真屌

@changwei 你这个是表现单个盒子，是的，这个已经做的很好用了，很直观的，但是对我说的，表现盒子和盒子之间的关系的没有

@Tonni 没看懂这东西的作用

@lneoi 直白的说吧，现在似乎没有哪款浏览器能表现出盒模型的碰撞关系，如果你不是对 CSS 本身有了解的话，去调试盒模型的位置非常痛苦，有的情况还算直观，有的是完全不知道为啥会出现在那里

@murmur 不不，你说的这些还是不直观，就像你说的，要基础牢靠，要去看一条条的样式，然后逐步去推测最终结果。而浏览器调试的一个最大坑点是，它能表达一个盒子的所属信息，但是它无法表达盒子和盒子之间的相关信息（这一点完全靠调试人员自己的经验），比如一个盒子其实是被另外一个盒子给挤下去的，这个你要基础不牢靠尤其是对盒模型的那些样式不是特别熟悉的话，调半天都不明白为啥这盒子就没法在这个位置上，这真的是太痛苦了

@Arthur2e5 好吧，我描述不准确，主要是我懒得去翻文档，总之 ascii 除了英文+数字，就剩下一些基本符号了

另外， C++字符串拼接怎么不麻烦啊，"字符串" + 变量名，这种方式居然无法工作，你知道这多让人崩溃吗。 C++的字符串处理能力比起 C 来真没啥本质变化， string 带来的历史遗留问题导致 wstring 不能很好的普及，而且很多和字符串有关的 api 都是按字节拷贝的，现代字符处理能力希望的都是屏蔽掉字节层次，专注处理字符

@niseshiki 在中国这个巨无霸开始在互联网发力之前，当时的计算机世界也确实不怎么需要计算性能了，欧洲，美洲人就那点人口，根本没有中国这种爆发性的计算需求，这就是为啥现在国内的重量级服务要么 C 要么 java 的原因，国内的人有时候喜欢人云亦云老外的说法，老外在国外呆着，当然不觉得 python 的性能有啥问题。德国地铁不来一趟中国，怎么会知道自己的峰值调度数据连北京日常数据都不如呢

@mingff258 这个问题我也遇到了，另外，我个人的总结是， Vue 这东西用的时候，在设计上，一定要避免在任何一个 compute ， method ， watch 中处理太复杂的逻辑，否则就卡，如果逻辑太复杂了，就异步吧

@sagaxu 其实不管是 pypy 还是 HVVM 都算不上成功，目前 jit 这条路就 node 这一个比较成功的例子

我们需要的语言，其实和动态静态无关，我们需要的其实应该是有编译前类型检查，带 GC ，最好还能热更新的现代语言，只是目前满足这几点的都是静态语言而已

你需要补充一下 Http 协议和 url 编码(urlencode)的知识， url 标准规定， url 地址中， URI （路径）， queryString 部分，都应该进行编码，所谓编码，就是所有的非 Ascii 字符都应该转为 url unicode 编码形式，就像这%2c 。但是要注意的。 Ascii 码里除了英文字母外基本就没有了，在它看来比如冒号，斜杠，这些都是要转码的，所以你一旦对整个 url 转码，你的 http 后面的冒号，斜杠也被转码了， http url 就被破坏了， curl 的转码函数不是很智能，像 php 就有只转 querystring ，和能识别哪些内容是协议头，主机域名端口所以略过不转的，但是 curl 不行，所以你必须指定哪些内容让它转，哪些保持不动，最后拼接处理结果。用 C++处理字符串就是很麻烦，不像后来的语言那么完善，自己得小心

PHP 的版本，正则表达式的实现里，需要实现对 unicode 匹配的支持才能做到正确匹配中文，我记得 php 是在某个版本之后才支持的

@freeminder
@AlisaDestiny
@ck65
谢谢楼上各位，奋斗了一晚上，终于在重新理解 promise 模型和闭包变量作用域的基础上，按照 freeminder 的方法搞定了。折腾死了，我终于明白为啥 Promise 仅仅出来了两年就被 async/await 干掉了， 12 万分的希望 async/await 早日在前端普及吧，再也不想拿 Promise 写东西了