这个笔记记录两个看起来不那么“显眼”，但实际很有价值的优化方向：

1. 不要把全局状态能力挂满整站
2. 先修掉 hydration 不稳定因素，再谈更大的性能优化

1. 不要把全局状态能力挂满整站

这个项目里一开始有一类比较典型的浪费：本地 JSON 数据本来只是静态资源，但是却通过全局 react-query 这类方式去管理。

这样做的问题是：

• 一些根本不需要 query 能力的页面也被迫吃下 provider 成本
• 公共 chunk 会被不必要地放大
• 首屏要承担更多与页面无关的逻辑

后来的处理方式是：

• 本地 i18n JSON 改成更轻的缓存读取方式
• QueryProvider 不再放在全站公共壳里
• 只有真正需要远程查询能力的页面才挂对应 provider

这类优化看起来不炫，但很实用。

在这次处理里，公共 page-shell chunk 大约从 262 KB 降到了 233 KB，说明全局壳确实被减轻了。

2. Hydration mismatch 为什么值得优先处理

如果页面存在 hydration mismatch，那么首屏不仅慢，而且会抖。

这种问题经常不会直接表现为“页面打不开”，但会表现为：

• 首屏内容闪动
• 文案或布局先错后对
• React 在接管 DOM 时发生重渲染

这类问题在静态站点里尤其影响体验。

3. 项目里处理过的几类常见问题

这一轮里修过几类很常见的 hydration 不稳定因素：

• 用随机值生成组件 id
• 服务端和客户端渲染时用不同的时间值
• 根据平台信息（如是否是 Mac）直接在首帧里判断
• 某些视觉元素初始化依赖随机数

这些问题的处理原则比较统一：

1. 能稳定生成的内容，就不要在首屏用随机值
2. 需要依赖浏览器环境的信息，就放到客户端 effect 里
3. 服务端和客户端的第一帧输出尽量一致