Navicat默认按列位置一一对应映射，非按字段名匹配；解决方法是在导入向导第二步「字段映射」界面手动拖拽或下拉选择对应字段，并必须勾选「使用第一行作为字段名」以识别CSV头，否则仅显示Field 1、Field 2等占位符。
CSV字段顺序和表字段不一致时怎么映射
navicat默认按列位置一一对应，不是按字段名匹配。如果csv第一列是phone但目标表第一列是id，直接导入会把手机号塞进id字段，轻则数据错乱，重则报错column count doesn't match value count。
解决方法是在导入向导第二步「字段映射」界面手动拖拽或点击下拉框选择对应字段：
- 必须先勾选「使用第一行作为字段名」，否则下拉列表里只有
Field 1、Field 2这类占位符，看不到真实字段名 - 勾选前确认CSV首行确实是纯字段名：无BOM、无前后空格、无引号包裹（比如
"name"要改成name） - 如果CSV用中文字段名，且目标MySQL表字符集为
utf8mb4，需确保Navicat连接参数中character_set_client也设为utf8mb4，否则映射下拉框可能显示乱码
跳过某列不导入却留空导致映射错乱
在「字段映射」里，把不想导入的列留空，Navicat会自动把它映射到第一个可用的目标字段，而不是忽略——这是最隐蔽的错位来源之一。
正确做法是：将该列的目标字段下拉框选为<ignore></ignore>（注意是带尖括号的字面量，不是空值）：
-
<ignore></ignore>明确告诉Navicat跳过这一列，不会参与任何映射 - 尤其注意CSV里可能含Excel自动生成的序号列、分隔用的空列、或导出时多出来的冗余列
- 如果误映射了
<ignore></ignore>列到主键字段，可能导致后续所有列整体右移一格
日期列为空但没报错，其实是字段偏移的假象
当CSV中某字段含未转义的换行符（如地址字段含回车）或逗号未被双引号包裹时，Navicat会错切一行，导致后续所有列整体偏移——这时你看到的“日期列为空”，本质是它把原本是address的内容当成了order_date，自然解析失败。
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
这种错位不报错，只静默填NULL，排查要点：
- 用Notepad++或VS Code打开CSV，开启「显示所有字符」，检查
"是否成对出现、逗号是否都在引号内、换行是否只出现在引号外 - 临时把
Field Separator从,改成;试试，如果错位消失，基本可断定是分隔符逃逸问题 - 若源文件来自Excel，优先用
pandas.read_csv()重新导出，比手动另存更可靠
中文字段名识别失败导致映射失效
即使勾选了「使用第一行作为字段名」，中文字段名仍显示为Field 1，往往不是编码问题，而是Navicat读取时把BOM头当作了字段名的一部分——比如首行实际是EF BB BF姓名,年龄（UTF-8-BOM），Navicat会把姓名当字段名，无法匹配。
处理方式很直接：
- 用记事本打开CSV → 「另存为」→ 编码选「UTF-8」（不要选「UTF-8-BOM」）→ 保存
- 或者用命令行清除BOM：
tail -c +4 input.csv > clean.csv（Linux/macOS） - Windows下可用PowerShell：
Get-Content input.csv -Raw | Set-Content clean.csv -Encoding UTF8
真正容易被忽略的是：字段错位常是多个小问题叠加的结果——BOM干扰字段名识别 → 导致无法启用字段名映射 → 被迫依赖列序 → 遇到分隔符逃逸又整体偏移 → 最后归因为“Navicat抽风”。逐层验证比反复重试更省时间。
