Dapper执行存储过程必须显式指定commandType: CommandType.StoredProcedure，否则默认按普通SQL解析导致“对象名无效”错误；参数需用匿名对象或DynamicParameters传递，OUTPUT/RETURN值须通过DynamicParameters.Get<T>()读取，且连接生命周期须覆盖参数读取全过程。
直接用 Dapper 执行存储过程，CommandType.StoredProcedure 必须显式传入，否则它默认当普通 SQL 字符串解析，报错“Could not find stored procedure”或语法错误。
为什么 ExecuteScalar/Query 等方法不自动识别存储过程名
Dapper 的 Query、Execute、QuerySingle 等扩展方法底层都依赖 IDbConnection，但它们不会主动检查你传的 sql 字符串是不是存储过程名——它只认字符串内容本身。所以即使你写 "usp_GetUser"，Dapper 仍按 CommandType.Text 处理，SQL Server 就会报“对象名 'usp_GetUser' 无效”。
实操建议：
- 所有调用存储过程的地方，必须显式传入
commandType: CommandType.StoredProcedure -
sql参数只填存储过程名，别加EXEC、括号或分号，例如用"usp_GetUserById"，而不是"EXEC usp_GetUserById @id" - 参数一律用匿名对象或
IDynamicParameters传，别拼 SQL 字符串
带 OUTPUT 或 RETURN 值时，必须用 QueryMultiple 或自定义参数对象
Dapper 默认的 Query<T> 只读结果集第一列；Execute 不返回任何值；ExecuteScalar 只取第一行第一列——它们都拿不到 OUTPUT 参数或 RETURN 值。
实操建议：
- 有
OUTPUT或RETURN时，优先用IDynamicParameters（如SqlMapper.IDynamicParameters）构造参数，并在执行后手动读取.Get<int>("@ReturnCode")等 - 若同时要结果集 + 输出参数，用
QueryMultiple配合Read<T>()和ReadFirst()分步取，但注意：它不自动绑定OUTPUT，仍需IDynamicParameters - 别指望
QuerySingle<int>("usp_Test", null, commandType: CommandType.StoredProcedure)能拿到RETURN值——它只会尝试把结果集第一行第一列转成int
异步执行时，SqlConnection 生命周期必须覆盖参数读取
用 QueryAsync 或 ExecuteAsync 没问题，但常见错误是把 SqlConnection 包在 using 里，又在 await 后访问 IDynamicParameters 的值。连接一释放，参数里的 Value 就可能变 null 或抛 InvalidOperationException。
实操建议：
- 确保
SqlConnection的作用域覆盖整个异步操作 + 参数读取完成，例如把using提到外层方法，或用try/finally控制关闭时机 - 别在
await后新开连接去“重新读参数”——输出参数值只存在于原命令上下文，换连接就没了 - 如果用了
IDynamicParameters，读值必须在await之后、连接关闭之前，顺序不能错
最易被忽略的一点：Dapper 对存储过程的“支持”本质只是透传 ADO.NET 行为，它不封装 CommandType 切换、不管理参数方向、也不延迟释放连接。所有和存储过程强相关的逻辑（比如 ParameterDirection.Output、ReturnValue、连接生命周期），都得你自己对齐 ADO.NET 底层规则，不能依赖 Dapper “自动处理”。
