事务隔离级别由数据库决定，C# 代码只是传递设置
你写的
SqlConnection+
SqlTransaction代码本身不实现隔离逻辑，它只是把
IsolationLevel枚举值（比如
IsolationLevel.ReadCommitted）通过 T-SQL 的
SET TRANSACTION ISOLATION LEVEL命令发给 SQL Server。最终的锁行为、版本控制、阻塞与否，全由数据库引擎按该级别执行。
这意味着：C# 并发控制不能只靠改隔离级别来解决。比如你用
IsolationLevel.Serializable，看似“最安全”，但实际会极大增加锁范围和死锁概率——这不是 C# 层能缓解的，而是数据库在运行时做出的资源调度决策。
IsolationLevel.Unspecified不代表“无隔离”，而是使用数据库默认级别（SQL Server 默认是
ReadCommitted） 若连接字符串启用了
MultipleActiveResultSets=True（MARS），某些隔离行为可能与预期不同，尤其在异步操作中 .NET 的
async/await不改变事务边界：一个
SqlTransaction实例不能跨
await续用，否则抛
InvalidOperationException：“The transaction is no longer available.”
C# 并发编程常见误用：把 lock 和数据库事务混为一谈
很多开发者在多线程写数据库时，下意识加
lock语句块保护数据库操作，这是典型错位：
lock只锁住当前进程内的某段代码，对其他应用、其他服务器、甚至同一应用的不同进程完全无效 数据库事务的并发控制（如行锁、意向锁、快照版本）才是跨进程、跨机器的真实协调机制 滥用
lock(this)或静态锁可能导致线程饥饿，而数据库锁超时（
CommandTimeout）才是更合理的失败兜底
正确做法是：用最小必要隔离级别 + 明确的事务范围 + 合理的重试策略（如
SqlException.Number == 1205表示死锁，应重试）。
Snapshot 隔离需要数据库端显式启用，C# 无法自动开启
IsolationLevel.Snapshot在 C# 中合法，但若数据库未启用快照隔离（
ALLOW_SNAPSHOT_ISOLATION ON）或读已提交快照（
READ_COMMITTED_SNAPSHOT ON），运行时会直接报错：
System.Data.SqlClient.SqlException: Snapshot isolation transaction failed...
这不是 C# 配置问题，而是 DBA 必须提前执行的 T-SQL：
ALTER DATABASE YourDB SET ALLOW_SNAPSHOT_ISOLATION ON; ALTER DATABASE YourDB SET READ_COMMITTED_SNAPSHOT ON;
注意：
READ_COMMITTED_SNAPSHOT改变的是默认
ReadCommitted的行为（从锁变版本），而
ALLOW_SNAPSHOT_ISOLATION才允许你在 C# 中显式指定
IsolationLevel.Snapshot。
高并发场景下，IsolationLevel.ReadUncommitted 的真实代价
用
IsolationLevel.ReadUncommitted（或
NOLOCK提示）确实能避免阻塞，但它带来的数据风险常被低估： 可能读到未提交的脏数据（
SqlTransaction.Rollback()后你还拿它做了业务判断） 可能跳过行（phantom reads）、重复读行（duplicate reads），尤其在分页查询中导致漏数据或重复处理 对索引视图、XML 列、空间数据等，
NOLOCK可能直接报错或返回不一致结果
它适合报表类只读、容忍误差的场景；但绝不该用于订单扣减、库存校验、资金流水等核心路径——这时候宁可调低超时、加重试，也不该用
ReadUncommitted换吞吐。
真正影响并发性能的，往往不是隔离级别本身，而是事务持续时间（比如在事务里调用 HTTP API 或做大量计算）。缩短事务生命周期，比在
Serializable和
ReadUncommitted之间反复横跳更有意义。
