结论：连不上基本是环境配置问题，非代码缺陷；应优先检查sql server服务状态、连接字符串中data source是否准确、tcp/ip协议是否启用。
直接说结论：用 Microsoft.Data.SqlClient + 正确的连接字符串 + using 语句块，基本不会连不上；连不上八成是连接字符串写错、SQL Server 服务没起、或 Windows 防火墙/SQL Server 配置拦了端口。
SqlConnection.Open() 报 “拒绝访问” 或 “找不到服务器” 怎么办
这不是代码问题，是环境配置卡住了。先确认三件事：
- SQL Server 服务是否在运行？打开「服务」（
services.msc），找SQL Server (MSSQLSERVER)或SQL Server (SQLEXPRESS)，状态必须是“正在运行” - 连接字符串里的
Data Source是否写对？本地默认实例用localhost或.；命名实例（如SQLEXPRESS）必须写全，比如localhost\SQLEXPRESS（注意双反斜杠） - 是否启用了 TCP/IP 协议？用 SQL Server 配置管理器 → 「SQL Server 网络配置」→ 对应实例的「协议」→ 确保「TCP/IP」已启用，且 TCP 端口是
1433（或你在连接串里明确写的端口号）
常见错误信息如 A network-related or instance-specific error occurred，基本都落在上面三点里。
连接字符串里 Integrated Security=true 和 User Id/Password 该怎么选
取决于你用的是 Windows 身份验证，还是 SQL Server 混合模式登录：
- 开发机本地调试，SQL Server 开了 Windows 认证 → 用
Integrated Security=true，不用输账号密码，也更安全 - 部署到服务器、或 SQL Server 只开了混合模式 → 必须用
User Id=sa+Password=xxx，且确保该账号有对应数据库的db_owner或至少db_datareader/db_datawriter权限 -
Initial Catalog必须拼写准确，大小写不敏感但名称不能错，比如写成XSCJDB就不能写成xscjdb（除非你建库时显式用了双引号）
硬编码连接字符串非常危险，哪怕只是本地测试，也建议先塞进 appsettings.json 里，用 IConfiguration.GetConnectionString("Default") 读取。
执行 SqlCommand 时提示 “对象已被释放” 或 “连接已关闭”
典型资源管理失误。关键就一条：所有 SqlConnection、SqlCommand、SqlDataReader 都得包在 using 块里，别手动 .Close() 或 .Dispose()。
错误写法：
var conn = new SqlConnection(connStr); conn.Open(); // ... 执行命令 conn.Close(); // 显式关连接，但异常时这里根本走不到
正确写法：
using (var conn = new SqlConnection(connStr))
{
conn.Open();
using (var cmd = new SqlCommand("SELECT * FROM student", conn))
{
using (var reader = cmd.ExecuteReader())
{
while (reader.Read())
{
Console.WriteLine(reader["name"]);
}
}
}
} // 自动 Close + Dispose，无论是否异常
漏掉任意一层 using，都可能引发连接池耗尽、句柄泄漏，尤其在循环或高并发场景下会立刻暴露。
为什么用 Microsoft.Data.SqlClient 而不是 System.Data.SqlClient
System.Data.SqlClient 已被微软标记为“过时”，.NET Core 3.0+ 和 .NET 5+ 默认不包含它；新项目必须用 Microsoft.Data.SqlClient。
- NuGet 安装命令：
Install-Package Microsoft.Data.SqlClient - 命名空间仍是
using Microsoft.Data.SqlClient;（不是System.Data.SqlClient） - 它支持 Always Encrypted、Azure AD 认证、更细粒度的超时控制，且持续更新；而旧版只维护 bug，不加新特性
如果你在 VS 里看到 SqlConnection 报红，大概率就是忘了装这个包，或者 using 写错了。
最常被忽略的一点：连接字符串里的 Data Source 和 SQL Server 实际监听地址必须一致——哪怕你本机连本机，127.0.0.1 和 localhost 在某些 SQL Server 配置下行为也不一样；真出问题，优先用 telnet 127.0.0.1 1433 测试端口通不通，比反复改 C# 代码快得多。
