调用存储过程必须设SqlCommand.CommandType = CommandType.StoredProcedure；参数名须与存储过程定义一致，输出/返回参数需显式指定方向，执行后从SqlParameter.Value取值，DateTime优先用SqlDbType.DateTime2，空值赋DBNull.Value，异步调用需ConfigureAwait(false)防死锁。
SqlConnection 执行带参数的存储过程必须用 SqlCommand.CommandType = StoredProcedure
直接拼 SQL 字符串调用存储过程（比如 "EXEC proc_GetUser @id = 1"）看似能跑通，但会绕过参数化机制，导致 SQL 注入风险、类型推断失败、输出参数无法捕获。核心是告诉 ADO.NET：“这不是普通 SQL，这是个存储过程”。
- 必须显式设置
command.CommandType = CommandType.StoredProcedure - 存储过程名只写名称，不要加
dbo.前缀（除非有同名冲突），ADO.NET 会按用户默认 schema 查找 - 参数名要和存储过程中定义的完全一致（大小写不敏感，但建议保持一致），否则
SqlParameter绑定会静默失败 - 输入参数用
ParameterDirection.Input（默认可省略），输出/返回值参数必须显式指定方向
获取存储过程的返回值（RETURN）和输出参数（OUTPUT）不能混用 ExecuteNonQuery
ExecuteNonQuery 只返回影响行数，它根本不会读取 RETURN 值或 OUTPUT 参数——这些值在命令执行完后才“存在”于 SqlParameter 对象里。
- 无论有没有结果集，都先调用
command.ExecuteNonQuery()触发执行 - 之后立刻从对应参数对象中取值：
returnParam.Value或outputParam.Value - 如果存储过程有
SELECT结果集，又需要 RETURN 值，仍得用ExecuteNonQuery，不能切到ExecuteReader，否则 RETURN 和 OUTPUT 参数不会被填充 - 注意：
Value是object类型，需手动转换，比如(int)returnParam.Value
用 SqlParameter 传 DateTime 或 NULL 值时容易类型不匹配或报错
SQL Server 的 datetime 和 datetime2 精度不同，C# 的 DateTime 默认精度是 100ns，而旧版 datetime 只支持 3.33ms，传入时若没对齐会报错或截断；传 null 更常见踩坑——直接赋 null 会抛异常，必须用 DBNull.Value。
- 日期参数优先用
SqlDbType.DateTime2，兼容性好且精度高，避免用DateTime - 传空值必须写
parameter.Value = DBNull.Value，不能写parameter.Value = null - 字符串参数长度不用预设（如
Size = 50），除非明确要限制截断，否则留空让 SQL Server 自动推断 - 数值类型如
int、decimal尽量用强类型构造函数，比如new SqlParameter("@age", SqlDbType.Int) { Value = 25 }，比用泛型构造器更可控
异步调用存储过程记得用 ConfigureAwait(false) 避免死锁
在 ASP.NET 同步上下文（如旧版 MVC、WebForms）或 WinForms UI 线程中，直接 await ExecuteNonQueryAsync 可能引发死锁，因为回调试图回到原上下文，而主线程正等着这个异步操作结束。
- 服务端代码（ASP.NET Core、Console、Worker Service）不受影响，可直接 await
- 若项目还在用 .NET Framework + WebForms/MVC，务必在 await 后加
.ConfigureAwait(false) - 输出参数和 RETURN 值在异步调用中获取方式不变，仍是执行完后读
Parameter.Value - 别为了“看起来异步”而强行套
Task.Run包装同步方法，这反而增加线程开销，且无法真正释放 I/O 线程
实际调用逻辑很薄，关键点就卡在类型、方向、空值、上下文这四块。漏掉任一个，都会表现为“参数没生效”“返回值是 0”“DateTime 被截断”或“界面卡死”。
