数据导入交互要让用户依次确认三件事：文件里的列写到哪里、哪些记录符合业务规则、失败记录怎样修正后继续。上传达到 100% 只表示文件传完；只有系统确认写入结果，才能显示“导入完成”。把这几个阶段分开，用户才不会对着一个成功提示反复导入同一批数据。
设计 CRM、订单或资产后台时，可以先搭建包含映射与校验步骤的后台原型，再沿着一份有错误的样表走完整条流程。下面用一个虚构的联系人导入任务，画清从列映射到错误行重导的页面和规则；其中的数据、结果数量均用于设计演示。
先确定这次导入会新增还是覆盖记录
“支持 Excel 导入”还不足以开始画页面。相同的文件，在新增、更新和新增或更新三种模式下，会产生完全不同的结果。Claris 的导入文档也把导入操作与字段映射分开：数据怎样影响现有记录，应在匹配字段前明确。
本例选择“仅新增联系人”。联系人编号是必填文本，并在当前企业内唯一；姓名必填；企业代码必须指向用户有权关联的现有企业；备注可空。已有编号 00024，现有企业代码为 E01、E02。遇到重复编号时拒绝该行，不自动覆盖原联系人。这组规则要同时出现在需求说明、预检和提交逻辑里。
如果业务还需要更新，应提供明确模式并补充“空单元格是保留原值还是清空”的约定。不能根据某行是否匹配到旧记录，就悄悄改变整次导入的含义。一个人只想补录备注，不应因为文件中的空手机号而清空现有联系方式。
映射页同时显示列名、样例值和字段约束
上传完成后，先让用户确认工作表、标题行和少量解析样例。若标题行识别错了，后面再精细的字段匹配也没有意义；CSV 出现整行挤在一列或中文乱码时，应留在解析阶段调整分隔符、编码或更换文件，而不是直接进入业务校验。
下面是这次导入使用的六条数据。原文件第 1 行为标题，因此错误报告中的行号从 2 开始。编号列按文本准备，00021 的前导零属于编号本身。
| 原文件行号 | 联系人编号 | 姓名 | 企业代码 | 备注 |
|---|---|---|---|---|
| 2 | 00021 | 测试甲 | E01 | 新品咨询 |
| 3 | 00022 | 空 | E01 | 回访 |
| 4 | 00023 | 测试丙 | E99 | 询价 |
| 5 | 00024 | 测试丁 | E02 | 补录 |
| 6 | 00025 | 测试戊 | E01 | 展会咨询 |
| 7 | 00026 | 测试己 | E02 | 空 |
这里的“空”表示空单元格，不是要写入的文字。映射页应保留这个区别，并允许查看不止第一条样例，避免第一行恰好完整而掩盖后续空值。
| 源列与样例 | 目标字段 | 需要显示的说明 |
|---|---|---|
| 联系人编号：00021 | 外部联系人编号 | 必填；文本；企业内唯一；保留前导零 |
| 姓名：测试甲 | 联系人姓名 | 必填；映射成功后仍需检查每行是否为空 |
| 企业代码：E01 | 所属企业 | 按企业代码关联已有企业，不按显示名称模糊匹配 |
| 备注：新品咨询 | 备注，或“不导入此列” | 可选；跳过后该列不参与写入 |
自动匹配只提供建议，用户应能看到建议对应到了哪个字段。Microsoft 的数据导入说明展示了查看列映射、处理不匹配列和忽略可选列的做法。设计自己的向导时，还应把“必填字段没有来源”和“某一行必填值为空”分别提示：前者在映射页解决，后者在逐行预检中解决。
字段下拉列表不能只写一个笼统的“不可用”。类型不兼容时说明为什么不能映射；缺少写入权限时说明需联系谁处理。两个源列指向同一目标字段时，也要要求用户选择保留哪一列，除非产品明确支持并展示合并规则。对编号和日期，先展示将要写入的值；不要把 00021 变成 21，也不要擅自判断 03/04 是 3 月 4 日还是 4 月 3 日。若前导零在原文件里已经丢失，应让用户修正源数据，不能靠导入页面猜回去。
预检结果要能解释每一条未通过记录
完成映射后，按钮可以写“校验 6 条记录”。预检尚未写入数据，页面应显示“3 条可导入、3 条需处理”，而不是“成功 3 条”。本例第 2、6、7 行通过；第 3 行缺姓名，第 4 行企业代码不存在，第 5 行编号与已有联系人重复。
把计数与筛选直接关联：点“需处理 3 条”进入错误行列表，列表保留原行号和原始值。错误数量按记录去重，一条记录即使有两个字段错误，也不能被计为两条失败记录；页面可另列“问题 4 项”，但必须标明口径。
| 原行号 | 定位字段 | 原因 | 下一步 |
|---|---|---|---|
| 3 | 联系人姓名 | 该字段必填，当前单元格为空 | 填写姓名后重新校验 |
| 4 | 所属企业 | 企业代码 E99 未匹配到可关联的企业 | 核对代码或先完成企业建档 |
| 5 | 外部联系人编号 | 00024 已存在，本次模式仅新增 | 核对是否同一联系人，选择跳过；如需更新，另发起明确的更新任务 |
对于关联对象，不要把“当前用户无权查看”泄露成一份可搜索的企业名单。是否能展示对象名称，应与现有权限规则一致。无法区分不存在与不可访问时，可以提示“未找到可关联的企业，请核对代码或联系管理员”。
文件内部重复也要提前约定。例如两个联系人都使用 00021，不能默认“第一行获胜”；可以把相关行一并标为冲突，让用户决定保留哪条。这个选择会影响预检数量和错误文件，不能留到研发实现时再决定。
整批拒绝还是部分导入，取决于记录能否独立成立
本例中的联系人相互独立，因此允许用户选择“仅导入 3 条有效记录”，其余 3 条暂不写入。确认区域应同时显示导入对象、仅新增模式、识别键和记录数量，让用户在提交前看到即将发生的动作。
若导入的是必须保持借贷平衡的一批凭证，或主表与明细缺一不可的单据，就不能照搬部分成功。可要求整批通过后才提交，或者按完整单据分组处理。界面上的提交单位要跟业务事务单位一致：一行、一张单据与一个文件不是同一回事。
预检通过也不是最终承诺。预检与提交之间，企业可能被停用，字段要求或用户权限也可能变化。提交时仍需重新核对必要条件；有变化就返回具体失败项。若需要用户重新确认映射，应保留原文件和已经选好的映射关系，指出失效的那一项，而不是把整个向导清空。
错误行文件应支持接着修，不让用户重做整批
假设提交后系统确认第 2、6、7 行均写入，本次结果为“已新增 3 条，未导入 3 条”。结果页提供查看成功记录、下载错误行、继续修正三个明确出口。下载文件保留原业务列，并增加任务编号、原行号、错误字段、错误原因和处理状态；多项错误可以放在同一单元格分条列出，或用单独的问题明细表关联到原行号。
继续这个例子：用户为原第 3 行补上姓名“测试乙”，把原第 4 行企业代码改为 E02；核实原第 5 行确为已有联系人后，选择跳过。再次校验显示“本次待新增 2 条，已跳过 1 条”，再次提交成功后，原任务累计新增 5 条、跳过 1 条。原先成功的 3 条不应重新进入待导入列表。
这个闭环需要两种标识。业务编号用于判断同一联系人，任务内的记录标识用于知道正在修正哪一条源记录；原行号方便人定位，但用户排序或删行后会改变，不能单独作为去重依据。修正文件增加的说明列也应被识别为辅助信息，不能自动映射成业务字段。
用户因网络中断没看到结果时，应先查询原任务状态，而不是直接提交第二次。原型可以展示“正在确认导入结果，请稍后查看此任务”，并保留返回任务详情的入口；重复提交保护和去重处理需要服务端配合，页面上的禁用按钮本身不能保证不重复入库。文件选择和传输阶段的异常，可沿用文件上传进度与失败重试中的设计，再从“解析完成”进入本篇的映射流程。
用五个页面状态评审整条导入路径
在原型里准备解析预览、字段映射、预检结果、正在导入和任务结果五个状态。映射页先让备注处于未处理状态，让评审者选择“不导入此列”；再把姓名字段取消映射，确认必填提示阻止进入预检。恢复映射后，使用上面的六行数据展示三种错误，避免只演示全绿的顺利路径。
随后分别走“返回修改文件”和“仅导入有效记录”两条路径。前者需说明重新上传是否保留同名列的映射；后者需进入任务结果，下载错误行后再回到原任务修正。最后模拟提交时断网和预检后权限失效，检查状态是否仍能解释当前进度、实际写入数量以及可继续的动作。
交付时，把新增或更新模式、唯一键、空值含义、部分成功单位和错误文件字段写在相应页面旁。原型演示的是这些行为约定，不是已经完成真实数据导入。需要把这个向导接回列表、详情和其他后台操作时，可继续查看原型交互专题，保持任务入口、返回位置与现有页面一致。
