生产环境导入接口报B1004？根因在三层隐藏故障而非Excel解析

上周生产环境突发批量导入故障，运维直接甩来一张报错截图：processSteps/importFile 接口返回 B1004，提示「Excel 解析失败」。所有人第一反应都是去查上传的 xlsx——列数不对？日期格式不兼容？特殊字符乱码？折腾两小时，文件翻来覆去查了十几遍，问题还在。

先拉全链路日志，别顺着表面报错走

我没顺着表面报错走，先把接口全链路日志拉了出来，把那份「生产作业记录导入.xlsx」放到测试环境跑了一遍解析流程。结果完全正常：哪怕有空行、合并单元格这些边缘情况，解析环节都能正确识别，输出结构和预期一致。这时候才反应过来，报错里的「Excel 解析失败」根本不是真根因——它是全局异常处理器把上游异常包了一层后的通用错误码，真正的故障点在解析环节之前就出现了。

三层真实问题，逐层定位

顺着调用链从前往后捋，抓到三层真实问题，每一层都能让接口报错。

第一层：文件流获取异常 B0909

第一层是文件流获取异常，错误码 B0909。生产日志里最早冒出来的不是 B1004，而是更早的 B0909：用户上传文件后生成的存储临时 URL 有效期只有 30 分钟，而这位用户是 2 小时后才点导入，fileId 对应的存储对象早就过期，文件流根本拿不到。没有文件输入，后面的解析自然失败，但异常被一层层包上去，用户看到的就成了「Excel 解析失败」。

第二层：绑定同步的 NPE

第二层是绑定同步的 NPE。我抽了 10 条报错记录回溯，其中有 3 条工序记录的投产时间字段是空的。导入保存完成后系统会触发绑定同步逻辑，把空的时间值传给校验方法，直接抛出 NPE。更麻烦的是这个方法被 @Transactional 包着，NPE 一抛就触发事务回滚，整批导入数据全写入失败。

第三层：审计日志插件异常

第三层是审计日志插件异常。审计日志插件记录导入操作时，会把 Excel 的列名拼进 SQL 里做参数绑定。这次导入的 Excel 里有一列叫 order#，带特殊字符的列名没被插件转义，直接抛了 IndexOutOfBoundsException，同样触发事务回滚。

反着查：根因在最下层，不在最上层错误码

有意思的是，很多人排查会顺着报错栈从下往上找，这次恰恰反着来：最上层的 B1004 是包装后的错，真正的根因卡在最前面的文件流获取环节。我按三个优先级定了修复方案——最高优先解决文件流问题，给临时 URL 加个过期前端提示，用户导入前 URL 过期就直接让重新上传，从根源避开；次优补全空值校验，在绑定同步环节加时间字段非空校验，缺必填的记录直接标失败，别连累整批正常数据；低优修日志插件，给它的 SQL 绑定逻辑加列名转义规则，挡住特殊字符导致的异常。

教训：别被表面报错带节奏

这趟排查最深的教训就是别被表面报错带节奏。生产报错先看全链路日志，别只盯着最上层错误码，不少通用错误码是下游异常被包装后的结果；@Transactional 注解方法里抛出的非受检异常大概率触发回滚，排查时得重点看事务包裹逻辑里的所有调用；查导入类问题，优先看输入和前置依赖——文件存储、前置字段校验，再查核心逻辑，最后才查周边插件，这么走能少绕不少路。