根本原因是windows和macos系统级差异导致navicat对ssh私钥路径解析、ssh客户端行为（内置vs系统ssh）、字符集与终端响应码处理逻辑不同：windows直接解析windows路径且稳定走内置ssh，macos依赖shell环境解析~路径、可能调用系统ssh-agent、对locale和编码更敏感。
同一SSH跳板机在Windows和macOS版Navicat中表现不同，根本原因不是跳板机或数据库配置变了，而是两端对SSH隧道的**路径解析、密钥加载逻辑、终端环境依赖**存在系统级差异——不是Navicat“做错了”，而是它必须适配各自系统的底层行为。
SSH私钥路径解析规则不一致
Navicat在SSH页面填写的私钥路径是纯字符串，但实际读取时由操作系统解释：
- Windows版直接按Windows路径语义解析：
C:\Users\me\.ssh\id_rsa或%USERPROFILE%\.ssh\id_rsa能被正确定位 - macOS版走POSIX路径规则，不识别
%USERPROFILE%，且~展开依赖当前Shell环境（如zsh或bash）；若Navicat未继承终端环境变量，~/.ssh/id_rsa可能被当作字面量路径而打不开 - 常见错误现象：
Authentication failed (publickey)在Mac上弹出，但用Terminal执行ssh -i ~/.ssh/id_rsa user@jump却成功——说明密钥本身没问题，只是Navicat没找到它
SSH客户端行为差异：内置vs系统ssh
Navicat 17默认使用内置SSH实现（基于libssh），但macOS版本会优先尝试调用系统ssh命令（尤其当检测到SSH_AUTH_SOCK时），而Windows版几乎只走内置路径：
- macOS若启用了
ssh-agent且密钥已添加，Navicat可能绕过私钥字段直连，此时改路径无效；反之，若agent未运行，又没填对路径，就必然失败 - Windows上即使装了OpenSSH，Navicat也极少自动切换，更稳定；但macOS上
ssh -o StrictHostKeyChecking=no这类自定义选项无法透传给Navicat内置客户端 - 实操建议：在Mac上测试前，先在Terminal里运行
echo $SSH_AUTH_SOCK，若非空，可临时unset SSH_AUTH_SOCK再启动Navicat，强制走私钥文件路径
字符集与终端响应码处理不同
跳板机若为Linux发行版（如CentOS 7或UOS），其/etc/locale.conf或LANG设置会影响SSH会话初始化阶段的响应格式：
- Windows版Navicat对
LC_ALL=C兼容性更强，能容忍跳板机返回的ANSI控制字符（如\033[?25l） - macOS版更严格解析UTF-8 BOM和行尾换行符，若跳板机locale设为
zh_CN.UTF-8但系统缺字体（如未装fonts-wqy-microhei），SSH握手阶段可能卡在乱码响应，表现为“连接超时”而非认证失败 - 容易被忽略的点：这个卡顿发生在SSH通道建立阶段，
测试连接按钮显示“Connecting…”后无后续，日志里看不到Connection established，但ssh -v能看到debug1: Authentication succeeded——说明问题出在通道建立后的首帧交互，而非登录本身
