Navicat数据网格粘贴仅识别焦点所在行或“+”新增行：焦点在已有行时只粘贴剪贴板首行；在“+”行才启动批量插入，否则第2行起静默丢弃，且不支持字段内换行符及非Tab/逗号分隔符。
Navicat数据网格粘贴只认「焦点所在行」或「+新增行」
Navicat的数据网格不是Excel，它没有“选中一片区域后整体覆盖”的语义。粘贴行为完全取决于当前光标位置：如果焦点落在已有数据行的某个单元格上，Ctrl+V只会取剪贴板**第一行**填入该行；如果焦点落在末尾的「+」空行上，才会启动批量插入模式，尝试解析多行。其他任何位置（比如列标题下、空白区域、被隐藏的行）都会导致第2行及之后的内容被静默丢弃——不报错、无提示。
常见触发场景包括：
• 复制Excel 10行含表头数据，点在第5行某单元格后直接Ctrl+V → 仅第5行被改写
• Mac用户用Cmd+V但未先按Cmd+Insert激活插入模式 → 系统级粘贴被Navicat拦截为单行处理
• 剪贴板含混合换行符（如\r\n和\n混用），Navicat在解析第二行开头时就中断，后续全丢
字段内换行符会被误判为「行分隔符」
当复制源（如Excel单元格、CSV文本）中某字段本身含\n或\r（例如地址栏写了“北京市\n朝阳区”），Navicat在「+」行粘贴时会按纯文本切分：遇到第一个\n就认为是新记录起点，导致列对齐彻底错位——后面所有字段都左移一列，最后一列数据消失，甚至整行被截断。
这不是编码问题，而是解析逻辑缺陷：Navicat数据网格**不支持RFC 4180标准的引号包裹字段**，无法识别"北京市\n朝阳区"这种合法CSV结构。它只认裸分隔符，所以唯一规避方式是预处理掉字段内换行：
• 导出前用SQL清洗：SELECT REPLACE(REPLACE(address, '\r', ''), '\n', ' ') FROM table
• 或在Excel里用查找替换把单元格内换行替换成空格/逗号
剪贴板格式与列映射不匹配导致错位
Navicat默认按当前列顺序匹配剪贴板内容，且只识别\t（Tab）和,作为分隔符。如果你从网页或Notepad++复制的是空格分隔、竖线|分隔，或字段间有不规则空格，它会把整段当第一列，其余列留空，看起来像“全部挤在第一列”。
验证和修复方法：
• 用VS Code打开「显示空白字符」（Ctrl+Shift+P → Toggle Render Whitespace），确认真实分隔符是\t还是
• 在Navicat粘贴前，先手动选中目标表的对应列（如只选name、email两列），再Ctrl+V，强制限制列数
• 若必须用CSV格式粘贴，先导出为CSV文件，再用「导入向导」并显式指定Fields terminated by和Fields enclosed by
Mac系统下Cmd+V默认不触发批量插入
macOS的Cmd+V是系统级粘贴命令，Navicat在macOS版本中并未将其绑定到「批量插入模式」。即使焦点在「+」行，Cmd+V仍走单行逻辑。必须先按Cmd+Insert（或Cmd+Shift+V，视Navicat版本而定）显式进入插入状态，再按Cmd+V才生效。
这个细节极容易被忽略，因为Windows下Ctrl+V在「+」行天然触发批量插入，而Mac用户会下意识沿用相同操作。临时补救：粘贴后立刻检查是否只有一行变化；若发现异常，撤销后改用Cmd+Insert再试。
最常被漏掉的验证点：别信Navicat预览窗口里的“成功插入X行”提示——它只反映粘贴动作是否被接收，不校验实际写入行数。真正要确认，得立刻执行SELECT COUNT(*)，或者用hexdump -C看粘贴后数据文件末尾字节，否则你以为的“10行全进去了”，其实只有首行落库。
