ASP.NET Core 试题 47：EF Core 迁移、事务与并发
0921 在 生产迁移 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 每个 Pod 启动时同时 Migrate 是最安全的零停机方案
- B. 多个应用副本启动时自动 Migrate 可能竞争，且应用账户不应长期拥有 DDL 权限
- C. 生产更适合由受控流水线审核并应用迁移脚本或 Bundle
- D. 观察到“滚动发布时多个实例争抢架构变更”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 生产迁移 的主规则：生产更适合由受控流水线审核并应用迁移脚本或 Bundle。选项“多个应用副本启动时自动 Migrate 可能竞争，且应用账户不应长期拥有 DDL 权限”是使用规则时要验证的边界，不是规则本身；“每个 Pod 启动时同时 Migrate 是最安全的零停机方案”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0922 滚动发布时多个实例争抢架构变更。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“每个 Pod 启动时同时 Migrate 是最安全的零停机方案”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“多个应用副本启动时自动 Migrate 可能竞争，且应用账户不应长期拥有 DDL 权限”。
- C. 以一次成功请求作为结论，不再确认“生产更适合由受控流水线审核并应用迁移脚本或 Bundle”是否成立。
- D. 先验证“多个应用副本启动时自动 Migrate 可能竞争，且应用账户不应长期拥有 DDL 权限”，再依据“生产更适合由受控流水线审核并应用迁移脚本或 Bundle”判断实现是否符合契约。
查看答案与解析
正确答案D
场景“滚动发布时多个实例争抢架构变更”指向 生产迁移，但症状本身不能证明根因。正确排查应先确认边界“多个应用副本启动时自动 Migrate 可能竞争，且应用账户不应长期拥有 DDL 权限”，再用主规则“生产更适合由受控流水线审核并应用迁移脚本或 Bundle”解释证据。直接采用误区“每个 Pod 启动时同时 Migrate 是最安全的零停机方案”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0923 关于 生产迁移，以下哪项说法不成立？
难度： 实战
- A. 生产更适合由受控流水线审核并应用迁移脚本或 Bundle
- B. 每个 Pod 启动时同时 Migrate 是最安全的零停机方案
- C. 多个应用副本启动时自动 Migrate 可能竞争，且应用账户不应长期拥有 DDL 权限
- D. 出现“滚动发布时多个实例争抢架构变更”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“每个 Pod 启动时同时 Migrate 是最安全的零停机方案”正是 生产迁移 的典型误区。其余三项分别给出了主规则“生产更适合由受控流水线审核并应用迁移脚本或 Bundle”、适用边界“多个应用副本启动时自动 Migrate 可能竞争，且应用账户不应长期拥有 DDL 权限”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0924 针对“滚动发布时多个实例争抢架构变更”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“生产更适合由受控流水线审核并应用迁移脚本或 Bundle”修正实现，并用测试或遥测验证“多个应用副本启动时自动 Migrate 可能竞争，且应用账户不应长期拥有 DDL 权限”。
- B. 按“每个 Pod 启动时同时 Migrate 是最安全的零停机方案”修改实现，并把一次请求成功作为验收结果。
- C. 按“生产更适合由受控流水线审核并应用迁移脚本或 Bundle”修改代码后直接上线，不验证“多个应用副本启动时自动 Migrate 可能竞争，且应用账户不应长期拥有 DDL 权限”。
- D. 只验证“多个应用副本启动时自动 Migrate 可能竞争，且应用账户不应长期拥有 DDL 权限”，但实现仍继续依赖“每个 Pod 启动时同时 Migrate 是最安全的零停机方案”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：生产更适合由受控流水线审核并应用迁移脚本或 Bundle；并确认 多个应用副本启动时自动 Migrate 可能竞争，且应用账户不应长期拥有 DDL 权限。继续接受“每个 Pod 启动时同时 Migrate 是最安全的零停机方案”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“滚动发布时多个实例争抢架构变更”这一生产场景能否安全上线。
0925 在 SaveChanges 事务 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 一次 SaveChanges 会自动把消息队列发布纳入同一数据库事务
- B. 跨多次 SaveChanges、外部消息和其他数据库需要显式一致性设计
- C. 观察到“数据库提交成功但消息发送失败”即可把一次现象当成完整框架契约。
- D. 关系数据库提供程序通常把一次 SaveChanges 中的多项变更放入事务
查看答案与解析
正确答案D
正确答案直接描述 SaveChanges 事务 的主规则：关系数据库提供程序通常把一次 SaveChanges 中的多项变更放入事务。选项“跨多次 SaveChanges、外部消息和其他数据库需要显式一致性设计”是使用规则时要验证的边界，不是规则本身；“一次 SaveChanges 会自动把消息队列发布纳入同一数据库事务”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0926 数据库提交成功但消息发送失败。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“一次 SaveChanges 会自动把消息队列发布纳入同一数据库事务”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“跨多次 SaveChanges、外部消息和其他数据库需要显式一致性设计”。
- C. 先验证“跨多次 SaveChanges、外部消息和其他数据库需要显式一致性设计”，再依据“关系数据库提供程序通常把一次 SaveChanges 中的多项变更放入事务”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“关系数据库提供程序通常把一次 SaveChanges 中的多项变更放入事务”是否成立。
查看答案与解析
正确答案C
场景“数据库提交成功但消息发送失败”指向 SaveChanges 事务，但症状本身不能证明根因。正确排查应先确认边界“跨多次 SaveChanges、外部消息和其他数据库需要显式一致性设计”，再用主规则“关系数据库提供程序通常把一次 SaveChanges 中的多项变更放入事务”解释证据。直接采用误区“一次 SaveChanges 会自动把消息队列发布纳入同一数据库事务”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0927 关于 SaveChanges 事务，以下哪项说法不成立？
难度： 实战
- A. 一次 SaveChanges 会自动把消息队列发布纳入同一数据库事务
- B. 关系数据库提供程序通常把一次 SaveChanges 中的多项变更放入事务
- C. 跨多次 SaveChanges、外部消息和其他数据库需要显式一致性设计
- D. 出现“数据库提交成功但消息发送失败”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“一次 SaveChanges 会自动把消息队列发布纳入同一数据库事务”正是 SaveChanges 事务 的典型误区。其余三项分别给出了主规则“关系数据库提供程序通常把一次 SaveChanges 中的多项变更放入事务”、适用边界“跨多次 SaveChanges、外部消息和其他数据库需要显式一致性设计”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0928 针对“数据库提交成功但消息发送失败”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“一次 SaveChanges 会自动把消息队列发布纳入同一数据库事务”修改实现，并把一次请求成功作为验收结果。
- B. 按“关系数据库提供程序通常把一次 SaveChanges 中的多项变更放入事务”修正实现，并用测试或遥测验证“跨多次 SaveChanges、外部消息和其他数据库需要显式一致性设计”。
- C. 按“关系数据库提供程序通常把一次 SaveChanges 中的多项变更放入事务”修改代码后直接上线，不验证“跨多次 SaveChanges、外部消息和其他数据库需要显式一致性设计”。
- D. 只验证“跨多次 SaveChanges、外部消息和其他数据库需要显式一致性设计”，但实现仍继续依赖“一次 SaveChanges 会自动把消息队列发布纳入同一数据库事务”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：关系数据库提供程序通常把一次 SaveChanges 中的多项变更放入事务；并确认 跨多次 SaveChanges、外部消息和其他数据库需要显式一致性设计。继续接受“一次 SaveChanges 会自动把消息队列发布纳入同一数据库事务”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“数据库提交成功但消息发送失败”这一生产场景能否安全上线。
0929 在 执行策略与事务 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 启用重试执行策略时，用户创建事务中的整个操作单元应通过 ExecutionStrategy 执行
- B. 在任意自建事务内数据库驱动会自动安全重放所有业务代码
- C. 只重试事务中间一条命令可能破坏原子性，提交结果未知时还要考虑幂等
- D. 观察到“瞬态故障重试导致重复订单”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 执行策略与事务 的主规则：启用重试执行策略时，用户创建事务中的整个操作单元应通过 ExecutionStrategy 执行。选项“只重试事务中间一条命令可能破坏原子性，提交结果未知时还要考虑幂等”是使用规则时要验证的边界，不是规则本身；“在任意自建事务内数据库驱动会自动安全重放所有业务代码”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0930 瞬态故障重试导致重复订单。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“在任意自建事务内数据库驱动会自动安全重放所有业务代码”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“只重试事务中间一条命令可能破坏原子性，提交结果未知时还要考虑幂等”。
- C. 先验证“只重试事务中间一条命令可能破坏原子性，提交结果未知时还要考虑幂等”，再依据“启用重试执行策略时，用户创建事务中的整个操作单元应通过 ExecutionStrategy 执行”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“启用重试执行策略时，用户创建事务中的整个操作单元应通过 ExecutionStrategy 执行”是否成立。
查看答案与解析
正确答案C
场景“瞬态故障重试导致重复订单”指向 执行策略与事务，但症状本身不能证明根因。正确排查应先确认边界“只重试事务中间一条命令可能破坏原子性，提交结果未知时还要考虑幂等”，再用主规则“启用重试执行策略时，用户创建事务中的整个操作单元应通过 ExecutionStrategy 执行”解释证据。直接采用误区“在任意自建事务内数据库驱动会自动安全重放所有业务代码”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0931 关于 执行策略与事务，以下哪项说法不成立？
难度： 实战
- A. 启用重试执行策略时，用户创建事务中的整个操作单元应通过 ExecutionStrategy 执行
- B. 只重试事务中间一条命令可能破坏原子性，提交结果未知时还要考虑幂等
- C. 出现“瞬态故障重试导致重复订单”时，应收集证据并同时核对主规则与适用边界。
- D. 在任意自建事务内数据库驱动会自动安全重放所有业务代码
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“在任意自建事务内数据库驱动会自动安全重放所有业务代码”正是 执行策略与事务 的典型误区。其余三项分别给出了主规则“启用重试执行策略时，用户创建事务中的整个操作单元应通过 ExecutionStrategy 执行”、适用边界“只重试事务中间一条命令可能破坏原子性，提交结果未知时还要考虑幂等”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0932 针对“瞬态故障重试导致重复订单”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“在任意自建事务内数据库驱动会自动安全重放所有业务代码”修改实现，并把一次请求成功作为验收结果。
- B. 按“启用重试执行策略时，用户创建事务中的整个操作单元应通过 ExecutionStrategy 执行”修正实现，并用测试或遥测验证“只重试事务中间一条命令可能破坏原子性，提交结果未知时还要考虑幂等”。
- C. 按“启用重试执行策略时，用户创建事务中的整个操作单元应通过 ExecutionStrategy 执行”修改代码后直接上线，不验证“只重试事务中间一条命令可能破坏原子性，提交结果未知时还要考虑幂等”。
- D. 只验证“只重试事务中间一条命令可能破坏原子性，提交结果未知时还要考虑幂等”，但实现仍继续依赖“在任意自建事务内数据库驱动会自动安全重放所有业务代码”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：启用重试执行策略时，用户创建事务中的整个操作单元应通过 ExecutionStrategy 执行；并确认 只重试事务中间一条命令可能破坏原子性，提交结果未知时还要考虑幂等。继续接受“在任意自建事务内数据库驱动会自动安全重放所有业务代码”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“瞬态故障重试导致重复订单”这一生产场景能否安全上线。
0933 在 乐观并发 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 添加 RowVersion 后 EF 会自动重试直到当前写入获胜
- B. 并发令牌使 UPDATE 或 DELETE 条件包含原版本，受影响行数为零时抛 DbUpdateConcurrencyException
- C. 捕获后要选择重试、合并或提示冲突，不能无条件覆盖客户端和数据库值
- D. 观察到“两个用户编辑时后保存者静默覆盖”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 乐观并发 的主规则：并发令牌使 UPDATE 或 DELETE 条件包含原版本，受影响行数为零时抛 DbUpdateConcurrencyException。选项“捕获后要选择重试、合并或提示冲突，不能无条件覆盖客户端和数据库值”是使用规则时要验证的边界，不是规则本身；“添加 RowVersion 后 EF 会自动重试直到当前写入获胜”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0934 两个用户编辑时后保存者静默覆盖。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“添加 RowVersion 后 EF 会自动重试直到当前写入获胜”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“捕获后要选择重试、合并或提示冲突，不能无条件覆盖客户端和数据库值”。
- C. 先验证“捕获后要选择重试、合并或提示冲突，不能无条件覆盖客户端和数据库值”，再依据“并发令牌使 UPDATE 或 DELETE 条件包含原版本，受影响行数为零时抛 DbUpdateConcurrencyException”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“并发令牌使 UPDATE 或 DELETE 条件包含原版本，受影响行数为零时抛 DbUpdateConcurrencyException”是否成立。
查看答案与解析
正确答案C
场景“两个用户编辑时后保存者静默覆盖”指向 乐观并发，但症状本身不能证明根因。正确排查应先确认边界“捕获后要选择重试、合并或提示冲突，不能无条件覆盖客户端和数据库值”，再用主规则“并发令牌使 UPDATE 或 DELETE 条件包含原版本，受影响行数为零时抛 DbUpdateConcurrencyException”解释证据。直接采用误区“添加 RowVersion 后 EF 会自动重试直到当前写入获胜”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0935 关于 乐观并发，以下哪项说法不成立？
难度： 实战
- A. 添加 RowVersion 后 EF 会自动重试直到当前写入获胜
- B. 并发令牌使 UPDATE 或 DELETE 条件包含原版本，受影响行数为零时抛 DbUpdateConcurrencyException
- C. 捕获后要选择重试、合并或提示冲突，不能无条件覆盖客户端和数据库值
- D. 出现“两个用户编辑时后保存者静默覆盖”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“添加 RowVersion 后 EF 会自动重试直到当前写入获胜”正是 乐观并发 的典型误区。其余三项分别给出了主规则“并发令牌使 UPDATE 或 DELETE 条件包含原版本，受影响行数为零时抛 DbUpdateConcurrencyException”、适用边界“捕获后要选择重试、合并或提示冲突，不能无条件覆盖客户端和数据库值”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0936 针对“两个用户编辑时后保存者静默覆盖”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“添加 RowVersion 后 EF 会自动重试直到当前写入获胜”修改实现，并把一次请求成功作为验收结果。
- B. 按“并发令牌使 UPDATE 或 DELETE 条件包含原版本，受影响行数为零时抛 DbUpdateConcurrencyException”修改代码后直接上线，不验证“捕获后要选择重试、合并或提示冲突，不能无条件覆盖客户端和数据库值”。
- C. 只验证“捕获后要选择重试、合并或提示冲突，不能无条件覆盖客户端和数据库值”，但实现仍继续依赖“添加 RowVersion 后 EF 会自动重试直到当前写入获胜”。
- D. 按“并发令牌使 UPDATE 或 DELETE 条件包含原版本，受影响行数为零时抛 DbUpdateConcurrencyException”修正实现，并用测试或遥测验证“捕获后要选择重试、合并或提示冲突，不能无条件覆盖客户端和数据库值”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：并发令牌使 UPDATE 或 DELETE 条件包含原版本，受影响行数为零时抛 DbUpdateConcurrencyException；并确认 捕获后要选择重试、合并或提示冲突，不能无条件覆盖客户端和数据库值。继续接受“添加 RowVersion 后 EF 会自动重试直到当前写入获胜”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“两个用户编辑时后保存者静默覆盖”这一生产场景能否安全上线。
0937 在 保存点 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 保存点等同于提交，回滚后之前变更对其他事务永久可见
- B. SQL Server 开启 MARS 时保存点存在限制，外部事务状态仍需谨慎处理
- C. 已有事务中 SaveChanges 可在支持时创建保存点，失败后回滚到该位置
- D. 观察到“批量步骤失败后希望保留事务内早期工作继续处理”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 保存点 的主规则：已有事务中 SaveChanges 可在支持时创建保存点，失败后回滚到该位置。选项“SQL Server 开启 MARS 时保存点存在限制，外部事务状态仍需谨慎处理”是使用规则时要验证的边界，不是规则本身；“保存点等同于提交，回滚后之前变更对其他事务永久可见”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0938 批量步骤失败后希望保留事务内早期工作继续处理。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“SQL Server 开启 MARS 时保存点存在限制，外部事务状态仍需谨慎处理”，再依据“已有事务中 SaveChanges 可在支持时创建保存点，失败后回滚到该位置”判断实现是否符合契约。
- B. 直接按“保存点等同于提交，回滚后之前变更对其他事务永久可见”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“SQL Server 开启 MARS 时保存点存在限制，外部事务状态仍需谨慎处理”。
- D. 以一次成功请求作为结论，不再确认“已有事务中 SaveChanges 可在支持时创建保存点，失败后回滚到该位置”是否成立。
查看答案与解析
正确答案A
场景“批量步骤失败后希望保留事务内早期工作继续处理”指向 保存点，但症状本身不能证明根因。正确排查应先确认边界“SQL Server 开启 MARS 时保存点存在限制，外部事务状态仍需谨慎处理”，再用主规则“已有事务中 SaveChanges 可在支持时创建保存点，失败后回滚到该位置”解释证据。直接采用误区“保存点等同于提交，回滚后之前变更对其他事务永久可见”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0939 关于 保存点，以下哪项说法不成立？
难度： 实战
- A. 已有事务中 SaveChanges 可在支持时创建保存点，失败后回滚到该位置
- B. SQL Server 开启 MARS 时保存点存在限制，外部事务状态仍需谨慎处理
- C. 出现“批量步骤失败后希望保留事务内早期工作继续处理”时，应收集证据并同时核对主规则与适用边界。
- D. 保存点等同于提交，回滚后之前变更对其他事务永久可见
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“保存点等同于提交，回滚后之前变更对其他事务永久可见”正是 保存点 的典型误区。其余三项分别给出了主规则“已有事务中 SaveChanges 可在支持时创建保存点，失败后回滚到该位置”、适用边界“SQL Server 开启 MARS 时保存点存在限制，外部事务状态仍需谨慎处理”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0940 针对“批量步骤失败后希望保留事务内早期工作继续处理”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“保存点等同于提交，回滚后之前变更对其他事务永久可见”修改实现，并把一次请求成功作为验收结果。
- B. 按“已有事务中 SaveChanges 可在支持时创建保存点，失败后回滚到该位置”修正实现，并用测试或遥测验证“SQL Server 开启 MARS 时保存点存在限制，外部事务状态仍需谨慎处理”。
- C. 按“已有事务中 SaveChanges 可在支持时创建保存点，失败后回滚到该位置”修改代码后直接上线，不验证“SQL Server 开启 MARS 时保存点存在限制，外部事务状态仍需谨慎处理”。
- D. 只验证“SQL Server 开启 MARS 时保存点存在限制，外部事务状态仍需谨慎处理”，但实现仍继续依赖“保存点等同于提交，回滚后之前变更对其他事务永久可见”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：已有事务中 SaveChanges 可在支持时创建保存点，失败后回滚到该位置；并确认 SQL Server 开启 MARS 时保存点存在限制，外部事务状态仍需谨慎处理。继续接受“保存点等同于提交，回滚后之前变更对其他事务永久可见”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“批量步骤失败后希望保留事务内早期工作继续处理”这一生产场景能否安全上线。