Excel打开看不出问题，ERP导入却提示第一个SKU不存在。用十六进制看文件开头常会发现EF BB BF，BOM被下游当成SKU的三个字节。

先把现象钉死

先用一个真实失败样本复现，不要一上来全量重建。把请求、实体ID和时间记下来，后面的SQL与日志才能对得上。

现场检查

  • 不要只用文本编辑器，直接查看文件头字节。
  • 确认问题只在第一行第一列，还是分隔符、引号和换行也不兼容。
xxd -l 16 export.csv
file -bi export.csv
head -1 export.csv | od -An -tx1
sed -i "1s/^\xEF\xBB\xBF//" export.csv

为了避免把环境差异当成根因，我会先在预发布或数据库副本复现；涉及订单、库存和支付的操作，正式环境只做只读核对，修复脚本必须带明确的订单号或SKU范围。

实际修复

如果ERP明确要求UTF-8无BOM，在生成流的最前面不要输出BOM；若文件来自第三方模块，定位写入chr(0xEF).chr(0xBB).chr(0xBF)的位置并改为可配置。临时处理可只移除文件开头一次，不能全局删除同字节序列。并统一逗号、双引号转义与CRLF要求。

实施时的顺序

  • 先在单个SKU、单个订单或单个Store验证。
  • 保留可回退的旧配置，不覆盖原始证据。
  • 需要批量处理时分批提交并输出成功/失败清单。

怎么确认没有假好

  • xxd开头直接是SKU表头字节
  • 包含中文名称仍是UTF-8
  • 带逗号和引号的字段可往返
  • ERP测试文件成功导入

验收不只看后台提示“成功”。我还会从前台/API再走一次真实链路，并在下一轮cron、索引或缓存命中后重复检查，确认不是短暂正常。

留一个坑位提醒

BOM不是“乱码修复开关”，有些Excel流程反而依赖它，应该按消费方生成不同导出配置。