pyodbc 报 Login failed for user 空用户名：先检查 UID/PWD 属性

pyodbc 使用 ODBC Driver 18 连接 SQL Server，最初报证书链不受信任；调整证书选项后，错误变成 Login failed for user ''，并伴随 Invalid connection string attribute。如果连接串里写的是 User Id=...;Password=...，先检查 ODBC 的属性名称。对于这里的 SQL Server 用户名密码认证，应使用 UID 和 PWD。

这条处理路径针对驱动已经收到登录失败响应、用户名却为空的场景。18456 还有密码、登录状态和数据库访问等原因，不能把所有登录失败都归为属性拼写。

错误变了，检查的阶段也要变

下面是用于判断的报错示例：

08001: The certificate chain was issued by an authority that is not trusted.
28000: Login failed for user ''. (18456)
Invalid connection string attribute

第一条指向 TLS 信任链。后两条需要查看认证信息有没有正确传给驱动。字符串里能看见用户名，不等于驱动识别了装载它的属性。换成 attrs_before 设置加密选项，也不会修正错误的用户名属性。

查看应用实际使用的连接配置，核对驱动名称、UID、PWD、Server 和 Database。只记录属性名称、目标及用户名是否为空，不要打印完整连接串或密码。配置文件、环境变量和 DSN 可能相互影响，图形界面的 DSN 测试成功，也不能证明 Python 进程使用了同一组认证信息。

用 ODBC 属性传递用户名和密码

以下是结构示例，假设 SQL Server 已允许该应用使用 SQL 登录，服务端证书受客户端信任，且名称与 db.example.com 匹配：

Driver={ODBC Driver 18 for SQL Server};Server=db.example.com;Database=appdb;UID=app_user;PWD={PASSWORD};Encrypt=yes;TrustServerCertificate=no;

域名、数据库和用户需替换；{PASSWORD} 是占位值，实际凭据从现有密钥配置取得。密码中有分号、花括号等字符时，必须按 ODBC 连接串规则编码或引用，不能直接用未经处理的字符串拼接。也不要把密码连同连接串写进版本库。

同一应用若使用 Windows 集成认证或 Microsoft Entra 认证，应按对应模式配置，不能照搬这组 SQL 登录属性。不要同时残留互相冲突的认证选项，再靠切换证书参数试错。

修改前保存原连接配置；修改后重新创建连接，让新设置实际生效。连接池中的既有连接可能仍使用原配置。若新配置连接到了错误实例，立即恢复原目标和配置，先确认身份与数据库再允许业务写入。

UID 正确后，证书问题仍要单独处理

ODBC Driver 18 默认启用连接加密。TrustServerCertificate=yes 在普通加密模式下会跳过服务端证书验证，它可能让连接继续进入认证阶段，但不会修复用户名属性，也不能作为正式环境的完整修复。Encrypt=strict 下该信任选项会被忽略，仍须验证证书。

若重新使用 TrustServerCertificate=no 后报证书错误，应让客户端信任正确的签发链，并使用证书覆盖的服务名称。这里的检查目标是同时通过证书验证与认证，不是仅把第一条错误隐藏掉。

如果错误中的用户名已经变成预期的 app_user，但仍返回 18456，继续由管理员核对 SQL Server 错误日志中的登录失败状态、账号是否允许登录、密码和数据库访问权限。应用端的简短报错不足以区分这些原因；不要因此给账号授予管理员权限。

修复后，用应用实际启动方式取得新连接，执行一条获准的只读检查，确认登录身份、当前数据库与目标实例正确。成功标准是没有无效属性警告，用户名不再丢失，TLS 验证正常，且该账号能访问应有的数据库。