@yuhuan66666 《程序员修仙不讲仙德》

至于为什么要用 CoW，当然就是为了性能啰。在 https://bugs.webkit.org/show_bug.cgi?id=185003 这里有提到在某些性能测试中有显著提升。
但是 CoW 很复杂，一下改了好多代码，所以出 bug 了。其实当时作者也写了很多 testcase，无奈还是漏掉了 reverse()。

bug 来源： https://github.com/WebKit/webkit/commit/c02f5d334455d7fe8b16fe642d1f5900c5cde6e9
修复： https://bugs.webkit.org/show_bug.cgi?id=188794

是的，上个月 webkit 已经修掉了（ 6 月上的 bug 代码），但是 apple 不知道为啥这次发版没把 patch 打上。

@oh 根据源码来看，基本上就是我说的问题（除了 reverse/slice 颠倒的瞎猜之外）。至于说刷新，其实是无关的。估计应该是 safari 在刷新本页的时候，一看啥都没变，就不销毁之前的资源继续用了。实际上不是每次刷新都复用的，有概率全清掉的。

这显然是一个 bug。并且是个惊天大 bug。

此 bug 跟 load 事件无关。直接执行即可重现。与刷新也并不直接相关。
简化的测试代码见： https://github.com/hax/hax.github.com/blob/master/browser-bugs/ios12-safari-array-reverse/test.html
测试页面链接： https://johnhax.net/browser-bugs/ios12-safari-array-reverse/test


此 bug 的本质是，Safari 对所有值是 primitive literal （如 null, true, 1, 'x' 是，但 /x/，undefined、NaN 就不是）的 array initializer 做了优化，同一个 initializer 产生的数组在内存里永远指向一份，其 toString 的结果也预先计算好，所以 reverse()之后 toString()结果不变，但实际数组已经变化。正常来说，如果该 array 执行了任何修改操作，则复制到一份独立内存去。这是所谓 copy-on-write 的优化策略。但不幸的，reverse 方法没有触发 CoW。

另一方面，所有不修改 array 的方法应该不触发 CoW。我实测下来，甚至 copyWithin 和 fill 这样的方法，如果 start/end 相同使得实际上并没有修改效果，也不会触发 CoW。但是神奇的是 slice()会触发 CoW。所以我猜有可能某个苹果的临时工把 reverse/slice 的方法索引搞颠倒了。

呀，witmin.net 的域名好像挂了，变成垃圾站了。

@xujingbao 那个国产货可以用的！我主要是临时用下，不想再出去买别的转接头啊。唯一缺点是在mac下开机会报个warning。

http://www.wch.cn/download/list.asp?id=178 这个国产的似乎可行！

悲剧，上面这个链接下载的只是个应用，并不是driver，不会出现/dev/tty*设备啊！