项目规模不大的话，数据库直接 join 什么其实还是很好用的。
瞅了一眼楼上为什么好多不推荐 join 的感觉都没说到点上。

我自己的经验就是：
1.大项目需要分表分库，join 在分库分表的情况下处理起来很麻烦。
2.缓存问题。比如某个订单列表里包含有用户昵称，这个昵称因为是通过 join 查询因此也被缓存起来了，假如某个用户改了昵称，那么很容易会忽略掉这些缓存造成不一致的问题。
3.用业务代码替代数据库 join ，也能方便日后服务化。比如用户系统和订单系统以后做拆分了，vo 需要同时展示订单信息+用户信息，那么就可以根据关联的 id 调用其他服务来获取数据，减少重构成本。（ UserDAO.findById -> UserRemoteService->findById ）
4.一般情况下，join 是不会直接 select *所有字段的，一般都是按需选字段。不同的业务需要取不同字段的话就要写不同的 join 了，还不如直接 id 直查关联数据，按需选取。

至于你说的多表关联，一般是要求不超过三张表 join 的。
像商品-订单-用户，就是典型的用户-商品多对多关系，订单可以看作是关联表并且额外维护了其他的信息。
但是像角色-角色权限关联表-权限，也是一个多对多关系，但是由于角色-权限本身是紧密耦合的，不会像商品用户那样可以独立作为一个系统，他们的关联表也不需要维护额外的信息，所以这种场景肯定还是 join 更合适。

@cghost
@wetist
接的 ultrafine 4k ，用的显示器扬声器。

三年没写过 js ，才发现又变天了。。。
都不用 npm yarn 了么。。又出了个新玩意。。

我觉得如果真的想缩短传输量，为什么不直接上 protobuf 这类结构体？
连字段名都可以省略

旧项目的话，因为存在大量循环引用依赖，private final 构造器注入（配合 lombok ）会出现错误，因此还是用 @Autowired 。

@PPing520 iBook 本身会将打开的图书导入进 icloud 图书库。
这个 iCloud 图书目录正常情况下你在 finder 里是看不到的。可以通过 spotlight 等方式进入。

双拼用了三年，后来又换回了全拼。
现在的输入法都很强大，双拼实际效率不必全拼快太多。
最主要的是各大主流网站搜索都只支持全拼。

应该说是苹果战略规划做的好。
18 年的时候，A12X 在 Geekbeench 上跑分就已经开始赶上 i 系列处理器了，当时大家觉得这个跑分结果很奇葩，移动处理器怎么可能和 PC 相提并论。
在 19 年的时候，苹果推出 catalyst 做铺垫，帮助开发者将 ipad 应用移植到 mac 上边。
20 年的时候正式推出基于 ARM 架构的 macOS ，x86 兼容工具 rosetta2 ，xcode 啥的全部做好一并提供给开发者，尽量让开发者们无缝迁移。
20 年秋季发布会直接发布 M1 芯片以及相关产品。

我们回过头来看看国内的鸿蒙，19 年的鸿蒙互联 /方舟编译器大饼怕是现在还没吃完吧。

我绑定的支付宝，也是扣费失败。
我解除了旧的绑定，重新绑一定就 ok 了。

大部分 nightshift airdrop handoff 都给你翻译了。
像 safari 、facetime 这类也给你在后边加了中文，比如 safari 浏览器、facetime 通话。
之所以要给你整成中文是前两年搞什么文化自信的政策要求的。
北京 soho 都强行被翻译成了北京搜候。
北京地铁的各个站点名现在都是拼音而不是英文翻译。

羊驼不是骆驼好不好？

我买了一台美版的 ultrafine 4k 。
被我弄坏了需要更换面板，当时花了两千多块钱。

我买的 mac studio ，跑 idea ，编译代码，没超过 45 度。
就离谱。

博客最重要的难道不是内容输出？界面什么的只要看着整洁不影响阅读不是 ok 了？
像 V2EX 上一群博客搞得花里胡哨但是博客文章都是些没有什么实质意义内容的《 xxx 安装配置》？

java 的三层架构太深入人心了，以至于写 java 的在切到其他语言以后免不了总是会有意无意的弄出这种分层模型。

前端属实是把茴香豆有几种写法整出花活来了。

我反而挺惊讶的。
我的 mac studio 定制版 3.30 日下单，说是 5.14 ～ 5.21 送达。
后来上海疫情严峻，我以为会拖到 6 月份。
结果 4 月 10 日突然收到一条 apple 发货的短信。
一看是深圳那边发来的。。

@chendy 网关能干的东西多了，请求合并、协议转换 /适配、数据格式转换都是网关力所能及的范围。