它不支持 ping 而已

七星浏览器 没有更好的了

@dellch 单手机多开

上海的还要吗

6k 真的是实习生都招不到

@guoer 感谢提供，不过我觉得 laravel 这个接口把 getUserByToken 定义为 protected 真实太遗憾了，这样不能校验从客户端提交过来的 token 。

@ariestiger 基金里面确实nav默认表示净值，至少我见过好几套项目里都这么用。 不同的缩写在不同的行业有不同的默认含义正常的

@zhea55 innerHtml+= 慢不是重载的问题，而是innerHtml的赋值触发了dom树的重新构建。 createElement的函数调用，实际上最终都要调用浏览器本地代码，而这个调用过程是有开销的。浏览器内部就可以直接操作dom树。即使是字符串操作，浏览器内部解析必然比js快（因为js是无类型的，操作前需要判断类型，参照php的zval），何况解析HTML，浏览器那帮工程师费尽脑汁提高效率

@zhea55 我是写后端的，前段算是半调子。学c出身，略略研究过编译原理器虚拟机等。我从来不认为i前后段理念上有什么差异。我讲的只有一个意思，不要认为你的优化比浏览器聪明，你费劲心思createElement优化的方案比不上浏览器的一个优化手段，不如全部交给浏览器处理（实际上目前在微软系的浏览器里，innerhtml就是比createElement快）。比高性能代码更优秀的是可编译优化的代码。一个个createElement我看不出来有多少优化方案可以应用。

@zhea55 到底谁在秀下限！上面别人也有评论你的，你就不反省下？

应该是vpn

@zhea55 第一句前2/3句非常认同,最后的类比只能说你的见识还不够，同样的循环，交给js，php这样的语言，和交给底层去处理速度完全不同，js我不是非常熟悉，php的str_replace就是一个实例。
模板引擎 自己createElement 肯定比不上把html交给浏览器，即使现在的结果是前者快（实际上对于ie，edge，chrome大部分情况都是后者快），那只能说浏览器优化还不够。
你举的例子是指 http://jsperf.com/appendchild-vs-documentfragment-vs-innerhtml/61 这个吗，innerHtml+= 都用出来了还提什么40%
我对我说出去的话负责，骂人的话我不接受只能显得你无趣。另外我回这么多不是想教育你，而是希望其他人不要被误导。

@zhea55 你看有其他人来打你脸了， 你拿ios和js类比就知道你有多么”业余",你知道托管代码和非托管的区别吗？js我可能说不上“精通”， 但是我知道交给dom api后，操作内存的是非托管代码，效率和js的操作是数量级的差别。
ie6里的innerhtml效率比createElement高多了知道吗
手动操作内存不一定比自动效率高，除非程序员真的知道他在写什么。现代语言的发展方向（rust等）有两种，一种是增加gc效率，一种是对程序员的增加约束，提高编译后的性能

@zhea55 你既然知道reflow了，拿个 innerHtml+= 出来说少了40也不嫌丢人
更适合模板引擎的case是这个，https://jsperf.com/innerhtml-vs-createelement-test/7
另外即使是61这个case，我猜你肯定是用chrome，你敢把相同的代码放到edge，ie里试试吗
作为一个程序员，我就不说维护性问题。除非你是写编译器的，不然能交给编译器优化的东西竟然自己优化，你确定你在思考怎么提高代码性能？

@zhea55 talk is cheap 。 我没研究过createElement，但是我学过编译原理。另外，如果没有linus的技术，就不要出口成脏

@zhea55 你的《不言而喻》不能让人信服，前提是浏览器傻乎乎的一个个解析然后createElement，但是实际上浏览器可能是对这段“html”进行编译优化。在c层面进行dom树构建反而比在js这边效率更高。
js里一个一个createElement实际上没有给浏览器留下任何的优化余地。所以html大于一定长度，我猜是html效率更高，或者，未来肯定html效率更高