Phaser 系列维护清单：新增文章如何归类、入专项和拆分组

这份清单是给后续维护 Phaser 系列用的，不是读者按主题学习的入口。它解决一个很实际的问题：当文章从 120 篇继续扩到 150、180 篇时，不能每次都靠记忆判断“这篇应该放到哪个总分类、是否要进入专项页、某个专项分组是不是已经太长”。

原则只有三个：总导航负责完整发现，专项页负责深入阅读，维护清单负责让新增文章有稳定的落位规则。新增文章可以很细，但导航规则必须稳定，否则系列越写越多，读者反而更难找到内容。

新增文章处理流程

每新增一篇 Phaser 文章，按下面顺序处理：

• 确认文件名、slug、标题、日期和描述是否稳定。文件名会影响公开 URL，不要为了归档整齐移动已发布文章。
• 判断它的“主系统类型”，只放进总导航的一个主分类，避免同一篇文章在总导航里重复出现。
• 判断它是否属于 3 个专项页之一：性能与发布、关卡与内容工具、战斗与数值。
• 如果属于专项页，再判断应该进入哪个二级分组；如果没有合适分组，先评估是否新增分组，而不是强行塞进相近分组。
• 更新总导航的专题篇数、月份回看和专项入口说明。
• 更新专项页的分组篇数、快速定位表和文章表。
• 跑链接存在性、尾随空白、git diff --check 和限定 Phaser 目录的 Hugo 解析。

总分类决策表

总导航仍然使用 7 个主分类。每篇文章只能选择一个主分类，哪怕它同时涉及多个系统。

专项页纳入规则

专项页不是第二个总导航，只纳入需要深读路径的文章。判断时看文章是否能帮助读者完成一个专项方案。

暂时不要为“经营与模拟”“UI、叙事与本地化”“小游戏与物理手感”新增专项页。只有当这些主分类各自超过 25 篇，且内部出现明显阅读路线时，再拆新专项。

二级分组拆分规则

专项页里的二级分组要比总分类更具体，但不要过早拆太碎。

• 单个二级分组达到 10 篇时，先检查是否已经混入两种不同问题。如果是，就拆成两个分组。
• 单个专项页达到 30 篇时，必须重新审视快速定位表，避免读者仍然需要从长表里找文章。
• 新增分组必须能用一句话说明边界，例如“资源、缓存与发布”比“其他发布问题”更适合作为分组名。
• 如果文章只是交叉相关，不要为了交叉关系新增分组；可以在专项页正文里用一句话提示交叉阅读。
• 分组标题使用中文，内部锚点使用显式英文 <a id="..."></a>，避免不同 Markdown 渲染器对中文锚点处理不一致。

文件位置与公开 URL

当前系列有一个历史状态：2026 年 1-4 月文章位于 content/posts/game/client/phaser/2026/，5-6 月文章位于 content/posts/game/client/phaser/ 根目录。因为站点 posts permalink 使用内容文件名生成公开 URL，不要为了目录一致性移动已经存在的文章。

后续新增文章建议：

• 如果是继续维护 2026 系列导航，优先放在 content/posts/game/client/phaser/2026/。
• 新文件名使用英文 kebab-case，并与 slug 保持一致。
• title 和正文使用简体中文。
• 已发布文章不要改文件名；如果必须改，先确认是否需要重定向或保留旧 URL。
• 维护页、专项页和总导航页不计入“文章总数”，文章总数只统计具体 Phaser 开发文章。

更新总导航检查项

修改 Phaser 2026 游戏开发专题导航 时，逐项检查：

• description 中的月份范围和文章数量是否正确。
• “专项入口”是否需要新增专项页或调整覆盖范围。
• “专题速览”的分类篇数是否正确。
• 新文章是否只出现在一个主分类表里。
• “按月份回看”的月份篇数和日期排序是否正确。
• “后续维护规则”是否仍然符合当前规模。
• 如果新增文章导致总量超过 150 篇，不要继续扩大总导航表格密度，优先拆新专项页。

更新专项页检查项

修改任一专项页时，逐项检查：

• description 是否准确描述当前覆盖范围。
• “怎么读”是否仍然是一条合理的工程推进路径。
• “快速定位”里的分组篇数是否等于下方表格篇数。
• 每个分组是否有清晰边界，是否出现“其他”“杂项”这类不可维护分组名。
• 表格里的发布日期是否来自文章 front matter。
• 专项页回链总导航，便于读者从深页返回总览。

校验命令建议

不要因为维护导航就直接跑完整 hugo --gc --minify。如果只是 Phaser 内容导航变更，优先使用限定目录校验。

perl -ne 'if(/[ \t]$/){print "$ARGV:$.:$_"; $bad=1} END{exit($bad?1:0)}' content/posts/game/client/phaser/2026/*.md
git diff --check -- content/posts/game/client/phaser/2026

限定 Hugo 解析可以用临时站点复制 Phaser 内容：

tmp=$(mktemp -d)
mkdir -p "$tmp/content/posts/game/client"
cp hugo.toml "$tmp/hugo.toml"
cp -R content/posts/game/client/phaser "$tmp/content/posts/game/client/"
hugo list all -s "$tmp" > "$tmp/list.csv"
wc -l "$tmp/list.csv"

如果新增文章涉及 Mermaid、图片或 front matter 字段，再额外检查代码块闭合、图片路径和 mermaid: true 是否符合页面实际需要。

维护记录格式

后续每批新增文章完成后，可以在提交说明或工作记录里使用下面格式：

新增范围：2026 年 X 月，N 篇
总导航：新增到 X-Y 月，共 N 篇文章
主分类变化：输入与设备 +1，性能与发布 +2，……
专项页变化：性能与发布专项 +2；关卡与内容工具专项无变化
是否新增二级分组：否
校验：链接检查通过，git diff --check 通过，限定 Hugo 解析通过

这个格式的价值在于让下一次维护能快速知道“上次为什么这么归类”，而不是重新读完整个系列。