yuki_uix

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

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

从单个 Agent 的原子化拆解到规划反思的迭代循环，从记忆系统的分层设计到生产环境的安全管控，AI Agent 的演进是把一个「聪明但不可靠」的工具，改造成一台「可可组合、可追溯、可信任」的系统。

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

Network 面板里的 Doc 到底是什么？为什么有些认证信息会出现在这里而不是 Fetch/XHR 里？这背后有什么机制？

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

在面试练习题中常常出现的 reduce 为什么在实战中相对较少的被使用到？我们在什么时候应该用到 reduce？本文从一个前端开发工程师的视角思考 reduce 的使用哲学。

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

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