@JsonUnwrapped

当时公司发了 MBP，后来怎么用怎么别扭，然后自己搞了个 win 的台式，不过日常也基本上都是虚拟机 Linux 在用

搞之前稍微想了想优缺点：

macOS 的优点：

- Unix-like: 文件系统（例如 ~/.ssh/ 、~/.m2/ ）、命令行、环境变量等等习惯
- 高分屏优化、字体渲染机制
- 色域
- 配合其硬件带来的优秀的触摸板体验
- 和生态内组件的联动，例如 iCloud 、note 、iPhone 、airPods 等

其缺点在于：

- Unix-like 既是优点也是缺点，毕竟不完全是 Linux
- BSD 风格工具集，和 linux 的命令行并不完全一样
- 日常键位、鼠标加速度、滚轮方向不符合大众习惯，需要各种转换软件
- 硬件封闭，受限于苹果提供的硬件性能，需要支付溢价
- UI 粘滞，不如 Windows 响应迅速
- 没有底部任务栏，窗口管理一片混乱
- 跑 docker 依赖于虚拟机，而非原生实现

还成，挺稳的，开发工具都在 vmware 的 manjaro 上，windows 装个企业微信当宿主机和办公机用
反而是 mac 现在基本上一周不关机就不成了


thinkbook 16p

从服务上线起的毫秒时间戳 + 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，代码写出来会很清晰。