连接池由 SqlConnection 自动启用，默认 Pooling=true，无需手动创建；它根据完全一致的连接字符串共享池，参数须在连接字符串中配置，且必须用 using 或 Close() 显式释放连接。
连接池不是手动创建的，而是由 SqlConnection 自动启用的
你不需要写代码“创建”连接池——只要用 SqlConnection 并且连接字符串里没显式关掉 Pooling=false，连接池就默认开着。.NET 的 ADO.NET 在底层自动管理这个池，包括预热、复用、回收和超时清理。
常见误解是去 new 一个“连接池对象”，实际上根本不存在 SqlConnectionPool 这样的 public 类；它是内部实现，对开发者透明。
- 默认行为就是开启池：
Pooling=true（即使不写也生效） - 只要连接字符串完全一致（大小写、空格、参数顺序都算），就共享同一个池
- 不同数据库、不同用户、不同初始目录都会触发新建独立池
- 首次调用
OpenAsync()或Open()时，池才真正初始化（不是应用启动时）
关键参数必须写在连接字符串里，不能靠 SqlConnection 属性设置
SqlConnection 类上确实有 MaxPoolSize、MinPoolSize 这些属性，但它们是只读的，赋值无效。所有池行为控制只能通过连接字符串参数完成。
错误写法：connection.MaxPoolSize = 200; —— 这行代码不报错，但完全不起作用。
正确写法：把参数拼进连接字符串，例如：
"Server=localhost;Database=MyDb;Integrated Security=true;Pooling=true;Min Pool Size=5;Max Pool Size=200;Connection Timeout=30;"
-
Min Pool Size：设为 0（默认）更安全；设为正数会导致启动即建连接，可能失败还拖慢启动 -
Max Pool Size：不要盲目设大；SQL Server 默认 100，超过需确认数据库 max_connections 配置是否允许 -
Connection Timeout：控制的是“等连接”的超时，不是查询超时；设太小容易抛出Timeout expired -
Connect Timeout和Connection Timeout是同一个意思，别名写法
连接不归还池的典型表现和修复方式
最常导致“连接耗尽”、反复出现 Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool 错误的原因，不是池太小，而是连接没释放。
现象包括：
- 并发稍高就卡住或报错，但数据库本身负载很低
- 用 SQL Server Profiler 看到大量
login事件，但没对应logout - 应用重启后瞬间恢复正常，几分钟后又卡住
根本修复方式只有一条：确保每个 SqlConnection 都被 using 正确包裹，或者显式调用 Dispose() 或 Close()。
反例（危险）：
var conn = new SqlConnection(cs);<br>conn.Open();<br>// 忘了 Close() 或 Dispose()，异常时更大概率泄漏
正例（必须）：
using (var conn = new SqlConnection(cs))<br>{<br> await conn.OpenAsync();<br> // ...<br>}
异步操作下连接池行为与同步一致，但要注意 await 位置
用 OpenAsync()、ExecuteReaderAsync() 不会破坏连接池逻辑，池机制对 sync/async 完全无感。但有个极易忽略的坑：
如果你在 using 块外 await 了某个异步操作（比如在 using 块里启动了一个 Task，但没 await 它），那么 using 可能在异步操作真正执行前就结束了，连接提前归还甚至被销毁。
- 错误模式：
using (var conn = ...) { conn.OpenAsync(); DoWorkAsync(conn); }——DoWorkAsync没 await，conn很可能在它执行前就被释放 - 正确做法：所有依赖连接的异步操作，必须在
using块内 await 完毕 - EF Core 的
SaveChangesAsync()同理：它内部会管理连接生命周期，但你仍要确保 DbContext 实例不跨请求长期持有
连接池本身不关心你是同步还是异步，但它极度依赖“作用域结束即释放”这一契约。一旦打破，池就不可靠。
