ef core未提供oracle行级锁定支持，因其默认采用乐观并发模型，依赖[timestamp]等属性生成带where条件的update语句，不持锁、不阻塞；而oracle的select...for update属悲观锁，需绑定未提交事务且要求连接与事务生命周期一致，与ef core短生命周期dbcontext及变更追踪机制存在根本性语义冲突。
ef core 本身不提供 oracle 行级锁定的直接 api，它默认走乐观并发；真要行锁，得绕过 ef 的抽象层，用原始 sql + select ... for update 显式加锁。
为什么 EF Core 没有 Oracle 行锁支持
EF Core 的并发模型是乐观的：SaveChangesAsync() 依赖 [Timestamp] 或 [ConcurrencyCheck] 属性生成带 WHERE 条件的 UPDATE，不持锁、不阻塞。Oracle 的 FOR UPDATE 是悲观锁，语义和生命周期（事务内有效）与 EF 的变更追踪机制冲突——EF 不会在查询后长期持有连接，也没法保证后续 Save 仍在同一事务上下文中执行。
- EF Core 的
AsNoTracking()查询结果无法用于后续带锁更新，因为没跟踪状态 -
DbContext生命周期通常短于业务事务，而 Oracle 行锁必须绑定到未提交的事务 - 所有标准 LINQ 方法（如
FirstAsync()、SingleOrDefaultAsync()）都生成只读 SQL，不会加锁
手动实现 SELECT ... FOR UPDATE 的正确姿势
必须用 Database.ExecuteSqlRaw() 或 Database.GetDbConnection() 获取原生连接，在显式事务中执行带锁查询，并确保锁在业务逻辑完成前不释放。
- 先开启事务：
using var transaction = await context.Database.BeginTransactionAsync(); - 执行锁定查询（注意表名需带 schema，且字段名大小写要匹配 Oracle 实际定义）：
await context.Database.ExecuteSqlRawAsync("SELECT \"Id\", \"Status\" FROM \"ORDERS\" WHERE \"Id\" = {0} FOR UPDATE", orderId); - 再执行业务修改（此时仍处于同一事务），最后
await transaction.CommitAsync(); - 不要用
ExecuteSqlInterpolated处理FOR UPDATE—— Oracle 对语法敏感，插值可能破坏关键字位置
容易踩的坑：锁失效或死锁
Oracle 行锁生效的前提是 WHERE 条件能命中索引，否则会升级为表锁或发生锁等待；同时，多个线程按不同顺序加锁极易引发死锁。
- WHERE 中的字段必须有索引，否则
FOR UPDATE触发全表扫描，锁住整张表 - 避免在锁住 A 行后再查 B 行并锁 B——应一次性锁住所有需要的行，或严格按固定顺序（如 ID 升序）加锁
- 连接字符串里没设
NLS_COMP=LINGUISTIC时，WHERE \"Name\" = 'xxx'可能触发NLSSORT()，导致索引失效，锁不住单行 - 忘记
Commit()或Rollback()，锁会一直持有直到连接超时或被 DBA kill
真正要用行锁的地方，往往已脱离典型 ORM 场景；与其在 EF 里硬套，不如把加锁逻辑下沉到存储过程，或用 Dapper 执行精准控制的 SQL——EF 的价值在于减少样板代码，不是替代数据库原语。
