📍 WDQWDWQD987AAAAA:216.73.216.246
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d3908510c523.html
📄

个人博客建站 - 网址规划先定维护需求：多人协作不返工的路径设计

个人博客建站时，网址规划应先满足维护需求，而不是先追求好看。多人协作、需要交付清楚的场景下，最该保住的维护需求是：链接长期稳定、栏目可增删而不改旧地址、文章归属清晰、迁移时能批量对应。做法是先定一套不会随人员变动而失效的路径规则，再选具体形式。验收信号是：换作者、换栏目名、换生成工具时，旧链接仍能打开或可批量映射，新成员看一遍规则就能自己发文章。

先区分两类地址：内容地址与功能地址

内容地址指向一篇具体文章，功能地址指向分类、标签、归档、作者页等由系统生成的列表。维护需求主要压在内容地址上，因为它一旦发布就可能被引用、被收藏、被搜索引擎收录。功能地址可以随栏目调整而变化，但内容地址不应跟着变。

• 内容地址：建议包含稳定且唯一的标识，例如日期加短标题，或直接用一个不重复的编号。
• 功能地址：分类、标签、分页可以带层级，但不要把它们嵌进内容地址里，否则改分类就会连带改文章链接。

判断结果：如果一篇文章的地址里出现了分类名，那么以后调整分类时，这篇文章的地址就会被迫改变，维护成本立刻上升。

多人协作下必须写进规则的几件事

多人协作的返工，多数不是技术问题，而是规则没写清。交付前应把下面几项固定成文字，放在协作文档里，而不是留在某个人的记忆里。

1. 标识生成方式：标题转成的短标识由谁定、是否允许手动改、重复时怎么加后缀。
2. 大小写与符号：统一用小写，空格用连字符，避免下划线、中文和特殊符号混用。
3. 层级深度：内容地址是否带目录层级，带几层，超出后如何处理。
4. 改名规则：文章标题可以改，但地址默认不改；确需改时，必须登记旧地址与新地址的对应关系。
5. 废弃处理：删除或合并文章时，旧地址是保留跳转还是返回特定状态，由谁执行。

验收信号：任意一位协作者按规则新发一篇文章，不需要问人就能得到符合规范的地址；另一位协作者检查时，能逐条对照规则判断对错。

用一张对照表决定路径形式

假设有三种候选形式，可以按维护需求逐项比较。以下为示例，不是真实项目结论。

• /2025/03/hello-world：日期加短标识。优点是唯一性好、便于归档；缺点是日期写错后地址显得别扭，但不影响维护。
• /posts/hello-world：固定前缀加短标识。优点是简洁、与分类解耦；缺点是全部文章挤在同一层，数量大时人工查找稍慢。
• /tech/web/hello-world：分类层级加短标识。优点是地址本身能看出归属；缺点是改分类就要改地址，维护成本最高。

适用条件：如果栏目经常调整、协作者较多，优先选前两种与分类解耦的形式。如果栏目极其稳定、且明确接受改分类时同步改地址，才考虑第三种。判断结果：把“分类是否会变”作为第一道筛选，比比较地址长短更有意义。

迁移与交接时的检查项

网址规划的维护价值，在迁移和交接时最明显。更换生成工具、更换托管方式、增加协作者之前，先做一次检查。

• 列出所有已发布内容地址，确认没有重复，也没有仅靠大小写区分的地址。
• 确认旧地址与新地址之间是否存在可批量生成的对应关系，而不是逐条手工修改。
• 确认功能地址变化时，内容地址不受影响。
• 确认协作文档里的规则与实际生成的地址一致，没有“文档写一套、实际做一套”。

如果检查中发现地址里混入了分类名、作者名或临时编号，就说明它绑定了易变信息，应在下次发布前改为稳定标识，并登记旧地址的对应关系。

下一步怎么做

先写出一页网址规则，只包含标识生成方式、大小写与符号、层级深度、改名与废弃处理四项，然后让一位协作者按这页规则试发一篇文章。若对方无需追问即可完成，且你能对照规则指出每一处是否符合，这套规划就达到了减少返工的维护要求；若出现追问，就补进规则再试一次。