SQL Server连接失败主因是连接字符串与实例实际状态不匹配：实例名错误、TCP/IP未启用、服务未运行、防火墙拦截或身份验证方式不符，而非代码语法问题。
能连上，但连不上才是常见问题；核心不在代码写法，而在连接字符串是否匹配本地 SQL Server 实例的实际状态。
SqlConnection 连接字符串必须匹配 SQL Server 实例名和身份验证方式
多数失败不是因为 SqlConnection 写错了，而是连接字符串里的 Data Source 指向了一个根本没运行、名字拼错、或端口被屏蔽的实例。比如你本机装的是 (localdb)\MSSQLLocalDB（VS 自带），却写了 localhost 或 .，就会报“无法找到服务器”。
-
Data Source值要严格对应 SQL Server 配置管理器中显示的实例名，常见值有：(localdb)\MSSQLLocalDB、.\SQLEXPRESS、localhost,1433（显式指定端口） - Windows 身份验证用
Integrated Security=true；SQL 登录要用User ID=xxx;Password=yyy，且确保该账号已启用并有数据库权限 - 如果 SQL Server 未启用 TCP/IP 协议，
Data Source=xxx,1433这种带端口的写法会直接失败——得进「SQL Server 配置管理器 → 协议 → 启用 TCP/IP」
Connection Timeout 参数不是可选安慰剂，而是关键诊断开关
默认超时是 15 秒，但如果你看到 SqlException: A network-related or instance-specific error... 并在几秒内就抛出，大概率是网络层阻断（防火墙/协议未开），而不是数据库忙。这时加 Connect Timeout=5 反而能更快暴露问题。
- 设太短（如
Connect Timeout=1）可能误判正常慢连接 - 设太长（如
60）会让调试卡住，尤其在开发机没装 SQL Server 时徒等 - 配合
Persist Security Info=false避免敏感信息泄露（虽然开发环境影响不大）
使用 using 语句不是为了“优雅”，而是防止连接泄漏
SqlConnection 是非托管资源，不显式关闭或释放，连接会一直挂在 SQL Server 上，直到连接池超时或服务重启。用 using 是唯一稳妥做法，哪怕只读一次数据。
- 错误写法：
SqlConnection conn = new SqlConnection(str); conn.Open(); ... // 忘了 conn.Close() - 正确写法：
using (SqlConnection conn = new SqlConnection(str)) { conn.Open(); /* 操作 */ }—— 离开作用域自动调用Dispose()，等价于Close() - 别依赖
conn.State == ConnectionState.Open来判断是否要重连；每次操作都应新建连接（连接池会复用底层物理连接）
最常被跳过的一步：没确认 SQL Server 服务是否真在运行。任务管理器里看 sqlservr.exe 进程，或者运行 services.msc 找 “SQL Server (MSSQLSERVER)” 或 “SQL Server (SQLEXPRESS)” 是否为“正在运行”。连服务都没启，再对的连接字符串也没用。
