字段丢失往往在映射规则编写时就已埋下：源字段没列全、无目标字段的字段被默认跳过、类型和枚举规则写错，直到迁移完成后才被发现。要把问题前移到规则阶段，需要把一次性的Excel人工对照升级为可校验的规则集，让每个源字段都有明确归属，并在预检中暴露缺口。本文聚焦数据内容层面的字段映射，流程与插件行为迁移、迁移后结果核验不在讨论范围内。
要点总览（TL;DR）
- 字段丢失多在映射规则编写阶段埋下，预防的关键是把一次性人工对照表升级为可机器校验的规则集，让每个源字段都有明确归属。
- 先导出源系统全部字段形成基线清单，作为覆盖率分母；自定义字段、历史遗留字段和多值字段都要枚举在内。
- 规则表除源字段与目标字段外，应声明是否必填、长度上限、枚举覆盖、默认值，并对无目标字段的源字段显式登记映射、合并、暂存或确认丢弃。
- 设置必填校验、类型校验和枚举覆盖校验三类机制，先用样例数据试跑，再做全量预检，以覆盖率100%为通过标准。
- 效果验证看组合指标：预检拦截数上升、迁移后补录数下降，并辅以抽样比对核对字段值是否与源一致。
当前映射做法与预防目标
多数团队的字段映射仍以一张Excel对照表为主：左边列源字段，右边填目标字段，由熟悉两边系统的人逐行核对。这张表能支撑一次迁移，却很难支撑校验，因为它记录的是“对应关系”，没有记录“规则”。是否必填、字段类型是否一致、枚举值是否覆盖完整、没有目标字段的源字段怎么处理，这些信息通常留在编写者的经验里，换一个人复核就无从判断对错。
这种做法的直接后果是，字段丢失只能在迁移完成后通过业务反馈发现。此时数据已经写入目标系统，补录成本高，部分历史数据甚至难以追溯原始值。
本文的预防目标可以归纳为三条，后续改进动作都围绕它们展开：
- 源字段100%有归属：每一个源字段在规则表中都有一行记录，要么映射到目标字段，要么登记为合并、暂存或确认丢弃，不存在“表里没有、实际被跳过”的字段。
- 映射规则可机器校验：必填、类型、长度、枚举、默认值以结构化字段声明，能够被脚本或工具批量检查，减少对人工记忆的依赖。
- 丢失在预检阶段暴露：正式迁移前用样例数据和全量字段清单做比对，未覆盖字段在规则阶段就被拦截，而不是留到迁移后。
需要说明的是，这里讨论的是数据内容如何从源字段落到目标字段。工作流、插件行为的迁移，以及迁移完成后的结果核验与切换管理，属于另外的工作，本文不展开。
字段丢失在映射规则阶段的常见成因
字段在规则阶段被漏掉，原因可以分成两类：规则缺失，即该有的规则没写；规则写错，即写了但内容不对。两类问题的表现不同，排查方式也不同。
| 成因类别 | 具体表现 | 典型后果 |
|---|---|---|
| 规则缺失 | 源字段清单不完整，自定义字段、历史遗留字段、多值字段未被枚举 | 字段从未进入对照表，迁移时被整体跳过 |
| 规则缺失 | 无目标字段的源字段未登记处置方式 | 隐式丢弃，无人知晓该字段已丢失 |
| 规则写错 | 类型不匹配，如源为多选、目标为单选 | 值写入失败或被截断 |
| 规则写错 | 枚举值未覆盖，源系统存在目标枚举中没有的选项 | 部分记录该字段为空 |
| 规则写错 | 必填与可空方向颠倒 | 目标必填字段出现空值，或本可保留的空值被强制填充 |
| 规则写错 | 同名不同义，字段名相同但语义不同 | 错误合并，两类数据混入同一字段 |
其中“隐式丢弃”最容易被忽视。源系统里有些字段在目标系统确实没有对应项，比如某些内部统计字段或已废弃的流程标记。如果规则表里不写这一行，迁移脚本通常会直接跳过，事后既没有记录，也没有人负责判断这个字段该不该保留。把它显式登记为“确认丢弃”并注明原因和确认人，与悄悄跳过是两种完全不同的状态。
“同名不同义”则需要单独核对语义而非字段名。两个系统都叫“优先级”的字段，取值集合和业务含义可能并不一致，直接按名称映射会把不同口径的数据合并到一起，这类问题在迁移后表现为数据“看起来都在，但用起来不对”。
优先改进动作：把映射规则做成可校验的规则集
改进的核心是把对照表改造成规则表，并配套预检步骤。以下动作按执行顺序排列，前一步的产物是后一步的输入。
第一步：建立源字段全量基线清单
从源系统的字段配置中导出全部字段，包括系统字段、自定义字段、历史遗留字段和多值字段，形成基线清单。这份清单是后续覆盖率的计算分母，必须完整，否则覆盖率再高也说明不了问题。导出后建议与业务方核对一遍，确认没有遗漏仍在使用的字段。
第二步：为每条映射声明规则
规则表在“源字段—目标字段”之外，增加结构化规则列。可参考以下字段结构填写：
| 列名 | 填写内容 | 作用 |
|---|---|---|
| 源字段名 / 源类型 | 源系统中的字段标识与数据类型 | 基线定位 |
| 目标字段名 / 目标类型 | 目标系统中的对应字段与类型 | 映射目标 |
| 是否必填 | 必填 / 可空 | 校验空值方向 |
| 长度上限 | 目标字段允许的最大长度 | 拦截截断风险 |
| 枚举值覆盖 | 源枚举值与目标枚举值的对应清单 | 检查未覆盖选项 |
| 默认值 | 源值为空时写入的默认值 | 处理空值场景 |
| 无目标字段时的处置 | 映射 / 合并 / 暂存 / 确认丢弃 | 显式登记，避免隐式跳过 |
| 责任人 | 该条规则的确认人 | 规则维护与追溯 |
“无目标字段时的处置”这一列是预防丢失的关键。四个选项对应四种明确状态：映射表示找到对应字段；合并表示与另一源字段共同写入同一目标字段，需注明合并规则；暂存表示先落到临时表或中间结构，待后续处理；确认丢弃表示业务确认不再保留，需记录确认人和原因。任何一行都不应留空。
第三步：设置三类校验
- 必填校验：检查目标必填字段在源侧是否有值来源，以及源值为空时是否配置了默认值。方向颠倒的情况在这一步暴露。
- 类型校验：逐条比对源类型与目标类型，多值对单值、文本对枚举等不匹配组合标记为待处理，不允许直接放行。
- 枚举覆盖校验：取源系统该字段的实际取值集合，与规则表中登记的枚举对应清单比对，未覆盖的值单独列出，由责任人补充映射或确认丢弃。
第四步：样例数据试跑与全量预检
先用一批覆盖各类取值的样例数据跑一遍映射，观察字段值是否正确落位，重点看空值、多值、超长文本和枚举边界值。样例通过后，再做全量预检：以第一步的基线清单为分母，逐项核对规则表中每个源字段是否都有归属，统计覆盖率并列出未覆盖字段。预检通过的标准是覆盖率达到100%，且不存在未登记处置方式的字段。
规则表和预检记录需要有固定的承载位置，避免散落在个人电脑里。在ONES中，可以把映射规则表作为文档维护在项目知识库中，把预检发现的未覆盖字段登记为工作项，指定责任人跟进，处理完成后再关闭。这样规则版本、问题状态和处理记录都在同一处，复核时可以直接追溯。ONES的Jira迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，并把数据完整作为迁移目标之一，正式迁移前需要确认数据范围；具体的映射规则配置方式和校验能力，以实际迁移方案为准。
适用前提与代价
这套做法成立需要几个前提。第一，能够拿到源系统的完整字段清单和样例数据，如果源系统已下线或权限受限，基线清单就无从建立。第二，目标系统的字段结构在规则编写前已经确定，否则规则表需要反复返工。第三，有熟悉两边业务语义的人参与枚举对应和同名字段的语义核对，纯技术人员难以判断业务口径差异。
代价同样需要提前说明：
- 前期投入增加：字段梳理、规则编写和枚举核对会占用迁移准备阶段的时间，字段数量多时工作量明显上升。
- 需要持续维护：规则表不是一次性文档，源系统新增字段或目标结构变更时都要同步更新，需要指定责任人。
- 存在能力边界：目标系统确实没有对应字段时，只能在暂存和确认丢弃之间选择，强行映射到语义相近的字段会制造新的数据问题。这条边界无法通过规则设计突破。
如果迁移范围很小、字段数量有限，人工对照加一次复核可能已经够用，不必完整引入规则表。字段多、自定义字段多、需要多次迁移的场景，投入这套机制更划算。
效果验证：如何判断字段丢失确实减少了
验证要回答的问题是：字段丢失是否真的减少了，而不是迁移整体看起来更顺利了。可以从三个口径观察。
| 验证口径 | 计算方式 | 观察方向 |
|---|---|---|
| 映射覆盖率 | 规则表中已有明确归属的源字段数 ÷ 基线清单字段总数 | 目标为100%，未达100%时逐项列出缺口 |
| 预检拦截数 | 预检阶段发现并处理的未覆盖、类型不匹配、枚举缺失问题数 | 该数字上升，说明问题在规则阶段被拦住 |
| 迁移后补录数 | 迁移完成后因字段缺失而补录或修正的记录数 | 该数字下降，与预检拦截数上升形成对照 |
除了数量统计，还需要做抽样比对：从源系统抽取一定数量的记录，逐字段核对迁移后的值是否与源一致，重点覆盖多值字段、枚举边界值和空值记录。抽样比对能发现“字段在但值不对”的情况，这类问题不会体现在覆盖率里。
需要提醒的是，预检拦截数上升本身不是坏事，它反映的是问题暴露位置的前移。判断改善应以“预检拦截数上升、迁移后补录数下降”这一组合为准，单独看任一数字都可能得出错误结论。上述口径的具体数值应来自本方每次迁移的实际记录，与上一次迁移对比才有意义，不宜套用外部结论。
常见问题
源系统已经下线或权限受限，拿不到完整字段清单怎么办？
基线清单是整套规则的分母，缺失时覆盖率统计会失真。可行的替代路径是从历史导出数据、接口文档、数据库表结构或旧系统截图里重建字段清单，再请熟悉原系统的业务方逐项确认。重建的清单应标注来源和确认人，并在规则表中注明“清单可能不完整”这一前提。如果连重建都做不到，建议把验证重心放到迁移后的抽样比对上，同时接受规则阶段拦截能力有限的事实。
目标系统确实没有对应字段，暂存和确认丢弃该怎么选？
判断依据是该字段的数据是否还有业务用途。仍可能被查询、统计或审计使用的字段，选暂存，先落到临时表或中间结构，保留原始值以便后续处理；已废弃的流程标记、内部统计字段等确认不再需要的，选确认丢弃，并记录确认人和原因。两种选择都要在规则表中占一行，避免隐式跳过。强行映射到语义相近的目标字段会制造口径混乱，不建议作为折中方案。
字段数量不多的小范围迁移，也需要建完整的规则表吗？
不必一律套用。迁移范围小、字段数量有限、只做一次迁移的场景，人工对照加一轮复核通常够用。规则表的投入在字段多、自定义字段多、需要多次迁移或长期维护映射关系时更划算，因为规则可以复用和批量校验。判断标准可以看两点：源字段里自定义字段占比是否较高，以及未来是否还有第二次迁移。满足其一，建规则表的收益就更明显。
预检通过、覆盖率达到100%，迁移后就一定不会丢字段吗？
覆盖率100%说明每个源字段都有明确归属，但不保证字段值正确落位。类型转换、枚举对应、多值拆分等环节仍可能出错，表现为“字段在但值不对”。因此预检之后还需要抽样比对：从源系统抽取记录，逐字段核对迁移后的值，重点覆盖多值字段、枚举边界值和空值记录。覆盖率解决的是字段有没有的问题，抽样比对解决的是值对不对的问题，两者配合才能较完整地验证。
规则表和预检记录放在哪里维护比较合适？
关键是集中存放、有版本、可追溯，避免散落在个人电脑里。常见做法是把规则表作为文档维护在项目知识库中，预检发现的未覆盖字段登记为工作项并指定责任人，处理完成后再关闭。在 ONES 中，可以用文档承载映射规则表，用工作项跟踪未覆盖字段的处理状态，规则版本和问题处理记录在同一处可查。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，并把数据完整作为迁移目标之一，正式迁移前需要确认数据范围；具体的映射规则配置方式和校验能力，以实际迁移方案为准。
