永远都存毫秒级时间戳

从服务上线起的毫秒时间戳 + IP 前后 16 位异或 + 两位随机数
应该是足够用了，如果再有碰撞的话，就依赖于重试去处理了

直接 .http 了

小型工具方法写单测，业务逻辑写集成测试。
业务逻辑写集成测试，mock 掉外部依赖（外部接口一类的），数据库不 mock，可以看下 testcontainers 项目，在测试部分启 MySQL / Redis 等容器。

就是把原有的读扩散改成写扩散，IM 可以理解成实时性更强的邮箱

先看源码再看文档，牛逼了

Linux 再等几年主流发行版 Kernel 升到 5.1+支持 io_uring 也就好了

git 走 ssh 那一套，不管你 http_proxy 的

就是 gossip 的思想吧，但这么搞怎么实现之前可以通过注册中心去做的那些路由调度、熔断、权重、灰度....

我觉得楼主你想法其实是对的，现在这样按层工程分包方式就是不对的。
从业务上讲，同一领域内的对象应当聚合在一起，这也是为了把领域内的知识都限制在包内，而不是散落在项目的角落里。
Node.js 在 Github 上 star 最多的 Best Practices 明确表明应当按业务分包。
为了照顾没有团队规范的多人开发，而抛弃正确的项目结构，我认为是本末倒置了。

我手上的 2720QM 还好，下边缝隙确实大了点，但屏本身还可以

直接 mono-repo 复用代码，但是分开部署

@mzmxcvbn
1. 都放在一层 dao 里，叫什么不重要，重要的这层只负责数据的加载和保存，你只需要调用标准接口，不需要关心存储细节；
2. 从 DDD 的角度来讲，每一个聚合根对应一个 DAO （ DDD 里叫 repository ）。但如果只从分层角度来考虑的话，是的，每一个 model 对应一个 dao ；
3. 对于 list 接口，你自己已经提到了，where/order by/limit 都只是“参数条件”，所以他们只是一个大接口的参数而已，这个接口的基础功能，就只是 list，至于怎么 list 、list 多少个东西出来、顺序是啥样的，只是参数而已

dao 还是要有的，未来如果需要在 data load 这个切面做事情的话，没有单独分层而是“server 层的代码中直接调用 orm 增删改查的方法。”会导致改起来很麻烦。当业务大到一定程度就没法改了。
其实如果还处于对性能要求不高的阶段，dao 层可以很简单，只有 list 、load 、save 三个方法。

至于 controller 和 service，我觉着确实一定程度上可以合并。现阶段大部分写事务脚本的业务，service 复用的机会不多。能复用的话也都会抽成单独的子函数。

建议楼主实践下 ddd，代码写出来会很清晰。

一般两遍，第一遍通读、跳读+高亮+注释，（部分书）第二遍主要读自己标记过的部分，然后整理成笔记

我们就 PM2 启 egg，没啥问题

你这需求明显 4K60，有钱 4K144，2K 没必要

只用时间戳，有可读性需要再单独转