三亚网站开发：旧系统字段无法完整迁入时怎样决定保留项
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6e0fee84402f.html
📄
三亚网站开发：旧系统字段无法完整迁入时怎样决定保留项
先给出结论：字段无法完整迁入时，不要按“旧系统里有什么”决定保留项，而要按“新站上线后哪些字段会直接影响用户完成动作或影响后续数据可追溯”来分两档处理。能拿到完整字段清单和业务确认的，做逐字段映射并明确丢弃项；拿不到完整清单或数据库权限的，先冻结字段结构，只迁移可验证的核心字段，把剩余字段以只读方式暂存，等业务方确认后再补。两种条件下的动作不同，但都不能凭字段数量或表结构相似度直接判断该留谁。
条件一：能拿到完整字段清单和业务确认时，按用途分三档
这种情况下你有条件做完整对照，判断依据不是字段新旧，而是它在旧站里承担什么职责。可以先把所有字段分成三档：
- 必留：用户提交、订单、会员身份、内容正文、发布时间、状态标记。这些字段一旦缺失，新站要么无法完成业务流程，要么无法判断一条记录是否有效。
- 可转换：旧系统用编码或枚举存的值，比如状态码、分类 ID、地区码。它们不必原样保留，但必须保留可还原的对应关系，否则迁移后无法解释旧数据。
- 可丢弃：重复统计字段、仅用于旧后台展示的冗余列、已经失效的临时标记。丢弃前要确认没有下游报表或导出脚本依赖它。
实际动作是：先导出字段清单，逐条标注上述三档，再让业务方确认“可丢弃”那一档。确认结果会直接决定下一步——如果业务方对某个字段的用途说不清，就把它从可丢弃移回可转换，先保留映射关系，而不是当场删掉。这一步的影响是：新站字段结构会因此多出一批待定字段，但避免了上线后才发现某张报表取不到数。
条件二：缺少完整数据或权限时，先冻结结构再迁移可验证字段
拿不到数据库权限、拿不到字段说明文档，或者旧系统已经无法登录后台，这时不要试图一次性还原全部字段。可执行的最小动作是：
- 只迁移能从现有导出文件、页面内容或接口返回中直接验证的字段，例如标题、正文、发布时间、可见状态。
- 把无法验证的字段以只读形式暂存在一张独立表里，保留原始值和来源标识，不并入新站主表。
- 在新站字段结构中预留扩展位，但不提前为不确定字段建正式业务列。
这样做的影响是：新站可以先行上线并正常运转，未确认字段不会污染主数据结构。后续一旦拿到权限或业务确认，再按条件一的方式补映射。需要说明的是，导出文件里字段为空、接口返回字段缺失、抓取不到某段内容，这些现象都不能单独证明该字段无用——它也可能是权限不足、导出范围受限或旧系统本身就没存。因此不能以“迁不过来”为由直接判定丢弃。
判断保留项时，用三个可区分的证据来源
决定保留谁，靠的不是感觉，而是三类能互相区分的证据：
- 业务动作证据：这个字段是否参与用户提交、支付、登录、内容发布等动作。参与则必留。
- 追溯证据：缺少它之后，是否还能解释一条历史记录的来源、状态变化或归属。不能解释则至少保留映射。
- 下游依赖证据：是否有报表、导出、对账或第三方系统在读取它。有依赖则不能直接丢。
三类证据指向不一致时，以业务动作证据优先，追溯证据其次，下游依赖证据最后但必须记录。例如某字段只被旧后台一个统计页面使用，而该页面已停用，那它属于可丢弃；但如果同一字段还被月度对账脚本读取，就必须先保留映射再谈清理。
一个注明假设的短例子
假设旧站有一个“来源渠道”字段，存的是数字编码，新站没有对应字典表，也拿不到旧后台的编码说明。此时不能直接把数字搬进新站，也不能直接删。可行做法是：把原始编码和记录 ID 一起暂存到独立表，新站主表暂不设该字段。上线后如果能从旧页面、导出备注或业务方口中还原编码含义，再补建字典并回填。这个例子的前提是“编码含义暂时不可得”，如果编码说明就在手边，则应直接按条件一完成转换。
例外：哪些字段即使迁不动也要先留占位
有一类字段即使当前无法迁入，也建议在新站保留占位或映射记录，而不是彻底放弃：涉及金额、身份、权限、时间戳和状态变更的字段。原因是这些字段一旦丢失，后续很难从页面内容反推。反过来，纯展示用的排序号、旧模板样式标记、重复的计数字段，在确认无下游依赖后可以放弃。这个例外的适用条件是：你至少能证明该字段曾经参与过业务动作或追溯，而不是仅凭字段名猜测。
最终决定保留项的标准可以归纳为一句：先保证新站能完成当前业务动作，再保证历史记录可解释，最后才考虑字段是否“完整”。缺少权限或数据时，冻结结构、暂存原始值、只迁移可验证字段，是仍可执行的最小动作；它不能推出旧字段无用，只能说明当前还无法确认其用途。
