电脑和人脑工作原理根本不一样，你觉得电脑快是因为它是一种被设计好的 dedicated 系统。好比硬解总是比软解高效一样。

以目前我们对大脑的工作模式理解，根本不可能。即便掌握了这个点，以目前电脑的算力去模拟人脑，那也是万万不足的。

用 1 楼的方法，绝大多数程序都会认这个环境变量。至少我还没遇到不支持的

Transmission ，一直用它挂 pt ，没崩溃过。

@mxalbert1996 好像确实如此，还可以这么玩，涨知识了。谢谢

@we000 不存在冒犯，但是既然你要说我说得有问题，那起码要讲详细点吧。我裤子都脱了你就给我看这个？

目测楼主还得再买一个

@we000 根据 LZ 描述分析，是想在 mac 下面把大于 4G 的文件拷贝到 windows 下面，不知道你说的“可以读”对这个目标有意义吗？请详细说说我怎么个答非所问法，我愿意改进。

@kingzez
exfat 在 mac 上面是不需要安装任何第三方软件的，有原生支持，高速 sd 卡也是默认这种格式的， exfat 不是日志型，遇上写时断电这种意外比较容易出问题。但你只是交换下文件，这个问题并不大吧。是不是稳定，好不好用，总是要自己试过才知道，切勿人云也云。

mac 系统原生不支持 ntfs ，貌似装第三方的稳定性也是一般般。其实你可以在 mac 下面将盘格式成 exfat 格式，就可以传超过 4G 的文件了，而且两个系统都支持。

mysql 在 pg 面前就是个半残的 rmdbs
事务竟然不支持表结构修改，断电或进程出错时容易导致数据文件损坏。
当然 mysql 大体上写性能会好些，特别是优化过后。
因此，根据你的应用场景进行选择了，数据不是很多，需要数据完整性和功能的话，选 PG 。
像 uber 那样存在大量写的话，就选 mysql ，配合容灾策略的话问题也不大，像淘宝都是用 mysql 的。
不存在哪个数据库系统可以适用任何场景。

sqlite 数据量大时撑不住吧，况且它不是 nosql 的。

搞个监听耳机放白噪音

真是奇怪的设计。
既然你知道是 utf-8 的话，那就按 utf-8 编码去读就 OK 了吧。就我有接触的编程语言标准类库中都含有按编码读取文本文件的功能。

@jciba5n4y6u 我也有同样的想法

会 python 不会编程？

直接传 key 简直就是多此一举啊，随便监听一下网络就能把你的 key 盗走。
最简单的方式是使用签名，各大开放平台都是这样做的，性能好，安全性不错。

签名基本原理是通过 key/secret 的实现：
1, 服务器负责为每个客户端生成一对 key/secret （ key/secret 没有任何关系，不能相互推算），保存，并告知客户端。
2, 当客户端调用 api 时，根据某种规则将所有请求参数串联起来并用 secret 生成签名 sign 。
3, 将 sign 和 key 一起放进请求参数对服务器进行调用。（注意 secret 不要传）
4, 服务端收到请求，根据 key 去查 secret ，然后用同样的算法，验证签名。
5, 为避免重放攻击，可加上 timestamp 参数，指明客户端调用的时间。服务端在验证请求时若 timestamp 超过允许误差则直接返回错误。

以上，即使第三方知道了你的算法， key 等信息，由于无法捕获到 secret ，也无法推算，因此是安全的。最好是把 api 布署成 https 的。

搞明白事务和锁就没什么问题了啊。
当然有钱的地方安全性要考虑好，反代只暴露 80/443 ，最好用 443 。
其它服务如数据库 /fastcgi 绑定到本地端口不允许外来连接。
业务流程反复考虑多几遍尽量把细节还有意外的情况纳入考量范畴，写成测试用例
金额变动要写日志，定期对帐，自动的手动的都要对一下。

我觉得“复刻”和“分家”最合适！

@gdtv 发工单威胁他们跟 ICANN 投诉，这招是当时 namesilo 教我的。记得 ICANN 是有条款不允许这种 60 天的冻结。