ASP.NET Core 试题 45：EF Core DbContext 与跟踪
0881 在 DbContext 生命周期 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. AddDbContext 默认把 DbContext 注册为 Scoped，常与单个 HTTP 请求工作单元对齐
- B. Scoped DbContext 可以安全地跨请求缓存到 Singleton
- C. 一个请求可能含多个工作单元，后台任务要自行创建作用域；Context 应及时释放
- D. 观察到“并发请求共享 ChangeTracker 导致异常”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案A
正确答案直接描述 DbContext 生命周期 的主规则：AddDbContext 默认把 DbContext 注册为 Scoped，常与单个 HTTP 请求工作单元对齐。选项“一个请求可能含多个工作单元，后台任务要自行创建作用域；Context 应及时释放”是使用规则时要验证的边界，不是规则本身；“Scoped DbContext 可以安全地跨请求缓存到 Singleton”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0882 并发请求共享 ChangeTracker 导致异常。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“Scoped DbContext 可以安全地跨请求缓存到 Singleton”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“一个请求可能含多个工作单元，后台任务要自行创建作用域；Context 应及时释放”。
- C. 先验证“一个请求可能含多个工作单元，后台任务要自行创建作用域；Context 应及时释放”，再依据“AddDbContext 默认把 DbContext 注册为 Scoped，常与单个 HTTP 请求工作单元对齐”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“AddDbContext 默认把 DbContext 注册为 Scoped，常与单个 HTTP 请求工作单元对齐”是否成立。
查看答案与解析
正确答案C
场景“并发请求共享 ChangeTracker 导致异常”指向 DbContext 生命周期，但症状本身不能证明根因。正确排查应先确认边界“一个请求可能含多个工作单元，后台任务要自行创建作用域；Context 应及时释放”，再用主规则“AddDbContext 默认把 DbContext 注册为 Scoped，常与单个 HTTP 请求工作单元对齐”解释证据。直接采用误区“Scoped DbContext 可以安全地跨请求缓存到 Singleton”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0883 关于 DbContext 生命周期，以下哪项说法不成立？
难度： 实战
- A. AddDbContext 默认把 DbContext 注册为 Scoped，常与单个 HTTP 请求工作单元对齐
- B. 一个请求可能含多个工作单元，后台任务要自行创建作用域；Context 应及时释放
- C. 出现“并发请求共享 ChangeTracker 导致异常”时，应收集证据并同时核对主规则与适用边界。
- D. Scoped DbContext 可以安全地跨请求缓存到 Singleton
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“Scoped DbContext 可以安全地跨请求缓存到 Singleton”正是 DbContext 生命周期 的典型误区。其余三项分别给出了主规则“AddDbContext 默认把 DbContext 注册为 Scoped，常与单个 HTTP 请求工作单元对齐”、适用边界“一个请求可能含多个工作单元，后台任务要自行创建作用域；Context 应及时释放”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0884 针对“并发请求共享 ChangeTracker 导致异常”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“Scoped DbContext 可以安全地跨请求缓存到 Singleton”修改实现，并把一次请求成功作为验收结果。
- B. 按“AddDbContext 默认把 DbContext 注册为 Scoped，常与单个 HTTP 请求工作单元对齐”修正实现，并用测试或遥测验证“一个请求可能含多个工作单元，后台任务要自行创建作用域；Context 应及时释放”。
- C. 按“AddDbContext 默认把 DbContext 注册为 Scoped，常与单个 HTTP 请求工作单元对齐”修改代码后直接上线，不验证“一个请求可能含多个工作单元，后台任务要自行创建作用域；Context 应及时释放”。
- D. 只验证“一个请求可能含多个工作单元，后台任务要自行创建作用域；Context 应及时释放”，但实现仍继续依赖“Scoped DbContext 可以安全地跨请求缓存到 Singleton”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：AddDbContext 默认把 DbContext 注册为 Scoped，常与单个 HTTP 请求工作单元对齐；并确认 一个请求可能含多个工作单元，后台任务要自行创建作用域；Context 应及时释放。继续接受“Scoped DbContext 可以安全地跨请求缓存到 Singleton”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“并发请求共享 ChangeTracker 导致异常”这一生产场景能否安全上线。
0885 在 DbContext 线程安全 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 同一个 DbContext 上使用 Task.WhenAll 查询是推荐的并行优化
- B. DbContext 不支持多个并行操作，异步查询应立即 await 后再发下一操作
- C. 需要并行数据库工作时应创建独立 Context，并考虑事务与连接压力
- D. 观察到“运行时报第二个操作在前一个完成前开始”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案B
正确答案直接描述 DbContext 线程安全 的主规则：DbContext 不支持多个并行操作，异步查询应立即 await 后再发下一操作。选项“需要并行数据库工作时应创建独立 Context，并考虑事务与连接压力”是使用规则时要验证的边界，不是规则本身；“同一个 DbContext 上使用 Task.WhenAll 查询是推荐的并行优化”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0886 运行时报第二个操作在前一个完成前开始。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“同一个 DbContext 上使用 Task.WhenAll 查询是推荐的并行优化”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“需要并行数据库工作时应创建独立 Context，并考虑事务与连接压力”。
- C. 先验证“需要并行数据库工作时应创建独立 Context，并考虑事务与连接压力”，再依据“DbContext 不支持多个并行操作，异步查询应立即 await 后再发下一操作”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“DbContext 不支持多个并行操作，异步查询应立即 await 后再发下一操作”是否成立。
查看答案与解析
正确答案C
场景“运行时报第二个操作在前一个完成前开始”指向 DbContext 线程安全，但症状本身不能证明根因。正确排查应先确认边界“需要并行数据库工作时应创建独立 Context，并考虑事务与连接压力”，再用主规则“DbContext 不支持多个并行操作，异步查询应立即 await 后再发下一操作”解释证据。直接采用误区“同一个 DbContext 上使用 Task.WhenAll 查询是推荐的并行优化”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0887 关于 DbContext 线程安全，以下哪项说法不成立？
难度： 实战
- A. 同一个 DbContext 上使用 Task.WhenAll 查询是推荐的并行优化
- B. DbContext 不支持多个并行操作，异步查询应立即 await 后再发下一操作
- C. 需要并行数据库工作时应创建独立 Context，并考虑事务与连接压力
- D. 出现“运行时报第二个操作在前一个完成前开始”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案A
题目要求选出不成立的说法，答案“同一个 DbContext 上使用 Task.WhenAll 查询是推荐的并行优化”正是 DbContext 线程安全 的典型误区。其余三项分别给出了主规则“DbContext 不支持多个并行操作，异步查询应立即 await 后再发下一操作”、适用边界“需要并行数据库工作时应创建独立 Context，并考虑事务与连接压力”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0888 针对“运行时报第二个操作在前一个完成前开始”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“同一个 DbContext 上使用 Task.WhenAll 查询是推荐的并行优化”修改实现，并把一次请求成功作为验收结果。
- B. 按“DbContext 不支持多个并行操作，异步查询应立即 await 后再发下一操作”修改代码后直接上线，不验证“需要并行数据库工作时应创建独立 Context，并考虑事务与连接压力”。
- C. 只验证“需要并行数据库工作时应创建独立 Context，并考虑事务与连接压力”，但实现仍继续依赖“同一个 DbContext 上使用 Task.WhenAll 查询是推荐的并行优化”。
- D. 按“DbContext 不支持多个并行操作，异步查询应立即 await 后再发下一操作”修正实现，并用测试或遥测验证“需要并行数据库工作时应创建独立 Context，并考虑事务与连接压力”。
查看答案与解析
正确答案D
完整决策同时覆盖规则与验证：DbContext 不支持多个并行操作，异步查询应立即 await 后再发下一操作；并确认 需要并行数据库工作时应创建独立 Context，并考虑事务与连接压力。继续接受“同一个 DbContext 上使用 Task.WhenAll 查询是推荐的并行优化”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“运行时报第二个操作在前一个完成前开始”这一生产场景能否安全上线。
0889 在 跟踪查询 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 跟踪查询每次遇到同一键都会创建全新实体实例
- B. 只读大查询会产生跟踪和快照成本，可投影或使用 AsNoTracking
- C. 跟踪查询把实体加入 ChangeTracker，并对同一键进行身份解析，适合后续更新
- D. 观察到“同一 Context 查询后修改实体无法保存”即可把一次现象当成完整框架契约。
查看答案与解析
正确答案C
正确答案直接描述 跟踪查询 的主规则：跟踪查询把实体加入 ChangeTracker，并对同一键进行身份解析，适合后续更新。选项“只读大查询会产生跟踪和快照成本，可投影或使用 AsNoTracking”是使用规则时要验证的边界，不是规则本身；“跟踪查询每次遇到同一键都会创建全新实体实例”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0890 同一 Context 查询后修改实体无法保存。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“只读大查询会产生跟踪和快照成本，可投影或使用 AsNoTracking”，再依据“跟踪查询把实体加入 ChangeTracker，并对同一键进行身份解析，适合后续更新”判断实现是否符合契约。
- B. 直接按“跟踪查询每次遇到同一键都会创建全新实体实例”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“只读大查询会产生跟踪和快照成本，可投影或使用 AsNoTracking”。
- D. 以一次成功请求作为结论，不再确认“跟踪查询把实体加入 ChangeTracker，并对同一键进行身份解析，适合后续更新”是否成立。
查看答案与解析
正确答案A
场景“同一 Context 查询后修改实体无法保存”指向 跟踪查询，但症状本身不能证明根因。正确排查应先确认边界“只读大查询会产生跟踪和快照成本，可投影或使用 AsNoTracking”，再用主规则“跟踪查询把实体加入 ChangeTracker，并对同一键进行身份解析，适合后续更新”解释证据。直接采用误区“跟踪查询每次遇到同一键都会创建全新实体实例”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0891 关于 跟踪查询，以下哪项说法不成立？
难度： 实战
- A. 跟踪查询把实体加入 ChangeTracker，并对同一键进行身份解析，适合后续更新
- B. 只读大查询会产生跟踪和快照成本，可投影或使用 AsNoTracking
- C. 出现“同一 Context 查询后修改实体无法保存”时，应收集证据并同时核对主规则与适用边界。
- D. 跟踪查询每次遇到同一键都会创建全新实体实例
查看答案与解析
正确答案D
题目要求选出不成立的说法，答案“跟踪查询每次遇到同一键都会创建全新实体实例”正是 跟踪查询 的典型误区。其余三项分别给出了主规则“跟踪查询把实体加入 ChangeTracker，并对同一键进行身份解析，适合后续更新”、适用边界“只读大查询会产生跟踪和快照成本，可投影或使用 AsNoTracking”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0892 针对“同一 Context 查询后修改实体无法保存”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“跟踪查询每次遇到同一键都会创建全新实体实例”修改实现，并把一次请求成功作为验收结果。
- B. 按“跟踪查询把实体加入 ChangeTracker，并对同一键进行身份解析，适合后续更新”修正实现，并用测试或遥测验证“只读大查询会产生跟踪和快照成本，可投影或使用 AsNoTracking”。
- C. 按“跟踪查询把实体加入 ChangeTracker，并对同一键进行身份解析，适合后续更新”修改代码后直接上线，不验证“只读大查询会产生跟踪和快照成本，可投影或使用 AsNoTracking”。
- D. 只验证“只读大查询会产生跟踪和快照成本，可投影或使用 AsNoTracking”，但实现仍继续依赖“跟踪查询每次遇到同一键都会创建全新实体实例”。
查看答案与解析
正确答案B
完整决策同时覆盖规则与验证：跟踪查询把实体加入 ChangeTracker，并对同一键进行身份解析，适合后续更新；并确认 只读大查询会产生跟踪和快照成本，可投影或使用 AsNoTracking。继续接受“跟踪查询每次遇到同一键都会创建全新实体实例”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“同一 Context 查询后修改实体无法保存”这一生产场景能否安全上线。
0893 在 AsNoTracking 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. AsNoTracking 会让数据库跳过事务和锁
- B. 无跟踪默认不做常规身份解析；需要去重实例可用 AsNoTrackingWithIdentityResolution
- C. 观察到“只读列表中重复联接实体产生多个对象”即可把一次现象当成完整框架契约。
- D. AsNoTracking 不把结果实体加入 Context 跟踪，适合只读结果
查看答案与解析
正确答案D
正确答案直接描述 AsNoTracking 的主规则：AsNoTracking 不把结果实体加入 Context 跟踪，适合只读结果。选项“无跟踪默认不做常规身份解析；需要去重实例可用 AsNoTrackingWithIdentityResolution”是使用规则时要验证的边界，不是规则本身；“AsNoTracking 会让数据库跳过事务和锁”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0894 只读列表中重复联接实体产生多个对象。排查时哪项动作最合理？
难度： 进阶
- A. 先验证“无跟踪默认不做常规身份解析；需要去重实例可用 AsNoTrackingWithIdentityResolution”，再依据“AsNoTracking 不把结果实体加入 Context 跟踪，适合只读结果”判断实现是否符合契约。
- B. 直接按“AsNoTracking 会让数据库跳过事务和锁”定性，不再检查配置、身份或运行时证据。
- C. 只增加重试次数或机器资源，暂不核对“无跟踪默认不做常规身份解析；需要去重实例可用 AsNoTrackingWithIdentityResolution”。
- D. 以一次成功请求作为结论，不再确认“AsNoTracking 不把结果实体加入 Context 跟踪，适合只读结果”是否成立。
查看答案与解析
正确答案A
场景“只读列表中重复联接实体产生多个对象”指向 AsNoTracking，但症状本身不能证明根因。正确排查应先确认边界“无跟踪默认不做常规身份解析；需要去重实例可用 AsNoTrackingWithIdentityResolution”，再用主规则“AsNoTracking 不把结果实体加入 Context 跟踪，适合只读结果”解释证据。直接采用误区“AsNoTracking 会让数据库跳过事务和锁”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0895 关于 AsNoTracking，以下哪项说法不成立？
难度： 实战
- A. AsNoTracking 不把结果实体加入 Context 跟踪，适合只读结果
- B. AsNoTracking 会让数据库跳过事务和锁
- C. 无跟踪默认不做常规身份解析；需要去重实例可用 AsNoTrackingWithIdentityResolution
- D. 出现“只读列表中重复联接实体产生多个对象”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“AsNoTracking 会让数据库跳过事务和锁”正是 AsNoTracking 的典型误区。其余三项分别给出了主规则“AsNoTracking 不把结果实体加入 Context 跟踪，适合只读结果”、适用边界“无跟踪默认不做常规身份解析；需要去重实例可用 AsNoTrackingWithIdentityResolution”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0896 针对“只读列表中重复联接实体产生多个对象”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“AsNoTracking 会让数据库跳过事务和锁”修改实现，并把一次请求成功作为验收结果。
- B. 按“AsNoTracking 不把结果实体加入 Context 跟踪，适合只读结果”修改代码后直接上线，不验证“无跟踪默认不做常规身份解析；需要去重实例可用 AsNoTrackingWithIdentityResolution”。
- C. 按“AsNoTracking 不把结果实体加入 Context 跟踪，适合只读结果”修正实现，并用测试或遥测验证“无跟踪默认不做常规身份解析；需要去重实例可用 AsNoTrackingWithIdentityResolution”。
- D. 只验证“无跟踪默认不做常规身份解析；需要去重实例可用 AsNoTrackingWithIdentityResolution”，但实现仍继续依赖“AsNoTracking 会让数据库跳过事务和锁”。
查看答案与解析
正确答案C
完整决策同时覆盖规则与验证：AsNoTracking 不把结果实体加入 Context 跟踪，适合只读结果；并确认 无跟踪默认不做常规身份解析；需要去重实例可用 AsNoTrackingWithIdentityResolution。继续接受“AsNoTracking 会让数据库跳过事务和锁”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“只读列表中重复联接实体产生多个对象”这一生产场景能否安全上线。
0897 在 DbContext 池 的框架契约中，哪项是应直接依赖的主规则？
难度： 基础
- A. 池化 DbContext 等同于数据库连接池且每个实例永久绑定一条连接
- B. Context 字段中的租户等每请求状态不会由应用自动重置，池化前要验证状态注入方式
- C. 观察到“租户筛选状态泄露到下一请求”即可把一次现象当成完整框架契约。
- D. AddDbContextPool 复用 Context 实例并重置框架状态，降低高频创建成本
查看答案与解析
正确答案D
正确答案直接描述 DbContext 池 的主规则：AddDbContextPool 复用 Context 实例并重置框架状态，降低高频创建成本。选项“Context 字段中的租户等每请求状态不会由应用自动重置，池化前要验证状态注入方式”是使用规则时要验证的边界，不是规则本身；“池化 DbContext 等同于数据库连接池且每个实例永久绑定一条连接”则是会导致错误实现的典型误区。场景只能提供线索，不能替代框架契约。
0898 租户筛选状态泄露到下一请求。排查时哪项动作最合理？
难度： 进阶
- A. 直接按“池化 DbContext 等同于数据库连接池且每个实例永久绑定一条连接”定性，不再检查配置、身份或运行时证据。
- B. 只增加重试次数或机器资源，暂不核对“Context 字段中的租户等每请求状态不会由应用自动重置，池化前要验证状态注入方式”。
- C. 先验证“Context 字段中的租户等每请求状态不会由应用自动重置，池化前要验证状态注入方式”，再依据“AddDbContextPool 复用 Context 实例并重置框架状态，降低高频创建成本”判断实现是否符合契约。
- D. 以一次成功请求作为结论，不再确认“AddDbContextPool 复用 Context 实例并重置框架状态，降低高频创建成本”是否成立。
查看答案与解析
正确答案C
场景“租户筛选状态泄露到下一请求”指向 DbContext 池，但症状本身不能证明根因。正确排查应先确认边界“Context 字段中的租户等每请求状态不会由应用自动重置，池化前要验证状态注入方式”，再用主规则“AddDbContextPool 复用 Context 实例并重置框架状态，降低高频创建成本”解释证据。直接采用误区“池化 DbContext 等同于数据库连接池且每个实例永久绑定一条连接”、只扩容或依赖一次成功都会掩盖真实配置和请求路径。
0899 关于 DbContext 池，以下哪项说法不成立？
难度： 实战
- A. AddDbContextPool 复用 Context 实例并重置框架状态，降低高频创建成本
- B. 池化 DbContext 等同于数据库连接池且每个实例永久绑定一条连接
- C. Context 字段中的租户等每请求状态不会由应用自动重置，池化前要验证状态注入方式
- D. 出现“租户筛选状态泄露到下一请求”时，应收集证据并同时核对主规则与适用边界。
查看答案与解析
正确答案B
题目要求选出不成立的说法，答案“池化 DbContext 等同于数据库连接池且每个实例永久绑定一条连接”正是 DbContext 池 的典型误区。其余三项分别给出了主规则“AddDbContextPool 复用 Context 实例并重置框架状态，降低高频创建成本”、适用边界“Context 字段中的租户等每请求状态不会由应用自动重置，池化前要验证状态注入方式”以及面向场景的正确取证方式，不能因为题干使用否定问法而反选这些有效结论。
0900 针对“租户筛选状态泄露到下一请求”进行上线评审，哪项决策依据最完整？
难度： 实战
- A. 按“AddDbContextPool 复用 Context 实例并重置框架状态，降低高频创建成本”修正实现，并用测试或遥测验证“Context 字段中的租户等每请求状态不会由应用自动重置，池化前要验证状态注入方式”。
- B. 按“池化 DbContext 等同于数据库连接池且每个实例永久绑定一条连接”修改实现，并把一次请求成功作为验收结果。
- C. 按“AddDbContextPool 复用 Context 实例并重置框架状态，降低高频创建成本”修改代码后直接上线，不验证“Context 字段中的租户等每请求状态不会由应用自动重置，池化前要验证状态注入方式”。
- D. 只验证“Context 字段中的租户等每请求状态不会由应用自动重置，池化前要验证状态注入方式”，但实现仍继续依赖“池化 DbContext 等同于数据库连接池且每个实例永久绑定一条连接”。
查看答案与解析
正确答案A
完整决策同时覆盖规则与验证：AddDbContextPool 复用 Context 实例并重置框架状态，降低高频创建成本；并确认 Context 字段中的租户等每请求状态不会由应用自动重置，池化前要验证状态注入方式。继续接受“池化 DbContext 等同于数据库连接池且每个实例永久绑定一条连接”会让评审依据失真；只改代码不验证边界，或只检查边界却沿用误区，都不足以判断“租户筛选状态泄露到下一请求”这一生产场景能否安全上线。