字段错位根源是CSV格式不合规：含换行符或逗号的字段未用双引号包裹，导致Navicat按RFC 4180解析时误判行界；须检查BOM、编码、字段映射及换行符统一性。
字段错位不是Navicat导错了，是CSV格式不合规
字段错位的根源几乎全是csv格式问题，不是navicat bug。它严格按rfc 4180解析：字段用"包裹、含,或\n的字段必须被引号包围，否则会被切错行。你看到的“第3列跑到第5列”，大概率是某行地址字段里有\n但没加引号，navicat把它当成了新记录开头。
- 检查CSV首行是否真为纯字段名——不能带BOM、空格、多余引号；否则整个映射会偏移
- 用Notepad++打开文件 → 编码菜单看是否显示
UTF-8（无BOM）或GBK，别信文件名后缀 - 搜索
,\n和"\n"：前者说明某字段结尾逗号后直接换行，是严重格式错误；后者才是合法换行 - 临时把
Field Separator改成;试试，如果错位消失，证明原CSV里存在未被引号包裹的逗号
必须手动做字段映射，不能依赖列顺序
Navicat默认按CSV列位置硬绑定目标表字段顺序，一旦源CSV和表结构字段顺序不一致，立刻错位。哪怕首行写了id,name,phone，只要数据库表定义是name,id,phone，不手动拖拽映射就必然写反。
- 导入向导第二步，务必勾选
使用第一行作为字段名——否则下拉列表里只有Field 1、Field 2 - 映射界面中，逐列点击下拉框，选对应的目标字段名；跳过某列就选
<ignore>，别留空 - 中文字段名要能正常显示，需确保Navicat连接参数中
character_set_client设为utf8mb4 - 若映射下拉框里字段名显示为乱码（如
涓?枃），说明CSV文件编码与Navicat当前解码方式不匹配，先解决编码问题
日期/数字字段为空？掩码或类型不匹配在静默丢数据
日期列全变NULL、数字列报Incorrect integer value: ''，表面是字段错位，实则是类型校验失败导致整行解析偏移。Navicat不会报错，但会跳过非法字段，后续所有列自动左移补位。
QuickBooks Mileage CSV
下载
使用 qbo-mileage CLI 及用户凭证，从 Airtable、Outlook 或 Google Calendar 记录生成 QuickBooks Online 里程 CSV 文件。
- 日期列为空：进「字段映射」→ 点日期列后的
…→ 检查日期格式是否匹配源数据（DMYvsMDY），示例框必须显示有效日期 - 数字列报错：确认CSV中该列值是纯数字（不含空格、单位、
-以外符号），且目标字段类型为INT/DECIMAL而非VARCHAR - 空字符串处理：在「高级」选项卡勾选
空字符串转为NULL，但仅对允许NULL的字段生效；NOT NULL字段仍会中断 - 真要存SQL NULL，CSV里必须写
\N，并勾选NULL值表示为填入\N
大文件导入时错位，其实是INSERT单条模式撑不住
超5万行或含长文本的CSV，Navicat默认用INSERT INTO ... VALUES (...)逐行执行，一旦某行因格式问题失败，后续所有行都会偏移——不是错位，是事务中断后剩余数据被整体错读。
- 优先改用
LOAD DATA INFILE模式（仅限本地MySQL且local_infile=ON），它绕过SQL解析层，直接由MySQL服务端按物理行加载 - 若无法用LOAD DATA，调高「提交记录数」至
5000～10000，减少事务回滚影响范围 - 关掉
启用外键检查和自动提交，避免约束校验加剧错位扩散 - 实在不行，用
head -n 10000 data.csv > chunk1.csv分块验证，快速定位出问题的具体行段
\r\n和\n共存）+ 字段内\r未被引号包裹，这种组合会让部分解析器把\r当成行尾、部分当成普通字符，结果连错位都难以复现——预处理清洗比死磕导入设置更可靠。 
