错误18456主因是sa账户未启用、混合验证未开启、TCP/IP未启用或Navicat未正确传用户名；需依次确认混合模式并重启服务、启用sa并设强密码、启用TCP/IP端口1433、Navicat选SQL认证且用户名无空格。
Navicat 连接 SQL Server 2019 报错 18456，绝大多数情况不是密码输错了，而是 sa 账户根本没被允许登录——要么被禁用、要么混合模式没开、要么网络协议关着、要么 Navicat 根本没把用户名传过去。
确认 SQL Server 启用了混合身份验证模式
SQL Server 默认可能只开了 Windows 身份验证。哪怕你填了 sa 和密码，也会直接拒绝，日志里就写 18456。
- 用 Windows 身份验证连进 SSMS 或 Navicat（主机填
.或localhost） - 右键服务器 → “属性” → “安全性” → 把“服务器身份验证”改成
SQL Server 和 Windows 身份验证模式 - ⚠️ 必须右键服务器 → “重新启动”，否则不生效
检查并启用 sa 账户、重置强密码
SQL Server 2019 对 sa 的密码策略更严格：弱密码（如 123456、password）会被静默拒绝，State=8 错误里根本不会告诉你是因为密码太弱。
- 在已连上的会话里执行：
ALTER LOGIN sa ENABLE; GO ALTER LOGIN sa WITH PASSWORD = 'MyP@ssw0rd2026!'; -- 至少8位，含大小写字母+数字+符号
SELECT name, is_disabled, LOGINPROPERTY(name, 'IsLocked') AS is_locked FROM sys.sql_logins WHERE name = 'sa';
is_disabled = 1 或 is_locked = 1，得先解禁/解锁确保 TCP/IP 协议已启用且端口可达
报 18456 有时是假象——实际是连接根本没到 SQL Server，卡在了网络层。尤其是虚拟机、Docker 或远程部署场景。
- 打开
SQL Server 配置管理器→ “SQL Server 网络配置” → 选对应实例 → 双击TCP/IP→ 设为“已启用” - 点“IP 地址”页签，找到
IPAll区域，确认TCP Port是1433（或你自定义的端口），且TCP Dynamic Ports为空 - 防火墙要放行该端口；若连虚拟机，宿主机和客户机防火墙都得检查
- Navicat 主机栏不能写
192.168.1.100:1433，必须写192.168.1.100,1433（冒号 → 英文逗号）
Navicat 连接设置里最容易漏掉的三件事
很多问题其实出在 Navicat UI 层，不是 SQL Server 配置问题。
- 连接窗口点“高级” → 确认
Authentication Method是SQL Server Authentication，不是“Windows Authentication” - 手动双击用户名框，按
Ctrl+A全选，看是否真有字符——空格、制表符、零宽字符会让它传空用户名，日志里就显示“用户 ''” - 输密码前，务必取消勾选“显示密码”，避免从富文本（比如微信、网页）粘贴带隐藏控制符
真正麻烦的点往往藏在组合场景里：比如开了混合模式但没重启服务，或者启用了 sa 但密码强度不够被 2019 拒绝，又或者 Navicat 填对了，但 TCP/IP 没开导致连接超时后 SQL Server 才返回一个模糊的 18456。建议按顺序逐项验证，别跳步。
