有点大炮打蚊子的感觉，就一个树状结构，自己实现不就行了。类似文件系统，目录和文件都用 inode 表示，用同一个表就能存。

@lihongjie0209 你以为 CRUD 简单？能把复杂的业务模型整理成纯粹的 CRUD 接口，给前端调用，这就是后端架构功力的体现。

要做“假设”，说明需求还没有厘清。厘清了，就不需要假设。整理需求直到接口显而易见，本来就是开发的正常过程。何况题主已经说了“产品需求文档以及设计稿已经具备”，设计稿都出来了，你还想怎么大改？产品设计可能改，这就是你不先整理接口的原因？

@lihongjie0209 那这就是你们的架构的问题，你们还活在前后端耦合的蛮荒时代。一个页面调几次接口也算问题？

后端当然会组装数据，但这些数据是符合“模型”，而不是符合“页面”。例如时间字段，返回的就是时间戳，不是 YYYY-MM-DD 之类的具体格式，因为前端可能需要显示的是“ xxx 前”。关联的数据也可以通过复合的字段返回，尽量减少前端的组装工作。现在的前端复杂度本来就是上升的，早就不是单纯写 css + html + jquery 的时代了。有时接口数据不复合需求，需要组装一下，是常见的事情了。前后端耦合，整体来讲就是低效率的。根据页面分接口，那多个端的，你也另外做一套？

后端服务的对象不是单纯的“ web 层”，web 只是前端的一种。移动端你另外写接口？小程序你另外写接口？内部调用你另外写接口？人力不是这么浪费的。

@lihongjie0209 你把“表结构”换成“参数和返回”，写下来，就等于是给了文档了，前端就可以把字段写进代码了，表结构那是后端实现阶段的事情。

@lihongjie0209 我说的是前后端共同遵守的接口约定，参数是什么，返回是什么，先定下来，怎么实现是后面的事情。例如一个加法接口，参数就是加数和被加数，返回另一个数，文档就是参数叫什么名字，例如 A, B，怎么传，post josn 还是 query string 还是都支持，返回的是什么结构，等等。至于后端怎么实现加法，这个前端不需要关心。
如果你连要做的是加法而不是乘法，参数是两个而不是多个，都不能确定的话，那就是我说的“需求未明确”。

@dajj 需求确定了，后端就可以根据需求写接口，接口就是传什么参数，返回什么，字段名是后端决定的。接口写好了，后面不是十分需要的话，是不会改字段名的，因为前端可能已经把字段名写入代码里了，你改名字，就是给前端添不必要的麻烦。其他人用了不同的字段名，就是因为你不肯先出文档，所以你才会认为“常见”。不好意思，先写文档的，根本就不会碰到这种破事。
另外，前后端分离的架构，接口应该是各种对象的 CRUD，加上一些特殊用途的，不是根据页面来的，根据页面那就是前后端耦合了。所以写文档，就是对业务本身的建模，主要是定义对象的字段等等，相当于后端的初步开发了，甚至可以根据字段定义自动生成文档。如果你的接口是按照页面来分，那页面需求变了你的接口也要跟着变，这就不是前后端分离的架构了，开发效率自然就低了，没法前后端并行开发的。

需求确定了，接口就能写出来了，实现时改接口，说明需求没有搞清楚，或者根本就没有试过去理解需求，就开始做了，那当然要一边做一边改。

这种后端就是个坑货

push 上去，几分钟就会被人拿。很多专门在 github 采集敏感信息的。

不要用 leveldb，一个几年了的严重问题，最近才修复。同样的问题，rocksdb 早修复了。

唯一选择就是 rocksdb，不少关系数据库都用它做后端

有的人连 26 个字母都认不全，他们的现实世界中也不需要其他语言

你会做这样的人吗？

它说“不签不让走”，你就真的以为不签不让走？
怎么个不让走？拘禁你？限制你人身自由？要判刑的。
所以“不签不让走”只是一句屁话，成年人了，应该懂得怎样斗争了。

可以试下仲裁，反正又不会掉块肉
它用支付宝转账发工资，很有可能是偷税了，它会怕你举报的

@Fitz 讨论这种未定义行为没有任何意义，开了竞态检测，顺序就可能不同。不同版本的调度器也有可能不同，不同的编译器实现的运行时也可能不同。所以这就是偶然的行为，你的程序是不可以依赖这种未定义行为的。

@Fitz 你可以试下用 go run -race 跑，多跑几次，看看是不是偶然。

按行读入几 G，排序后写入临时文件
重复上一步，直到处理完 100G
读所有临时文件，做归并，写入最终文件

偶然而已，按什么顺序都是对的，goroutine 的执行顺序是不确定的

没社保的还用考虑？