绍兴网站开发，旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2ac432f82f35.html
📄
绍兴网站开发，旧系统字段无法完整迁入时怎样决定保留项
结论先给：字段能不能保留，不看它在旧库里是否重要，而看它在新站上是否有明确的展示位置、录入入口和后续维护人。三者缺一，就应转入归档而不是硬迁。这个判断只在旧数据仍可读、且新站字段结构已经冻结的前提下成立；如果新站结构还在改，任何保留决定都会返工。
先判断字段的三种去向，而不是先排序重要性
面对迁不进去的字段，把它们分成三类比打分更有效：继续使用、只读展示、离线归档。继续使用要求新站有对应的录入界面和校验规则；只读展示只要求前台有位置，后台不需要编辑；离线归档则完全不进新库，只留一份可检索的导出文件。
区分这三类的证据来自三个问题：这个字段的更新频率是多少？谁负责更新？如果一年没人改，业务是否照常运转？更新频率低且无明确责任人的字段，即使内容量很大，也不该占用新站的表结构。
让结论失效的反例：字段本身没价值，但它是别处的关联键
常见的误判是把“没人看”等同于“可以丢”。假设旧系统里有一个内部编号字段，前台从不展示，运营也从不查询，看起来该归档。但如果旧订单、旧工单或对账文件里引用的都是这个编号，一旦丢弃，后续想按编号回溯历史记录就断了线索。
反过来也成立：某个字段内容量极大、看着很重要，但它只是旧版页面模板的排版残留，新模板不再需要这种结构，那么迁移它只会增加清洗成本。判断依据不是字段大小，而是它是否被其他数据引用、是否出现在对外凭证上、是否被第三方系统读取。
按“展示位置—录入入口—维护人”三问逐项过筛
对每个待定字段依次问：
- 新站哪个页面会显示它？如果没有页面，能否接受它只出现在导出文件里？
- 后台有没有对应的编辑控件？没有控件意味着以后只能改数据库，这通常不可接受。
- 谁负责在内容变更时同步更新？答不出具体角色，就该归入归档。
三问全部有答案的字段进入继续使用；只有第一问有答案的进入只读展示；其余进入离线归档。这个顺序能避免先按业务重要性争论，再发现根本没有落地位置。
一个假设例子：把决定变成可复查的记录
假设某旧站有“设备出厂批次”字段，共约两千条记录，前台不显示，后台可编辑，但近两年无人修改，也没有对外单据引用它。按三问过筛：新站没有展示位置，后台可以不做控件，维护人无法指定，因此归入离线归档，导出为带原编号的表格文件，并在迁移说明里记录归档原因和文件位置。
如果同一批数据里另有一个“服务到期日”字段，前台需要显示、后台需要可改、由客服组负责更新，那么它进入继续使用，并需要在迁移前确认日期格式和时区处理方式。两个字段的处理差异，来自三问结果不同，而不是数据量不同。
决定之后立刻做的一件事：写迁移映射表并冻结
把每个字段的最终去向写进一张映射表，包含旧字段名、新字段名或归档文件名、处理方式、负责人。写完当天就与内容、运营、客服确认一遍，确认后冻结。冻结的作用是让后续开发不再反复讨论字段取舍，把精力放在清洗和校验上。
冻结之后如果仍有人提出恢复某个归档字段，处理方式不是直接改表，而是先补上展示位置、录入入口和维护人三项中的缺失项，再走一次同样的过筛。这样字段取舍就从一次性争论，变成可重复执行的流程。
