自建博客步骤，导入内容后标题与文件错位如何核对对应关系
📱 CCBot/2.0 (https://commoncrawl.org/faq/)
🔗 /f4d9a0067e1b.html
📄
自建博客步骤，导入内容后标题与文件错位如何核对对应关系
先给结论：导入后标题与文件错位，多数不是导入程序随机打乱，而是“标题来源”和“文件名来源”在批次内被分别排序或分别截断。核对时不要逐篇凭记忆比对，而要先给每篇内容建立一个与标题、文件名都无关的稳定标识，再用这个标识把两侧重新对齐。下面用一个假设情境把决策过程走一遍。
假设情境：三十篇旧文导入后错位
假设你从旧站导出了三十篇文章，每篇有标题、正文和原文件名。导入新博客后，列表里标题顺序和文件顺序对不上，正文本身没有丢。你已经试过重新导入一次，结果错位依旧。这个现象说明问题不在单次操作失误，而在导入流程里存在两个各自独立的排序或命名环节。
此时先不要动数据库，也不要批量改标题。先抽三篇做核对，判断错位属于哪一类：是标题整体后移一位，还是部分标题被截短后与其他文件重名，还是文件名里的序号与标题里的序号来自不同批次。三类原因的核对动作不同。
先确认标题与文件名各自来自哪里
导入工具通常把标题当作一个字段，把文件名当作另一个字段，两者可能来自同一份导出文件的不同列，也可能一个来自正文首行、一个来自压缩包目录。核对时先找出这两个来源：
- 标题如果来自正文首行，导入后可能被清洗规则去掉前缀，导致与原文件名不再对应。
- 文件名如果来自导出目录，压缩或解压过程可能改变排序，尤其是带中文序号或日期的文件名。
- 若导出文件本身按修改时间排序，而导入按标题字母排序，两侧顺序天然不同，错位是排序差异而非数据丢失。
判断方法：取错位最明显的一篇，分别记录它的标题、正文首行、原文件名、导入后文件名。如果正文首行与原文件名一致，而显示标题是另一篇的，问题出在标题字段映射；如果正文首行与显示标题一致，只是文件名变了，问题出在文件命名环节。
用一个稳定标识重建对应关系
标题和文件名都可能被修改，所以核对时要引入第三个字段作为锚点。常见可用的锚点包括原始发布时间、正文中唯一的编号、导出文件里的自增ID。假设你的旧文正文末尾都带一个形如 <!-- post-017 --> 的注释，这就是最理想的锚点。
具体动作：从导入结果中导出标题、文件名、正文三段，用脚本或表格公式提取每篇正文里的锚点，再按锚点排序。排序后如果标题与文件名同时恢复一致，说明之前只是排序错位；如果锚点相同但标题不同，说明标题在导入时被覆盖或串位，需要回到导入映射设置检查。
这个动作的结果会直接决定下一步：排序问题只需固定导入时的排序字段；字段覆盖问题则要停用当前的标题映射规则，改用锚点或原始ID作为匹配键重新导入。
处理标题被截断造成的假错位
另一种容易被误判为错位的情况，是长标题在导入时被截断到固定长度，截断后两篇标题开头相同，列表看起来像互相错位。核对方法是比较标题长度：如果多篇显示标题都在同一字符数附近结束，而原始标题更长，就属于截断而非错位。
此时先不要改标题，而是检查导入环节是否有标题长度限制或数据库字段长度限制。假设字段限制为五十个字符，而你有一批标题超过这个长度，那么截断后的标题可能失去区分度。解决顺序是先把字段容量调够，再重新导入，最后才考虑手工补全标题。若先手工改标题，重新导入时又会被再次截断，前面的修改就白费了。
核对完成后如何验证对应关系已恢复
修正后不要只看列表顺序，要抽三类样本验证：一篇标题最长的、一篇标题最短的、一篇文件名带特殊符号的。对每篇检查标题、正文首行、锚点三者是否指向同一内容。三类都通过，再批量检查其余文章。
需要提醒的是，导入前后列表顺序变化本身不能单独证明对应关系已正确，也不能单独证明导入失败。排序规则、缓存、分页展示都可能让顺序看起来不同。真正可靠的证据是锚点与标题、正文三者一致，而不是列表第几篇显示第几个标题。
把锚点核对做成一次性的检查脚本或表格模板，以后再导入新批次时先跑一遍，就能在改标题之前发现错位，避免把排序问题误当成内容问题反复返工。
