个人博客建站步骤，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /da3b423202ce.html
📄
个人博客建站步骤，旧系统字段无法完整迁入时怎样决定保留项
先给结论：不要按“字段能不能搬”决定去留，而要按“这个字段是否还在支撑一个当前可见的读者动作”决定。把每个旧字段写成一条可核对的事实记录，由提出保留的人说明它影响哪个页面、哪个动作、谁来判断对错，再决定保留、改写还是退出。迁移工具报错、导入条数变少或某字段在新系统里为空，都只能说明搬运过程有问题，不能单独证明该字段该留还是该删。
先分清三种处理，不要把所有分歧都塞进“保留”
旧字段无法完整迁入时，实际只有三种处理：保留原字段并继续写入；改写成新结构下的替代字段；退出，不再作为独立字段存在。三种处理适用的前提不同。
- 保留适用于该字段仍被某个前台页面直接读取，且读者能感知到它的存在。例如文章页仍显示“写作地点”，而你的读者确实会按地点筛选。
- 改写适用于信息还有价值，但旧粒度已经没人单独使用。例如旧的“心情标签”可以并入更宽的分类，而不是继续维护一套只有作者看得懂的枚举值。
- 退出适用于字段只服务于旧后台的某个流程，前台从未展示，也没有任何查询或导出依赖它。
把这三类混在一起讨论，最常见的后果是：所有人都在争“要不要保留”，却没人说清保留之后谁来填、填了给谁看。
把分歧转成可以核对的项目记录
多个角色对同一字段有不同理解时，争论往往停留在“这个字段很重要”这种无法验证的判断上。可以把它改写成一条固定结构的记录，让每个角色填自己那部分。
- 字段名与旧含义：用一句话写清它在旧系统里代表什么，避免同名不同义。
- 可见位置：它出现在哪个页面、哪个位置。如果写不出具体页面，保留的理由就弱了一半。
- 读者动作：读者看到它之后会做什么，例如按它筛选、复制它、忽略它。
- 写入者：以后由谁负责填，是每篇都填还是偶尔填。
- 判断对错的方式：怎样算填错。例如日期格式不一致、枚举值超出范围。
这份记录的作用不是走流程，而是让“我觉得重要”变成“它出现在文章页顶部，读者会按它筛选，我负责填，填错表现为格式不统一”。一旦写到这个程度，很多分歧会自然收敛。
用一条假设例子看清取舍
假设旧系统有“阅读时长”字段，由作者手工填写，迁移时新系统没有对应位置。三位参与者意见不同：作者认为它体现内容价值，编辑认为读者不看，开发认为可以自动算。
按上面的记录核对：它出现在文章页标题下方；读者动作不明确，没有筛选或排序依赖它；写入者是作者，但经常漏填；判断对错的方式是手工估值与实际阅读时间偏差较大。此时更合理的处理是改写：不再作为手工字段保留，而是由正文字数换算出一个估计值，或者干脆退出前台展示。
如果核对结果是：它出现在列表页，读者会按它筛选短文章，且每篇都必须填——那才值得保留，并接受迁移时逐条补录的成本。这个例子的重点不是“阅读时长该不该留”，而是同一字段在不同可见位置和读者动作下，结论可以完全相反。
迁移异常不能直接当成删除依据
导入后字段为空、条数变少或工具报错，常被当成“这个字段没用”的证据。但这些现象还有别的合理解释：旧数据本身就有大量空值；编码或格式不兼容导致部分记录被跳过；导入脚本只处理了部分表；字段在新结构里被合并到了另一个名称下。
因此，看到异常时先做一次对照：从旧系统导出该字段的非空记录数，再与新系统对应位置的非空记录数比较。如果两边都很少，说明它本来就不是高频字段，退出更省事；如果旧系统里大量有值而新系统为空，那是迁移问题，不是取舍问题，应先修复搬运再决定去留。
决定之后要留下可复查的痕迹
无论保留、改写还是退出，都建议在项目里留一条简短说明：字段名、处理方式、理由、负责人。这样做的实际结果是，下次有人再问“这个字段为什么没了”，不必重新争论一遍，直接看记录即可。如果选择保留，下一步动作是把补录责任落到具体的人和时间段；如果选择改写，下一步是确认新字段的取值规则；如果选择退出，下一步是检查前台模板里是否还有残留调用，避免页面出现空白或报错。
取舍的标准始终是读者能否感知、由谁维护、出错时如何核对，而不是迁移工具是否顺利跑完。
