导入失败按文件解析、类型映射、数据库约束三层顺序排查，90%问题3分钟内定位；预览错位需核对delimiter、quoteChar及编码；类型转换失败须检查NULL占位符、千分位和日期格式；主键冲突应调整writeMode为IGNORE/UPDATE/REPLACE；错误详情查loadErrors列表定位具体行列。
导入失败不是随机出错，而是分层失效：文件解析错、类型映射错、数据库约束错。按这三层顺序查，90%的问题3分钟内定位。
预览阶段列就错位？先核对delimiter和quoteChar
预览里一列内容跑到另一列里、字段值开头或结尾多出引号、换行被吞掉——全是DataImporterCSV参数和文件实际格式不匹配的典型表现。
- 打开导入向导，在“格式设置”页手动点开“编辑”按钮，别依赖默认值
- 用文本编辑器（如VS Code）打开CSV，把光标停在第一行两个字段之间，看真实分隔符是逗号
,、分号;还是制表符\t，填进delimiter - 如果某字段含逗号（比如地址“北京市,朝阳区”），它一定被引号包着，此时
quoteChar必须设为"；若文件用单引号，就得改成' - 编码选错也会导致预览乱码，Windows生成的中文CSV大概率是
GBK，不是UTF-8
预览正常但执行报“类型转换失败”？重点查NULL占位符和千分位
预览看着整齐，一执行就报Cannot convert value '1,234' to integer或Failed to parse date '2023/05/01'，说明解析层过了，映射层卡住了。
- 检查源文件中空值怎么写的：是空字符串
""、NULL（全大写）、\N，还是单纯留白？在“列映射”页对应列的“空值”下拉框里选一致的标识 - 数字列含千分位（如
1,234.56）必须提前清理，DBeaver不自动剥离；要么用正则替换，要么在列映射里勾选“忽略千分位符号”（部分版本支持） - 日期列务必统一格式，
YYYY-MM-DD最稳；若混着DD/MM/YYYY和MM-DD-YYYY，别指望自动识别，先用脚本归一
导入中途报主键冲突？别急着删数据，先改writeMode
前几百行成功，后面开始报duplicate key value violates unique constraint，说明目标表已有记录，而DBeaver默认走的是INSERT ONLY策略。
- 在导入设置页找到“写入方式”（不同版本叫法可能是
Insert mode、Write method或Conflict handling） - 根据需求三选一：
IGNORE（跳过重复，适合补数据）、UPDATE（覆盖旧值，注意只更新映射列）、REPLACE（先删后插，慎用） - 如果选
UPDATE但没生效，检查是否漏配主键列映射——DBeaver需要知道拿哪几列去WHERE，否则当普通插入处理 - 首次运行建议先用
IGNORE跑通，再从结果统计里看“跳过行数”，心里有底后再切策略
错误提示里找不到具体哪一行失败？去翻loadErrors列表
DBeaver不会因某一行失败就中断整个任务，所有错误都攒在内存里，最后统一输出。所以“结果页没红字”不等于成功，“日志最后一行报错”也不代表是第一个问题。
- 导入完成后，点结果窗口右上角的“显示详细信息”或“查看日志”，找
loadErrors段落 - 每条错误含
lineNumber、column、message，例如Line 1278, column 'created_at': Cannot parse date '2023-13-01' - 直接用文本编辑器打开CSV，跳转到对应行，比在DBeaver里猜快得多
- 这个列表来自
DataTransferState类，只要导入任务没被强制终止，它就完整保留
真正容易被绕开的其实是预览页那三十秒——它暴露的是文件层问题，而大多数人习惯跳过去，等报错才回头调参数。一旦预览列对不上，后面所有类型映射和冲突处理都是在给错误输入做无用功。
