禁用DatabaseFacade.AutoSavepointsEnabled为何会引发数据库损坏风险？

首先明确EF Core中自动保存点的核心逻辑：它仅在手动开启的事务中，每次调用SaveChanges()时创建，作用是当单次SaveChanges()执行失败时，可回滚到本次操作前的状态，无需回滚整个外层事务。

禁用自动保存点的“损坏风险”本质 #

警告里的“数据库损坏”并非物理层面的损坏，而是指业务数据的不一致状态，核心触发场景包括：

• 手动事务内多次调用SaveChanges()：第一次SaveChanges()成功写入数据，第二次执行失败。若无自动保存点，外层事务回滚会撤销第一次的修改，但如果两次操作间存在无法回滚的外部依赖（如调用第三方API、发送消息通知），就会出现数据库数据与外部系统状态不一致的情况，这属于业务层面的“损坏”。
• 部分操作成功的场景：比如批量更新中部分行执行成功、部分失败，没有保存点的话，无法精准回滚本次失败操作，外层事务回滚会丢失之前所有已成功的修改；而有保存点时，可仅回滚本次失败操作，保留之前的有效修改（需配合手动逻辑处理）。

重试场景下的自动保存点价值分析 #

在你司“SaveChanges()抛出异常就重试整个事务”的环境中：

• 若重试逻辑是完全重新开启事务、从头执行所有操作，那么自动保存点确实只会带来PostgreSQL的子事务额外开销——因为每次重试都是独立的完整事务，失败后会完全回滚，不存在部分修改残留的问题，此时禁用自动保存点是合理的。
• 若重试逻辑是在同一个事务内重复调用SaveChanges()（捕获异常后不回滚外层事务直接重试），禁用自动保存点就会有风险：第一次SaveChanges()可能已修改部分数据，重试时会在已有修改基础上继续操作，导致数据混乱。

总结：警告的“严重程度”是针对复杂多步事务场景的，若你确认重试逻辑是完整的事务重试，禁用自动保存点来降低PostgreSQL子事务开销是可行的，但必须确保所有失败都会触发整个事务的完全回滚，避免部分修改残留。

内容的提问来源于stack exchange，提问作者DVN237294