怎么创建自己的博客：导入内容后标题与文件错位如何核对对应关系
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /c50820955517.html
📄
怎么创建自己的博客：导入内容后标题与文件错位如何核对对应关系
先别急着重新导入。把“标题”和“文件”各当成一份独立清单，用两边都稳定存在的字段做锚点，先建立一对一映射，再处理对不上的那几条。缺少后台数据或权限时，你仍然可以完成这套核对：只需要导出标题列表、文件列表，以及少量页面源码或渲染结果，就能判断错位是发生在导出顺序、文件名规则，还是标题字段本身。
先确定用哪个字段做锚点
标题和文件错位，本质是两份清单的排序或取值不一致。核对前先选锚点，优先级从高到低：
- 文件内唯一标识：如文章源码里的永久链接、front matter 中的 slug、数据库导出的 ID。它通常不随标题修改而变，是最稳的锚点。
- 文件路径或文件名：适合文件名由固定规则生成的博客，但要先确认改名后是否同步更新。
- 标题本身：最不稳定，因为标题可能被手工润色、批量替换或截断，只适合做辅助验证。
如果三样都拿不到，只能退到“标题+创建时间”组合。此时要接受一个结论边界：能确认对应关系，但不能确认哪一边才是正确值。
把两份清单整理成可比较的形式
假设你导出了 40 篇文章的标题，博客目录下有 40 个 Markdown 文件。先做最小动作：把标题按导出顺序编号，把文件按文件名排序编号，然后逐行对照。常见结果有三种。
- 整体错位一位：通常来自导出时多了一行表头、少了一篇草稿，或文件列表里混入了非文章文件。
- 局部错位：中间某几篇开始整体偏移，说明之前有一篇被删除、合并或改名，后续序号全部顺延。
- 随机错位：标题和文件各自成对，但顺序不同，多半是排序规则不同，比如一边按标题拼音、一边按文件修改时间。
这一步的结果直接决定下一步：整体错位先查清单边界，局部错位先定位断点，随机错位先统一排序规则，不要一上来就逐篇改标题。
用页面源码验证单条对应关系
对疑似错位的条目，打开对应页面，查看渲染后的标题和源码中的标识是否一致。例如源码里可能出现：
<link rel="canonical" href="/posts/example-slug">
如果这个 slug 与文件名一致，但页面显示的标题属于另一篇，说明标题字段在导入或模板取值时被串了；如果 slug 与文件名不一致，说明文件本身被改过名或复制过。两种情况的修复方向不同，前者查数据映射，后者查文件操作记录。这个动作不需要后台权限，只要能访问页面即可完成。
缺少完整数据时能得出什么、不能得出什么
当你只有标题列表和文件列表，没有数据库或导入日志时，可以确认“哪条标题对应哪个文件”，但无法确认错位发生在导入前还是导入后。可以确认“某几条对不上”，但不能据此推断整个博客的内容都不可信。
一个常见误判是：看到导入后标题顺序变了，就认为导入程序有 bug。实际上，导出工具按标题排序、文件系统按名称排序、页面按发布时间排序，都会产生不同顺序，而内容本身没有错。核对时先记录你用的是哪种排序，再比较。
修正后如何确认对应关系已经稳定
修正动作建议只做一类：统一锚点。比如把每篇文件的 slug 写入标题清单，作为唯一对照列；或把文件名统一改为 slug，再重新导出一次标题列表。改完后重新对照一遍，重点看之前错位的那几条是否落在正确位置。
要注意，前后两次对照的差异可能来自排序规则变化，而不是修正本身生效。比较时保持导出条件一致，并记录修改前后的清单版本。如果两次结果仍然错位，说明锚点选错了，应换回文件内唯一标识重新核对，而不是继续改标题。
核对完成后，把这份对照清单保留下来。下次再导入内容时，先用同一锚点跑一遍最小对照，就能在标题和文件再次错位前发现断点。
