不如一步到位直接起个数据库（划掉）
如果可以序列化成数据库的话，同一台机器上可以使用 SQLite3 ，启用 WAL 模式后读写互不干扰，可以同时进行，性能大概比每次序列化强，但是单独访问的话就不一定比 OrderedDict 快（
但是最主要的是不用自己解决复杂的线程同步问题了，而这个可是经常处理出错误的（

@1sm23 也不是不可以在安卓子系统上弄）
我记得是全局生效的

协程就是一种代码的组织结构，你当然可以全部使用手写状态机来做，事实上早期开发大部分都是这个模型。。。
作为一种结构，它可以大幅度简化某些场景的代码复杂度，这就是它最初的意义。
即使传统磁盘 IO 没办法使用 poll 的模型（因为总是 ready ），为了代码上的统一，做成线程池支撑，上层逻辑用协程描述也无可厚非（虽然现在新的 io 模型已经支持提交大量磁盘请求然后等一起完成了）
至于性能方面的提升，那有也只是副作用，即降低了编码复杂度导致可以从更高抽象角度优化业务逻辑，而不是拘泥于底层状态机的实现细节。
这里和同步 /异步，阻塞 /非阻塞其实关系不大，即使是一个纯算法，也可以使用协程来描述，generator 的模式和协程其实就差不多同构（可以互相转换），与其在需要数据时耦合上获取数据的代码，不如做一个 generator 将数据获取的过程抽象出来，generator 可以让你使用传统控制流结构来描述逻辑，同时内部状态就直接用 generator 中的局部变量表示。

Swift: ?

(先看看是不是真的要特权才能跑。。。
执行前设置一个 __COMPAT_LAYER=RunAsInvoker 环境变量试试功能会不会异常

@yangyaofei 考虑下内网有没有别的服务（
比如数据库

还有就是即使啥权限没有，也能挖矿

@feather12315 win 阵营也抄了个 Io Rings （
https://docs.microsoft.com/en-us/windows/win32/api/ioringapi/

考虑到还有原生对象，精确的复制大概是不现实的（
加上还可以 proxy

Windows 容器可以 hyperv 也可以用进程隔离，但是后者只在 server 版提供（
反正两种都不支持运行图形应用

原因是被编译（ ES6->ES5 ）成
var _this = this
... map(function (question) {
eval('this.xxx' + xxx)
});
这样了。。。
显而易见编译不可能处理 eval 里面的东西（

api 30 明明是倒退
无需任何权限就可以在标准目录里创建文件夹，然后也能读取文件列表，那么只需要把跟踪信息编码到文件名里就好了

(我就记得 chrome 的菜单按钮可以支持这个操作的
启动器不支持我觉得是故意的，因为这和拖动重新排序的手势冲突了，而后者是出现了很久的，不可能说改就改

（开机一次用掉的读写都比你一个星期编辑几个文本用掉的多了）
现代 ssd 对这种远远小于缓存的读写优化很好，不可能出现反复读写同一块的情况）

说的好像 outlook 不会挂一样，最近好多人 windows 邮件客户端打开就闪退就是因为 outlook 访问异常（

@shadows (git 存啥都是完整存档的，diff 都是临时计算的，换句话说你换个专用 diff 工具可能就可以对某些特定二进制格式做 diff 了）

（用镜像劫持）（划掉）
标准方法是使用兼容性管理工具，可以安排环境变量设置，甚至替代 dll （但是较为复杂）

网格边界上有明显的分界线（

程序员最讨厌的两件事：1. 写文档； 2. 别人不写文档。