连接字符串含账号密码仍报错：IIS APPPOOL\CoreApplications登录TrendingDB失败

我来帮你梳理下这个问题的核心排查方向——你遇到的矛盾点很明确：明明连接字符串配置了SQL用户名和密码，但系统却在尝试用IIS应用池账户登录，说明要么你的连接串没被正确应用，要么新环境的SQL Server/配置逻辑和其他三个环境存在差异。以下是具体的排查步骤：

1. 先确认连接字符串的身份验证逻辑是否生效 #

很多时候配置了SQL账户却没起作用，是因为连接串里不小心带了Windows身份验证的参数：

• 检查你的连接串格式，确保是纯SQL身份验证的写法：

  Server=xxx;Database=TrendingDB;User Id=你的SQL账户;Password=你的密码;
  

  重点看有没有Integrated Security=True或者Trusted_Connection=True——这两个参数会直接强制使用Windows身份验证，完全覆盖你设置的SQL账户密码。
• 可以在应用启动时加个日志，输出连接串的非敏感部分（比如只输出Server和Database），确认新环境的配置文件确实被加载了，没有被其他配置覆盖。

2. 检查新环境SQL Server的身份验证模式 #

如果连接串没问题，那大概率是SQL Server的身份验证模式和其他环境不一样：

• 登录新环境的SQL Server Management Studio，右键服务器→属性→安全性，看看服务器身份验证是不是"SQL Server和Windows身份验证模式"（混合模式）。如果是纯"Windows身份验证模式"，那SQL账户根本没法用，系统会自动 fallback 到当前运行的Windows账户（也就是你的IIS应用池账户）。

3. 验证SQL账户的数据库权限（如果连接串确实生效的话） #

要是混合模式已经开启，那得确认你的SQL账户在新环境的TrendingDB里有足够权限：

• 先检查SQL Server层面有没有这个账户的登录权限（在"安全性→登录名"里找，状态要是"允许登录"）；
• 再到TrendingDB的"安全性→用户"里，确认这个账户已经映射进来，并且被授予了需要的权限（比如db_datareader/db_datawriter，或者更高级的权限）。

4. 排查IIS应用池账户的权限（如果实际在用Windows身份验证） #

要是你其实误配了连接串（比如不小心加了Windows验证参数），那得给IIS APPPOOL\CoreApplications这个账户授权：

• 在SQL Server里添加这个Windows账户作为登录名，然后映射到TrendingDB，赋予必要的读写权限；
• 注意：如果SQL Server和Web服务器是分开的，这个本地应用池账户没法直接访问远程SQL，得换成域账户，或者在远程SQL上配置对应的权限。

5. 检查配置的优先级覆盖问题 #

新环境可能有其他配置来源覆盖了你的appsettings：

• 比如ASP.NET Core里，环境变量（格式像ConnectionStrings__TrendingDB）的优先级比配置文件高，你可以检查新环境有没有设置这类环境变量；
• 另外，部署时有没有应用错误的配置转换？比如appsettings.Production.json和其他环境的版本不一样，或者部署脚本替换了连接串内容。

内容的提问来源于stack exchange，提问作者gdubs