成为全栈·React 管理后台篇·总复盘：从“接口能调通”到“后台值得使用”

成为全栈·React 管理后台篇·总复盘：从"接口能调通"到"后台值得使用"

这套管理后台最大的工作量不在把二十多个接口接上页面，而在处理状态所有权、失败恢复、契约偏差和用户工作被打断的边界。

第一版管理后台已经有侧栏、表格、表单、权限和所有主要模块。从功能清单看，它完成了；真正使用时，却不断出现细小但高损失的问题：保存已发布文章导致下线，返回列表丢页码，后台重取覆盖正文，连续粘图丢内容，批量部分失败却清空选择。

这些问题解释了"接口能调通"和"后台值得使用"之间的距离。本篇不再罗列组件 API，而是复盘二十二篇最终沉淀出的判断。

Vite 负责开发与构建，TypeScript strict 处理类型和空值，Biome 管规范，Vitest 固化行为，OpenAPI 生成类型减少契约漂移。它们组成多道门禁，却没有任何一道能单独证明系统正确。

请求层统一解包 {code,message,data}，按业务码区分刷新与退出，并用单一 Promise 解决旋转刷新令牌的并发竞态。页面因此不再各自处理 401 和 toast。

服务端事实交给 TanStack Query，会话与偏好交给 Zustand，编辑草稿交给 React Hook Form，分页筛选进入 URL，短暂交互留在组件。这个划分消除了很多"双份数据谁覆盖谁"的问题。

Query 的核心也不是少发请求，而是声明远端事实的身份、有效期和失效关系。文章发布会影响列表、详情和统计，代码必须把这条业务关系表达出来。

四处计划与契约冲突都选择契约：评论写接口路径、用户端点、likes 裸数组、并不存在的标签合并。反向测试进一步钉死这些差异，避免后来者凭经验改错。

页面体验返工则集中在状态切换点：加载到编辑、上传到保存、列表到详情、部分失败到重试、权限到业务护栏。主流程截图往往看不出这些问题，只有带着真实任务连续操作才会暴露。

文章页把普通保存与发布、下架分开；评论审核使用通过、拒绝、待复核，而不是裸状态下拉；标签仍有引用时禁用删除；管理员不能通过表单禁用自己。

这些设计没有改变后端权限，却减少了误操作。前端的职责不是冒充安全边界，而是把状态机、权限和关系约束翻译成用户能理解的动作与后果。

表单只首次回填，保存成功后用服务器响应重建基线，失败时保留输入。上传计数覆盖整个表单，Promise 队列与 latest ref 防止连续粘图覆盖正文。批量任务保留失败项和详细原因。

共同原则是：系统状态可以失败，用户已经完成的工作不能因为一次失败被顺手清空。

编辑器生态最初约 1.06MB。路由拆分隔离使用场景，visualizer 找到 refractor/all，297 种语言缩到 41 种后，md-editor 降至 563.94kB、gzip 180.24kB。

它仍超过告警线，但项目保留告警并记录 owner 取舍。优化不是追求终端安静，而是知道成本落在哪条用户路径上。

最终门禁为类型检查、Biome、14 个文件 69 个测试和生产构建。浏览器在独立临时数据库上覆盖文章、列表、评论、设置、窄屏与主题等主路径。

仍未完整自动化验证中文输入法组合、精确上传竞态、批量部分失败和真实生产 Cookie；组件级 jsdom 与 Playwright E2E 也还没有建立。这些是下一阶段明确的工程项，不应被"69 tests passed"遮住。

共享入口最终约 146.28kB gzip，编辑器和看板按路由加载。部署还必须验证 SPA 深链、/api/v1、/files、HTTPS Cookie 和缓存策略。

text 复制代码

工程与请求 → 状态与会话 → 列表与表单
→ 编辑器与业务工作流 → 权限与关系数据
→ 异步可靠性与全局页面 → 构建、测试、部署

它不是组件目录，而是一条从"代码能运行"到"工作不会被打断"的路径。每一层都建立在前一层明确的事实与边界上。

这次接手让我再次确认：后台的质量很少毁在一个不会写的组件上，更多毁在两套状态交接、一次失败恢复、一条旧契约假设和一个没有说清后果的按钮上。

各位看官，如果你正在做自己的管理后台，可以暂时放下功能清单，完整走一遍真实任务：带筛选找到内容，编辑、上传、保存、返回，再制造失败。系统仍然保留上下文、解释结果并允许继续工作，它才开始值得使用。

如果这篇文章对你有帮助，欢迎订阅我的 CSDN 专栏 「成为全栈」：