React Query 和 Zustand 的正确分工：React Query 管理服务端状态（如接口数据），Zustand 管理客户端状态（如筛选条件）。常见错误是将接口数据复制到 Zustand，导致重复数据源和同步问题。正确做法是让 React Query 缓存接口数据，Zustand 只存储交互状态（分页、搜索条件等）。这种分工能避免状态管理混乱，保持代码清晰可维护。

摘要：本文探讨前端表格模块的工程化实践，通过React Query、TanStack Table和shadcn/ui的组合方案解决复杂表格需求。文章从简单表格的问题出发，逐步构建包含请求层、类型层、Service层等8个层级的清晰架构，重点阐述服务端分页与虚拟滚动的实现。核心在于明确各工具职责边界：React Query处理请求与缓存，TanStack Table管理表格状态，shadcn/ui负

本文介绍了React中实时数据的三种解决方案：轮询、WebSocket和SSE，重点分析了SSE技术的应用场景及实现方式。文章指出原生EventSource的局限性，如仅支持GET请求、无法自定义请求头和鉴权等，并推荐使用@microsoft/fetch-event-source库来解决这些问题。该库支持POST请求、自定义请求头、JSON请求体等特性，更适合业务场景。同时详细说明了后端的SSE实

React项目目录结构设计指南 本文探讨了React项目目录结构的设计原则，旨在解决项目规模扩大后的可维护性问题。文章指出，简单的扁平化结构在项目初期可行，但随着功能增加会导致组件混乱、逻辑耦合等问题。

多步骤表单的核心设计取舍，是把“完整数据结构”和“分步骤交互”分开处理。完整数据结构由 Zod schema 统一定义；每一步表单通过局部 schema 只处理自己的字段；跨页面草稿由 Zustand 管理；刷新恢复由 persist 处理；路由访问通过 guard 控制；最终提交前再做一次完整 schema 校验。这样写的好处是边界清楚：组件只负责当前步骤，store 只负责草稿状态，schem

TanStack Table是一个无头(headless)表格库，专注于处理表格的核心逻辑而非UI样式。它解决了前端开发者在实现复杂表格功能时面临的常见问题，如排序、筛选、分页、单元格编辑等，同时保持UI的完全可定制性。

MQTT 单例客户端难理解，是因为它不只是一个。如何避免多个组件重复创建连接？如何让多个组件复用同一个 topic？如何在组件卸载时安全取消订阅？如何保证最后一个使用者离开时才 unsubscribe？如何在网络重连后恢复订阅？如何把 MQTT 消息分发给正确的业务模块？如何和 HTTP 快照、状态管理配合？所以它的核心不是连接，而是管理。MQTT 单例客户端 = 一条全局连接 + topic 到

本文介绍了SSE（Server-Sent Events）技术在前端实时通信中的应用。SSE是一种服务端向客户端单向推送数据的轻量级方案，适合订单状态更新、直播评论、数据看板等只需服务端推送的场景。文章对比了轮询、WebSocket和SSE的适用场景：轮询适合短时状态检查，WebSocket适合双向通信，而SSE则专注于服务端单向推送。通过一个体育比赛评论的示例，详细说明了后端如何实现SSE接口（需

Next.js 16 之前，我们更多是在“整页静态 / 整页动态”的框架下理解缓存策略：通过 revalidate 控制重新验证，通过 dynamic = 'force-dynamic' 强制整页动态，通过 fetch(..., { cache: 'no-store' }) 精细禁用某次请求缓存，通过 connection() 等动态 API 把页面推入运行时渲染。到了 Next.js 16，随着

三种操作，如果继续扩展成 edit / clearCompleted / reorder，用 useState 会越来越乱。动作：setField、setError、reset、submitStart/Success/Fail。动作：fetchStart / fetchSuccess / fetchError / reset。当你的状态变复杂、更新方式很多、或者你想把“怎么改状态”集中管理时，用它