90%的sqlconnection连接失败源于连接字符串错误而非代码问题；需确保data source与sql server实际实例名完全一致（如.\sqlexpress）、正确选用windows或sql身份验证模式、设置合理connect timeout、避免硬编码并启用persist security info=false。
连接字符串写错，90% 的 SqlConnection 报错不是代码问题，而是它根本没连上目标实例。
Connection string 里 Data Source 值必须和 SQL Server 实际实例名完全一致
很多人写 Data Source=. 或 Data Source=localhost，结果报“无法找到服务器”——因为本机装的是 (localdb)\MSSQLLocalDB（VS 自带），或者 .\SQLEXPRESS（SQL Server Express 默认实例）。这些名字不通用，不能互相替换。
- 查真实实例名：打开「SQL Server 配置管理器 → SQL Server 服务」，看正在运行的服务名称（如
SQL Server (SQLEXPRESS)对应.\SQLEXPRESS） - 本地开发常用值：
(localdb)\MSSQLLocalDB、.\SQLEXPRESS、localhost,1433（显式端口，需 TCP/IP 已启用） - 远程服务器必须用 IP 或主机名，不能用
.或(local)，它们只在本地解析
Integrated Security=true 和 User ID/Password 不能混用，且账号必须有权限
Windows 身份验证走当前登录用户凭据，SQL 登录则走数据库内建账户。两者互斥，写错会导致“登录失败”或“拒绝访问”。
- 用 Windows 认证：
Integrated Security=true（等价于Trusted_Connection=yes），此时删掉User ID和Password - 用 SQL 认证：
User ID=sa+Password=xxx，但要确认该账号已启用（SSMS → 安全性 → 登录名 → 右键属性 → 状态 → 登录 → 启用） - SQL Server 默认禁用
sa账号，且可能未开启混合模式认证（需在 SSMS → 服务器属性 → 安全性 → 服务器身份验证 → 切换为“SQL Server 和 Windows 身份验证模式”）
Connect Timeout 不是可选项，它是诊断网络层阻断的第一开关
默认 15 秒超时，但如果你几秒就看到 SqlException: A network-related or instance-specific error，说明根本没到数据库鉴权阶段，而是卡在 TCP 连接建立环节。
- 加
Connect Timeout=5能更快暴露问题：是防火墙挡了？SQL Server 没开 TCP/IP？实例根本没运行？ - 设成
Connect Timeout=1容易误判——尤其在虚拟机或高延迟环境，正常连接也可能超时 - 设成
Connect Timeout=60会让调试卡住，比如开发机压根没装 SQL Server，你得干等一分钟才报错
别硬编码连接字符串，也别忽略 Persist Security Info=false
把连接字符串写死在代码里，不仅难维护，还容易泄露密码；而 Persist Security Info=true（默认值）会让已建立的连接对象把密码明文暴露在 ConnectionString 属性中，有安全隐患。
- .NET Framework 项目：存进
app.config的<connectionstrings></connectionstrings>节，用ConfigurationManager.ConnectionStrings["key"].ConnectionString读取 - .NET 5+ 项目：放
appsettings.json的ConnectionStrings对象下，通过IConfiguration注入获取 - 务必加上
Persist Security Info=false（尤其 SQL 认证场景），防止连接对象被意外序列化或日志打印出密码 - 生产环境敏感字段（如密码）建议用 Azure Key Vault、环境变量或 DPAPI 加密配置节，而不是靠注释“临时删密码”来“安全”
最容易被跳过的一步，是没确认 SQL Server 服务本身是否在运行——任务管理器里搜 sqlservr.exe，或者直接在服务列表里找对应实例名的服务，右键“启动”。连进程都没起来，再对的字符串也没用。
