在 Azure Functions 中可安全高效使用 Dapper，关键在于正确管理 SqlConnection 生命周期（Transient 注册、避免 static）、复用 SqlConnectionStringBuilder、显式异步事务控制、结合 Application Insights 监控及规避 N+1 查询。
在 Azure Functions 中使用 Dapper 是完全可行的，而且是轻量、高效的数据访问方案。关键不是“能不能用”，而是“怎么用得稳、用得巧”——尤其在无服务器（Serverless）环境下，要注意连接生命周期、连接池复用、冷启动影响和事务边界。
1. 安装依赖并配置 SqlConnection
Dapper 本身只是一个 NuGet 包（Dapper），不带连接逻辑，它依赖 System.Data.SqlClient（.NET Core 3.1+ 推荐用 Microsoft.Data.SqlClient）。Azure Functions v4+ 默认基于 .NET 6/7/8，所以请安装：
- Microsoft.Data.SqlClient（官方推荐，支持 Azure AD 认证、连接加密等）
- Dapper
不要在每次 Function 执行时 new 一个 SqlConnection —— 这会快速耗尽连接池或触发 Azure SQL 的连接限制。正确做法是：用 static 或 IHttpClientFactory 风格的连接工厂封装，或者更推荐：在 Startup / Program.cs 中注册 SqlConnection 为 Transient（注意不是 Singleton！），由 Dapper 每次调用时按需创建 + 显式释放。
2. 避免静态 SqlConnection，但可复用 SqlConnectionStringBuilder
别把 SqlConnection 做成 static 字段，这在并发和缩放场景下会出错（连接状态混乱、线程不安全）。但你可以把连接字符串的构建逻辑抽出来，比如：
- 从 IConfiguration 读取连接字符串（推荐存在 Key Vault，通过 Functions 的托管标识访问）
- 用 SqlConnectionStringBuilder 设置超时、加密、应用名称等（便于监控识别）
示例片段（Function 方法内）：
var builder = new SqlConnectionStringBuilder(_configuration.GetConnectionString("SqlDb"));
builder.ApplicationName = "MyFunctions-UserQuery";
using var conn = new SqlConnection(builder.ConnectionString);
await conn.OpenAsync();
var users = await conn.QueryAsync<User>("SELECT * FROM Users WHERE Active = 1");3. 手动管理事务 & 异步优先
Azure Functions 天然异步，Dapper 的 QueryAsync / ExecuteAsync 必须用上。事务要显式控制：
- 不要依赖隐式上下文事务（如 TransactionScope），它在无服务器中不可靠且可能跨函数实例泄漏
- 用 SqlTransaction + using 包裹多个 Dapper 调用
- 注意：Functions 超时设置（默认 5 分钟）要覆盖最长事务路径
小技巧：对只读查询，加 WITH (NOLOCK) 或设置 CommandTimeout 可防阻塞；写操作务必设合理 timeout 并捕获 SqlException 做重试（配合 ExponentialBackoff）。
4. 监控与诊断不能少
无服务器里看不见连接数、执行计划、慢查询？那就得主动埋点：
- 用 Application Insights 记录 Dapper 查询耗时（包装一层 IDbConnection 扩展或用 DiagnosticSource）
- 在日志里打上 SQL 片段（脱敏后）和参数摘要，方便排查超时或死锁
- 开启 Azure SQL 的 Query Store 和自动优化建议，和 Functions 日志交叉分析
特别提醒：避免在 Function 中执行 N+1 查询（比如先查订单，再对每个订单查用户）——无服务器缩放会让这种模式雪崩式放大延迟和连接数。
基本上就这些。Dapper 在 Azure Functions 里不复杂，但容易忽略连接生命周期和异步边界。用好它，你既能保持数据层简洁，又不会掉进 Serverless 的坑里。
