MongoDB 5.0 事务未新增语法或隔离级别，但通过优化器改进、snapshot 读关注扩展至事务外、分片提交可控性提升及窗口函数安全只读支持，使事务更稳定可预期；窗口函数不可写、不参与原子性，仅依赖快照保证一致性。
MongoDB 5.0 的事务本身没有新增语法或隔离级别，但底层执行机制和配套能力的升级，让事务在窗口函数使用、长时查询一致性、以及分片集群中的行为更可控——不是“事务变强了”，而是它跑得更稳、更可预期。
事务中能直接用 $window 吗？
不能。MongoDB 的窗口函数（如 $sum、$avg 配合 partitionBy 和 sortBy）只存在于聚合管道中，而事务不支持在 aggregate 操作里嵌套事务逻辑。但关键点在于：5.0 允许你在事务内安全执行带窗口函数的聚合查询，前提是该聚合不修改数据（即只含 $match、$group、$window 等只读阶段）。
这在 4.4 及更早版本中虽语法上可行，但存在风险：
- 4.4 的优化器对
$window下推支持弱，容易触发全集合扫描，事务持有快照时间变长，加剧锁竞争 - 5.0 优化器能把
$project结果下推到$sort前，降低内存峰值，减少事务内排序阶段的资源抖动 - 窗口函数依赖的索引现在能被
$expr中的比较符直接命中，避免事务内因索引失效导致的计划回退
readConcern: "snapshot" 在事务外也生效了
5.0 把 snapshot 读关注从“仅限事务内”扩展到了普通读操作，且默认启用 enableMajorityReadConcern: true。这意味着：
- 非事务的长时间分析查询（比如报表导出），也能获得一致的快照视图，不再受写入干扰
- 事务内读取与事务外
snapshot读共享同一套快照历史管理机制，WiredTiger 的快照保留更稳定，尾延迟下降明显 - 注意：
snapshot读不保证实时性，它读的是某个已提交版本，对低延迟敏感场景需权衡
分片集群中事务提交返回时机更可控
5.0 开始，分片事务支持显式控制 w（写关注）和 j（journal）行为，尤其影响 commitTransaction 的响应：
- 旧版本（4.4）中，分片事务提交后必须等所有分片确认写入磁盘才返回，网络抖动易导致超时
- 5.0 允许配置
writeConcern: { w: "majority", j: false }，牺牲一点持久性换取更快的提交确认 - 配合默认
w: "majority"的写关注，事务真正落地的可靠性比 4.4 更高，不再是“写完就认为成功” - 但要注意：如果业务依赖
commitTransaction返回即代表数据已落盘，需显式设j: true，否则可能因节点崩溃丢失
真正容易被忽略的是：窗口函数本身不参与事务原子性——哪怕整个聚合管道在事务中运行，$window 计算过程不记录 oplog，也不受事务回滚影响。它的“一致性”完全依赖底层快照，而非事务日志。所以别指望用窗口函数做事务内的中间状态校验。
