Navicat导入数据时按列位置而非列名匹配字段，必须手动映射并勾选“使用第一行作为字段名”，否则易致数据错乱或报错；日期需在Options中指定格式，MEMO字段须人工改为TEXT类型，数组类型需手动修正DDL。
字段映射不按列名匹配，只认列位置
navicat 导入 csv/excel 时默认按「从左到右的列序」一一对应表字段，不是按字段名匹配。比如 csv 第一列是 phone，但目标表第一列是 id，直接导入就会把手机号塞进 id 字段，轻则数据错乱，重则触发 incorrect integer value: '138...' for column 'id' 报错。
解决方法只有在导入向导第二步「字段映射」里手动拖拽或下拉选择：
- 必须先勾选「使用第一行作为字段名」，否则下拉列表里只显示
Field 1、Field 2，根本看不到真实字段名 - 确认 CSV/Excel 首行是纯文本字段名：无 BOM、无空格、无引号包裹（如
"name"要改成name） - 中文字段名需匹配目标库字符集：MySQL 表用
utf8mb4，Navicat 连接参数里也要设character_set_client=utf8mb4，否则映射框显示乱码 - 想跳过某列？把它映射目标设为
<ignore></ignore>——留空会被当成映射到第一个可用字段，不是忽略
日期字段报 Invalid Date Format，不是格式写错了
报这个错，90% 不是因为你写了 2025-03-18 而是 Navicat 根本没按这个格式去解析。它默认依赖系统区域设置，且不会自动识别 Excel 里的日期序列值（比如底层是数字 45722，表面却显示为日期）。
必须在导入向导第三步「字段映射」页点右下角 Options 手动指定：
- 勾选
Use custom date format - 填入真实源格式，例如：
%Y-%m-%d、%d/%m/%Y、%Y年%m月%d日 - Excel 源需提前处理：选中日期列 → 右键「设置单元格格式」→ 改为「文本」→ 再用
=TEXT(A1,"yyyy-mm-dd")转成标准字符串 - 注意：Navicat 的日期解析发生在字段映射阶段，
STR_TO_DATE()在导入流程里完全不生效
Access/MEMO 字段被截成 varchar(255)，长文本全丢
Access 里的 MEMO 字段（即长文本），Navicat ODBC 驱动常返回 SQL_LONGVARCHAR 类型描述，但 Navicat 默认映射成 varchar(255)，导致超长内容被无声截断，且不报错。
关键不是等自动识别，而是人工干预映射：
- 导入前打开 Access 表设计视图，确认字段类型是「备注」而非「文本」
- 在 Navicat 「字段映射」页，找到该列，手动将目标类型改为
TEXT（MySQL）或TEXT（PostgreSQL） - 禁用「自动调整字段长度」——它只看前几行样本，对空值多或首行短的 MEMO 字段极不可靠
- 字段名带方括号（如
[客户姓名]）会引发语法错误，务必勾选「移除标识符括号」
数组类型（如 PostgreSQL text[]）同步后变成普通 text
Navicat 16.2 及更早版本在反向工程或结构同步时，根本不读取 pg_type.typarray 元数据，看到 text[] 就当 text 处理，生成的 DDL 缺失 []，插入数组值时直接报错：column "tags" is of type text but expression is of type text[]。
不能靠设置修复，只能拦截并重写 SQL：
- 点击「结构同步」→「下一步」后，一定点开「查看脚本」，别直接执行
- 查找类似
tags text的定义，改成tags text[] - 若看到
tags ARRAY，必须补全为tags text[]（ARRAY单独存在是非法语法） - 涉及大量数组字段时，放弃图形化同步，改用
pg_dump -s导出原生 DDL，它永远正确
字段映射错误的本质，是 Navicat 不做语义理解，只做字面翻译。所有“自动”都建立在严格规范的数据前提上——而现实数据永远不规范。手动映射不是补救，是必经步骤。
