问题背景
这类问题常见于业务增长后的前端项目。页面还能跑，但新增需求越来越慢，问题定位越来越依赖个人记忆，最后所有人都怕改公共代码。
先分清服务端数据、表单状态、界面状态和跨页状态，再决定用 Context、缓存库还是轻量 store。 这篇文章更关心落地细节：怎么拆问题、怎么写代码或流程、怎么验收，而不是停在概念介绍。
React 项目里最容易被低估的是状态来源。接口缓存、局部表单、URL 参数和全局偏好混在一起后，组件会变得很难预测。
推荐做法
- 先分清服务端数据、表单状态、界面状态和跨页状态，再决定用 Context、缓存库还是轻量 store。
- 先把问题拆成数据、状态、视图、交互四个部分，不要一开始就改组件。
- 找到项目里已经稳定运行的相似实现，沿用命名、目录和错误处理风格。
- 给关键路径补最小可复现样例或测试，避免只靠刷新页面确认。
一个可直接借用的片段
type ApiResult<T> = { code: number; data: T; message: string };
type UserView = Pick<User, 'id' | 'name' | 'avatar'>;容易踩坑
- 不要为了消除重复就过早抽象，三处相似不一定代表同一个业务概念。
- 不要把后端返回的所有字段原样传到页面深处，字段越散越难维护。
- 不要只在高速网络和新电脑上验收，真实用户环境往往更差。
检查清单
- 是否能说清楚这个改动解决的具体问题。
- 是否有失败、空数据、慢网络或权限不足时的处理。
- 是否留下了后续维护者能看懂的命名和边界。
- 是否用命令、截图或真实页面验证过结果。
好的技术文章不只是告诉你“可以这么做”，还要说清楚什么时候不该这么做。前端工程 的很多经验，真正值钱的部分都在这些边界里。