在C#后端开发中，Dapper凭借轻量、高性能的特点成为很多开发者操作数据库的首选ORM工具，它可以在不损失原生ADO.NET性能的前提下，大幅减少重复的代码编写工作。当我们需要和数据库进行复杂交互时，存储过程往往是更优的选择，尤其是需要返回额外计算结果的场景，Output输出参数能避免多次查询数据库，提升整体执行效率。
Dapper执行存储过程的基础原理
Dapper本质上是对ADO.NET的封装，它执行存储过程的核心逻辑和原生ADO.NET是一致的，只是通过扩展方法简化了参数传递、结果映射的流程。当调用存储过程时，首先需要明确数据库命令的类型，Dapper默认执行的是文本类型的SQL语句，所以如果要执行存储过程，必须显式指定CommandType为CommandType.StoredProcedure，否则数据库会把存储过程名称当成普通SQL语句去解析，最终抛出语法错误。
参数传递是执行存储过程的关键环节，Dapper提供了DynamicParameters类来处理动态参数，这个类支持定义输入参数、输出参数、返回值参数等多种类型的参数，完美适配存储过程的参数需求。和直接传递匿名对象不同，DynamicParameters可以单独指定每个参数的方向、数据类型、大小等属性，这也是它能处理Output参数的核心原因。如果使用匿名对象传递参数，Dapper会默认把所有参数都识别为输入参数，无法获取输出参数的值。
举个简单的例子，假设我们有一个查询用户信息的存储过程，需要传入用户ID作为输入参数，同时返回该用户的部门名称作为Output参数。如果使用原生ADO.NET，我们需要手动创建SqlParameter对象，设置Direction属性为ParameterDirection.Output，执行后再从参数中取值。而Dapper的DynamicParameters把这个过程封装得更简洁，只需要几行代码就能完成参数的定义和赋值，不需要手动处理参数集合的添加逻辑。
实战：完整实现存储过程调用与Output参数获取
首先我们需要在数据库中创建对应的存储过程，这里以SQL Server为例，创建一个简单的存储过程，功能是传入用户ID，查询用户姓名作为输出参数，同时返回用户的基本信息列表。存储过程的代码如下，注意Output参数需要显式标记OUTPUT关键字，否则数据库不会将其作为输出参数处理：
CREATE PROCEDURE GetUserInfoWithOutput
@UserId INT,
@UserName NVARCHAR(50) OUTPUT
AS
BEGIN
-- 设置输出参数的值
SELECT @UserName = UserName FROM Users WHERE Id = @UserId
-- 返回用户的其他信息
SELECT Id, UserName, Age, Email FROM Users WHERE Id = @UserId
END
接下来是C#端的代码实现，首先需要安装Dapper包，可以通过NuGet执行Install-Package Dapper命令完成安装。然后创建数据库连接，使用DynamicParameters定义参数，指定输出参数的方向和类型，执行存储过程后从参数中获取输出值。完整的C#代码如下：
using Dapper;
using System.Data;
using System.Data.SqlClient;
public class UserRepository
{
private readonly string _connectionString = "Server=.;Database=TestDB;Trusted_Connection=True;";
public (string UserName, List<User> Users) GetUserWithOutput(int userId)
{
using (var connection = new SqlConnection(_connectionString))
{
// 创建动态参数对象
var parameters = new DynamicParameters();
// 添加输入参数
parameters.Add("@UserId", userId, DbType.Int32, ParameterDirection.Input);
// 添加输出参数，指定参数名、类型、方向、大小
parameters.Add("@UserName", dbType: DbType.String, direction: ParameterDirection.Output, size: 50);
// 执行存储过程，指定命令类型为存储过程
var users = connection.Query<User>(
"GetUserInfoWithOutput",
parameters,
commandType: CommandType.StoredProcedure
).ToList();
// 获取输出参数的值
var outputUserName = parameters.Get<string>("@UserName");
return (outputUserName, users);
}
}
}
public class User
{
public int Id { get; set; }
public string UserName { get; set; }
public int Age { get; set; }
public string Email { get; set; }
}
上面的代码中，我们首先实例化了DynamicParameters对象，然后分别添加了输入参数@UserId和输出参数@UserName，添加输出参数时必须指定direction为ParameterDirection.Output，如果是字符串类型的输出参数，最好指定size属性，避免因为长度不足导致取值截断。执行存储过程时，Query方法会返回存储过程查询出来的结果集，也就是用户的基本信息列表，而输出参数的值不会包含在结果集中，需要执行完成后从parameters对象中通过Get方法获取。
如果存储过程还有返回值参数，比如返回受影响的行数或者自定义的状态码，也可以按照类似的方式添加参数，只需要把direction设置为ParameterDirection.ReturnValue即可。需要注意的是，Dapper执行存储过程后，输出参数和返回值参数的值只有在连接未关闭的时候才能获取，所以我们的代码把取值逻辑放在了using块内部，确保连接还没释放的时候就拿到参数值，避免获取不到的情况。
常见问题与避坑指南
第一个常见问题是忘记指定CommandType，很多开发者第一次使用Dapper执行存储过程时，会直接把存储过程名称作为SQL传入，没有设置commandType，这时候Dapper会把存储过程名称当成普通SQL语句执行，数据库会提示找不到对应的表或者语法错误。解决这个问题只需要在调用Query或者Execute方法时，显式传入commandType: CommandType.StoredProcedure即可。
第二个问题是输出参数的类型不匹配，比如存储过程中Output参数是NVARCHAR(50)，但是C#端定义参数的时候用了DbType.Int32，这时候执行存储过程会直接抛出类型转换异常。所以在定义输出参数的时候，一定要和数据库中存储过程的参数类型保持一致，字符串类型还要注意长度匹配，如果存储过程返回的内容长度超过定义的大小，会被自动截断，导致获取的值不完整。
第三个问题是参数名的大小写问题，虽然SQL Server默认不区分参数名的大小写，但是如果存储过程中定义的参数是@UserID，而C#端定义的是@UserId，在某些数据库配置下可能会出现参数匹配不上的问题，所以最好保持C#端参数名和存储过程中的参数名完全一致，包括大小写和下划线等符号，避免不必要的匹配错误。另外，如果存储过程有多个输出参数，只需要按照同样的方式添加多个输出参数到DynamicParameters中，执行后分别获取即可，不需要额外的复杂逻辑。
还有一个容易忽略的点是，当存储过程没有返回结果集，只是通过输出参数返回数据的时候，不要使用Query方法，而应该使用Execute方法，因为Query方法期望返回结果集，如果没有结果集返回可能会返回空集合，而Execute方法返回的是受影响的行数，更适合这种场景。比如存储过程只是做数据更新，然后返回更新状态作为输出参数，这时候用Execute方法更合适，执行后同样可以从DynamicParameters中获取输出参数的值。
Dapper存储过程Output输出参数修改时间：2026-08-17 23:57:04