Navicat导入CSV时“跳过错误记录”选项位于导入向导最后一步Options标签页中，勾选“Skip errors and continue importing”仅对单行数据级错误生效，不处理编码、BOM、语法或服务端约束类错误。
Navicat导入CSV时“跳过错误记录”在哪设置
navicat 本身没有全局“跳过错误记录”的开关，所谓“高级选项”实际藏在导入向导的最后一步——options 标签页里，且仅对部分错误类型生效（比如字段类型不匹配、空值插入非空列）。它不会跳过语法错误或编码解析失败。
- 必须先完成字段映射（Mapping），点击
Next到最后一页才能看到Options按钮 - 点开
Options后勾选Skip errors and continue importing—— 这才是你要找的选项 - 该选项只影响单行数据级错误（如某一行的
age写成"abc"而目标列为INT），不会跳过表结构不兼容、主键冲突或外键约束失败 - 如果 CSV 含 BOM 或换行符混乱，勾了也没用：Navicat 会直接卡在解析阶段，根本进不到这个选项页
为什么勾了“Skip errors”还是报错中断
常见假性“已开启但无效”，其实是 Navicat 把某些问题归类为“不可恢复错误”，而非数据行错误。典型包括：
-
Incorrect string value: '\xF0\x9F\x98\x82' for column 'name'：UTF-8 四字节 emoji 写入utf8（非utf8mb4）字符集表 → 必须改表字符集，跳过选项不生效 -
Data truncated for column 'email' at row 123：目标字段是VARCHAR(50)，但第123行 email 长度 62 → 默认截断警告不算错误，但若开启了严格 SQL 模式（STRICT_TRANS_TABLES），就会报错中断 - CSV 第一行有 BOM（
\xEF\xBB\xBF），导致字段名识别错位 → Navicat 解析失败，连映射页都进不去 - 时间格式不匹配，如 CSV 里写
2023/13/01，MySQL 拒绝插入 → 属于服务端校验失败，客户端跳过选项无感知
真正能绕过错误的实操替代方案
当 Skip errors and continue importing 不起作用，又不想手动清洗全部数据，可以分层处理：
- 先导出建表语句，在目标表加
SET SQL_MODE = ''临时关闭严格模式（仅限开发环境） - 用
LOAD DATA INFILE替代 Navicat GUI 导入：LOAD DATA INFILE '/path/to/file.csv' IGNORE INTO TABLE t1 ...中的IGNORE关键字才是真正跳过重复主键/唯一键冲突的机制 - 把 CSV 先用 Python 或命令行预处理：例如用
awk -F, 'NF==5' file.csv > clean.csv剔除字段数异常的行，再导入 - 在 Navicat 中改用“追加模式”（Append）而非“替换模式”（Replace），避免因清空表触发外键或触发器引发的连锁报错
容易被忽略的字符编码和换行陷阱
90% 的“跳过无效”问题根源不在选项本身，而在文件底层格式。Navicat 对编码和换行极其敏感：
- Windows 记事本保存的 CSV 默认是
GBK或带 BOM 的UTF-8 with BOM，而 Navicat 导入页默认按UTF-8解析 → 必须手动在导入向导第一步选择正确编码，不能依赖自动检测 - Mac 或 Linux 下生成的 CSV 常用
\n换行，Windows 环境 Navicat 可能误判为单行 → 在Options页确认Line separator设置为LF（不是默认的CRLF） - 字段内含换行符（如地址字段写了回车）且未用双引号包裹 → Navicat 会直接解析错乱，此时任何跳过选项都救不了，必须提前用脚本转义或重包引号
复杂点从来不在勾不勾那个框，而在你手里的 CSV 文件到底有没有被 Navicat “看懂”。
