Web 应用中的数据传输与状态管理

我开始写这个系列时，以为"状态管理"就是选个库（Redux 还是 Zustand）的问题。写完 9 篇，我才意识到:状态管理是一个思维方式，而非技术选型。 这篇文章不是技术总结，而是我的认知转变记录。

选择通信方案,本质上是在选择组件之间的耦合程度。紧耦合的代码容易理解但难以重构，松耦合的代码灵活但追踪成本高。实用建议是：从最简单的方案开始，Props 能解决就用 Props，不够用再升级。

表单状态是前端最复杂的场景之一，难在状态、验证、性能、依赖的交叉。React Hook Form 以非受控为基础，是目前平衡较好的方案。验证时机比规则本身更影响体验。

WebSocket 本身的 API 很简单，但要在生产环境用好它，需要考虑很多工程问题。这些问题没有标准答案，需要根据具体场景权衡。

用 useState 管理服务端数据会导致难以同步等问题。服务端状态本质是"远程缓存"而非普通状态，React Query/SWR 等专业工具已内置缓存、去重、重试、乐观更新等能力，能显著提升开发效率

别再死记 REST、GraphQL、WebSocket 的优缺点了。本文从实际问题出发，解释每种方案的设计思想，提供决策树，教你根据需求选择合适方案，而非盲目跟风。

AI 帮你写状态管理代码时，可能推荐过度复杂的方案。本文对比主流工具的"AI 友好度"，分析 Zustand、Redux 等方案的适用场景，提供决策指导，让你在 AI 协作中选对工具。

登录跳转回原页面——这个常见功能背后藏着 URL 编码、redirect 参数、安全验证等技术细节。本篇文章通过实际场景拆解 URL 作为数据载体的设计思想，分享容易踩的坑和解决方案。

你有没有思考过，当你在表单里输入一个名字，点击"提交"，然后页面显示"保存成功"。这个过程中，数据经历了什么？数据的生命周期/副本/状态是什么样的？一起来探索与发散思考吧！