用户甩来一个十万行的Excel要导入？批量导入三种方案对比

To B 系统躲不开 Excel 导入：客户初始化要导几万条物料，财务每月要导几千条凭证，运营一高兴甩过来一个十万行的表格。做得糙的系统，导入按钮就是事故按钮：点了没反应、页面转圈三分钟、最后超时报错，更可怕的是数据进了一半，没人说得清进了哪一半。

核心矛盾是：Excel 导入是低频但高风险的操作——数据量大、格式脏、错误多，还经常在业务高峰期执行。 业界有三条主流路线：同步直接导入、异步任务导入、文件预检加分阶段导入，体验和复杂度逐级上升。

方案一：同步直接导入

原理： 上传即解析，解析即入库，接口同步返回结果。行级校验，错了要么整体回滚要么跳过错误行，一次请求搞定。

优点：

• 实现最简单，半天工作量
• 用户体验直接：点完就知道结果，没有中间状态
• 小数据量下完全够用，几百行秒级完成

缺点：

• 数据量一大就崩：几千行以上开始超时，网关、容器、数据库连接池层层超时等着你
• 长事务风险：整体回滚意味着一个大事务，锁表、日志爆涨都可能来
• 没有进度感：用户对着转圈的页面，不知道是该等还是该刷新

适用场景： 明确的小数据量场景（一千行以内）：后台配置导入、小批量资料维护。作为唯一方案只够小系统用，但作为大系统的"小文件快速通道"很合适。

方案二：异步任务导入

原理： 上传后文件落对象存储，立即返回任务 ID；后台 worker 拉取任务逐行处理，进度写库；前端轮询或推送展示进度条，完成后提供错误明细下载。

优点：

• 数据量不再是问题：几万到几十万行都能扛，大不了慢慢跑
• 进度可见：用户心里有数，焦虑感大减
• 资源可控：worker 数量限死，导入再猛也冲不垮在线业务

缺点：

• 复杂度上来了：任务队列、进度管理、结果通知一整套
• 错误反馈滞后：用户传完以为成功了，十分钟后才发现错了一半
• 重复提交要防：用户等不及又点一次，同一文件跑两遍，幂等设计少不了

适用场景： 中大数据量导入的标准解法（几千到几十万行），绝大多数 To B 系统的主方案。

方案三：文件预检 + 分阶段导入

原理： 把导入拆成两个独立阶段：第一阶段"预检"——上传后只做解析和全量校验（格式、必填、字典匹配、重复数据、业务规则），快速返回校验报告，一行数据都不入库；第二阶段"执行"——用户确认校验报告后才真正入库，入库过程异步执行并支持断点续传。

优点：

• 错误前置暴露：格式错误、业务冲突在入库前全亮出来，不存在"进了一半"
• 用户掌控感强：先看体检报告再决定动不动手术
• 执行阶段几乎不出错：能入库的都是校验过的数据，成功率接近百分之百

缺点：

• 实现成本最高：校验和执行两套逻辑，校验规则还要和业务侧对齐
• 校验和执行的间隙数据可能变化：预检通过的数据，执行时可能已经不合法（比如引用的字典被删了），执行期轻量复核不能省
• 交互链路长：两步操作，产品设计要跟得上，不然用户找不到第二步

适用场景： 初始化迁移、主数据导入这类"错不起"的场景，以及单文件超十万行的超大批量。金融、医疗等对数据准确性要求高的行业标配。

按数据量与容错要求对号入座

成熟的系统通常组合使用：小文件走同步快速通道，大文件自动切异步，关键主数据强制预检流程。用户感知是"一直都挺顺"，背后是三条路的分流。

落地前必做的三件事

第一件：模板和错误提示说人话。 导入失败的元凶八成是格式问题：模板要有示例行和字段说明，错误报告要精确到"第 387 行'客户编号'不存在"，而不是抛一个"导入失败"。错误提示的质量直接决定客服的工作量。

第二件：幂等和去重是底线。 唯一键去重、任务防重复提交、失败重跑不产生脏数据，这三件事必须在方案里闭环。导入是重复执行概率最高的操作，没有幂等兜底早晚出数据事故。

第三件：大文件要有资源隔离。 导入 worker 和在线业务隔离部署或限流，文件解析用流式读取（SXSSF 等），别让一个十万行的 Excel 把应用内存吃光。导入把正常业务拖垮的事故，比导入失败本身难看得多。

写在最后

批量导入是个"平时不起眼、出事就显眼"的功能，设计水平全在细节里：错误提示说不说得清、重复执行安不安全、大文件拖不拖垮系统。方案选型跟着数据量和容错要求走，但模板、幂等、隔离这三件事，哪种方案都省不了。