图书管理系统最后巡检

开始全系统巡检。分层来：静态语法 → 官方 Inspector → 构建一致性 → 数据完整性 → dist 卫生 → 后台 API 冒烟。

第 1 层：全库语法检查 第 2 层：官方 Inspector（SEO 口径） Inspector 基本全绿，有 2 个疑点要深挖：重复标题 ×2 和 重定向变成 7 条（我只加了 1 条）。排查：发现真问题：你已经用新功能把文章移动过两次（未归档→笔记→产品手册），重定向形成了 A→B→C 三级链——访客点最老的链接要跳 3 次才到，SEO 上会稀释权重。先确认现状： 第 3 层发现 2 个问题：①重定向三级链（你移动了两次产生的，最严重的是 id=6 规则 产品手册→未归档——旧地址恰好是文章现在真实所在，部署后托管层会把它弹走，形成弹回循环）；②章节组内同名（一本书里两章同名，非致命）。

先修重定向链——给移动功能加「压平链条」逻辑：用新逻辑修复现存链数据（重放你最后一次移动），然后重建验证：链条已压平（元凶规则 6 已删除，8/9 全部直达）。第 4 层：数据完整性：三个疑点逐个核实（可能是我检查脚本的口径问题）：疑点 1、3 是我脚本口径问题（集合的 source_path 是目录、FTS 不收集合只收章节），疑点 2 是真问题：两条老重定向的落点在 dist 里不存在。查它们的去向：确认根因：源条目已删（DB 无记录），但它名下的重定向规则没级联清理——stub 页还占着 dist 目录，落点却是 404。看 Db::prune 实现来根治：根治：prune 删除条目/章节时级联清理其名下重定向规则： scan() 的 dumpRedirects 在 prune 之后，侧车会自动同步。现在一次性清理两条历史失效规则并重建：规则清零、孤儿目录收走。第 5+6 层：起服务冒烟测试（页面 + API）：中文 URL 需要 percent-encoding（000 是 curl 请求问题，不是站点问题）。重测：兜底行为是 serve 开发路由的特性（canonical 正确指向真页，静态托管环境不会出现）。第 7 层：重建后 Inspector 复检：

全系统巡检报告

七层检查，发现并修复 2 个真问题，其余全绿。

✅ 全部通过

🔧 修复的 2 个真问题

1. 重定向三级链（严重） 你用新移动功能把文章移了两次（产品手册→未归档→笔记→产品手册），产生了 A→B→C 链。最危险的一条：产品手册→未归档 的 old 恰好是文章现在真实所在——部署后托管层会把真页弹走。 → 修复：移动功能新增压链逻辑（flattenRedirectChain + upsertRedirect），今后每次移动自动把途经地址改指最终位置。现存链已压平：旧地址现在一条 301 直达。

2. 失效重定向 + 孤儿 stub 页 工具/index-1、m记忆-可以动 两条：源条目早已删除，但重定向规则残留——stub 页还占着 dist、落点却是 404。 → 修复：prune 现在级联清理被删页名下的重定向（根治）；历史 2 条已清，重建时孤儿目录自动收走（清理 2）。

⚠️ 留给你决定（非 bug）

• 2 处重复标题：书签小公举集合里 Bookmarklet Forge 有两章；「11月」集合里 書之風貌、読書記 各出现两次。同一集合内两章同名，不利收录但不致命，改个章名即可。

ℹ️ 澄清的假警报

• 5 条「缺源文件」是集合条目（source_path 是目录，检查脚本口径问题，实际都在）
• FTS 25 行 = 12 散页 + 13 章节（集合本身不进搜索索引、进的是章节，设计如此）
• 本地 serve 对已删路径兜底渲染分类页——仅开发服务器行为，canonical 正确，静态托管不受影响

最终状态：91 页产物、4 条重定向全部落点有效、构建 0 失败、测试服务已清理。

【WorkBuddy】总结完整需求 https://workbuddy.link/p/iutTpl7pONKMJFgaSCPS4X?shareId=ec65ec1a-ae83-4659-9952-9b55f87dbd8b&ext2=copy_link