幽灵读和不可重复读是数据库事务隔离问题：不可重复读指同一事务两次读同一行结果不一致（因其他事务更新/删除），幽灵读指两次查询相同条件结果集行数不同（因其他事务插入/删除）。
幽灵读（Phantom Read）和不可重复读（Non-Repeatable Read）不是 C# 语言本身的特性，而是数据库事务隔离级别引发的现象；C# 代码无法“直接避免”它们，只能通过正确配置 SqlTransaction 的隔离级别、合理设计查询逻辑、或借助快照隔离等数据库机制来规避。
什么是幽灵读和不可重复读？
两者都发生在并发事务中，且只在非串行化隔离下出现：
-
不可重复读：同一事务内两次
SELECT同一行，结果不一致（因其他事务UPDATE或DELETE了该行） -
幽灵读：同一事务内两次
SELECT ... WHERE，第二次多出/少了几行（因其他事务INSERT或DELETE了满足条件的新行）
它们的根本原因不是 C#，而是 SqlConnection 默认使用数据库的默认隔离级别（SQL Server 是 READ COMMITTED），它允许不可重复读和幽灵读发生。
用 SqlTransaction 显式指定 SERIALIZABLE 隔离级别
SERIALIZABLE 是最严格的隔离级别，能同时防止不可重复读和幽灵读，但代价是锁范围大、并发性能差。C# 中需显式传入 IsolationLevel.Serializable：
using (var conn = new SqlConnection(connectionString))
{
conn.Open();
using (var tx = conn.BeginTransaction(IsolationLevel.Serializable))
{
try
{
var cmd = new SqlCommand("SELECT COUNT(*) FROM Orders WHERE Status = @status", conn, tx);
cmd.Parameters.AddWithValue("@status", "Pending");
int count1 = (int)cmd.ExecuteScalar();
<pre class='brush:php;toolbar:false;'> // 模拟其他事务插入新 Pending 订单（此时会被阻塞或失败）
Thread.Sleep(1000);
int count2 = (int)cmd.ExecuteScalar(); // count1 == count2，幽灵读被阻止
tx.Commit();
}
catch
{
tx.Rollback();
throw;
}
}}
注意：SERIALIZABLE 在 SQL Server 中会对扫描范围加范围锁（Range Lock），可能引发死锁或阻塞，不适合高并发读写场景。
改用 SNAPSHOT 隔离（推荐替代方案）
SQL Server 的 SNAPSHOT 隔离不依赖锁，而是基于行版本控制（tempdb 中保存旧版本），对应用透明且兼容性好。C# 层无需改代码，只需确保数据库已启用并连接字符串开启：
- 数据库执行：
ALTER DATABASE YourDB SET ALLOW_SNAPSHOT_ISOLATION ON - 连接字符串添加：
ApplicationIntent=ReadWrite;Snapshot=True（.NET 6+ 支持）或更通用的做法是在事务中显式设置：SET TRANSACTION ISOLATION LEVEL SNAPSHOT - C# 中仍用
BeginTransaction()，但需配合数据库级配置
SNAPSHOT 能彻底消除不可重复读和幽灵读，且不会阻塞写操作——这是比 SERIALIZABLE 更实用的选择。
业务层规避：避免依赖两次读的一致性
很多所谓“幽灵读问题”，其实源于错误的业务假设。例如：“先查订单数，再插入新订单，要求总数 ≤ 10”。这本质上是竞态条件，应改用原子操作：
-- 不要这样（C# 先 SELECT 再 INSERT） -- 而是用带条件的 INSERT 或 MERGE INSERT INTO Orders (UserId, Status) SELECT @userId, 'Pending' WHERE (SELECT COUNT(*) FROM Orders WHERE UserId = @userId AND Status = 'Pending') < 10;
或者用带 UPDLOCK, HOLDLOCK 的 SELECT 锁定范围（SQL Server 特有）：
SELECT COUNT(*) FROM Orders WITH (UPDLOCK, HOLDLOCK) WHERE UserId = @userId AND Status = 'Pending';
这类方案把一致性保障下推到数据库层，比靠 C# 控制事务隔离更可靠、更轻量。
真正难处理的不是怎么写 BeginTransaction，而是判断哪里需要强一致性、哪里可以接受快照或最终一致；盲目套用 SERIALIZABLE 容易拖垮性能，而完全忽略隔离级别又会在高并发时暴露数据逻辑漏洞。
