修复被数据库拒绝的 CSV 导入并完成入库

数据库只会耸肩，校验器才点名道姓

导入失败时数据库很少解释自己。装载器在某行附近报一个语法错误，或者更糟——装了一半才停下，操作者只能在编码、分隔符、引号风格之间挨个猜。所以第一步不是修，而是诊：跑结构校验，拿到带行号的缺陷清单——坏行、引号不闭合、与表头列数对不上的行。一个校验干净却仍然装不进去的文件，问题出在表头或重复行上，恰好是后两步的职责；一个校验不干净的文件，先把不规整的行修好或有意跳过，因为后续每一个工具都默认自己拿到的行结构是可信的。

表头就是契约

目标表是契约，文件的第一行是谈判。外部导出总是这样：一月份叫 Customer ID，二月份叫 userid，换一个团队出报表就成了 CUSTID。表头解析把这些名字逐一映射到目标结构的真实列名上，分层自动匹配与显式别名字典并用——后者专门针对你早已知道不可靠的那几个名字。这一步的交付物是一张映射表：目标结构的每一列都由恰好一个来源表头供给，没有漏网，也没有争抢。漏映射的列在入库后变成悄悄出现的空值；被两个表头争抢的列则意味着一个字段悄悄覆盖另一个。两种问题都在映射界面上抓出来最便宜，拖到三周后的查询里才发现代价就高了。

重复行是策略，不是意外

导入文件里的重复行多半不是意外——是重复导出、表单提交了两次、或两个人各自录入同一位客户。所以去重该属于一个明说的策略，而不是条件反射。精确匹配是诚实的默认值：只删一字不差出现两次的行，从不碰仅仅看起来相像的行。当文件出自手工录入、空格或大小写隔开了真正的孪生行时，模糊匹配才有出场资格——而且必须记录在案，因为"我们删掉了 340 行"只有在判据留档时才站得住。行数账目在这一步闭合：源行数，减去重复行，减去跳过的坏行，等于下一步将要产出的行数。

两条出路——可审查的 INSERT 还是批量 TSV

最终产物跟着装载路径走。分批的 INSERT 语句适合经过审查的中等规模装载：自带类型推断，目标覆盖 MySQL、PostgreSQL、SQLite、SQL Server，并声明冲突策略——ON CONFLICT 或 IGNORE——重跑也不会插出双份。它们能在代码审查里被阅读、进版本控制、随时重放。TSV 出口适合原生批量装载器：COPY 与 LOAD DATA 吃一份干净的制表符分隔文件，速度远超任何语句流，方言转换处理好带引号字段与内嵌分隔符，保证 TSV 本身可安全解析。但有一条警告——批量装载器不会替你解决冲突，可能重跑的文件请走带冲突策略的 INSERT 路径。

这套流程的边界

本页修复的是一个被数据库拒收的外部 CSV，陪它走到第一次成功装载。当任务超出这个范围，请交给邻居们：以工作簿形式抵达的数据源、或每周必须无人值守运行的交接，归 ETL 摄取工作流；可疑数值、离群值、要拿去支撑一场争论的质量证据，归数据质量调查；给一个本来就能装进去的表做筛选、分组、整形，归 CSV 实用工具；设计或迁移目标结构本身，归数据库结构迁移那些页面。先修复——等例行公事成熟了，再把它升级成管线。