ASP.NET MVC Scoped依赖注入跨AJAX请求生命周期问题

核心结论 #

ASP.NET MVC全版本（含MVC5、Core MVC）的Scoped生命周期服务标准行为为：单实例严格绑定单次HTTP请求上下文，请求结束后实例立即被释放，绝对不会跨任何独立请求（包括页面首次加载、后续AJAX请求）存续。你观察到的“首次请求创建的实例在后续AJAX调用中一直存活”既不是框架标准行为，也不是本地运行环境的特殊效果，本质是实现逻辑或验证方式存在偏差导致的误判。

常见误判原因 #

你可以按以下顺序排查问题：

• 服务注册生命周期配置错误：不管是用内置DI容器还是第三方Autofac、Unity等容器，如果注册时误选了单例（Singleton）生命周期，整个应用运行周期内只会生成一个服务实例，所有请求拿到的都是同一个对象，自然会出现“跨请求存续”的表现。
• 实例同一性判断逻辑错误：如果你通过自定义ID字段、内存中标记值判断是否为同一实例，需要检查ID生成逻辑是否依赖静态变量、单例服务字段。如果ID生成逻辑没有为每个新实例生成唯一值，哪怕实例是全新创建的，也会被误判为旧实例。另外本地调试时如果断点命中条件配置错误、开启了VS调试优化，可能出现构造函数只命中第一次断点的情况，不要以此作为实例未重建的依据。
• 状态存储位置错误：如果你把筛选状态存在服务的静态字段、全局单例依赖、本地内存缓存组件中，就算Scoped服务每次请求都重建，新实例读取到全局存储的旧状态时，也会让人误以为是旧实例存续。
• 前端请求异常：如果AJAX请求触发了浏览器缓存、请求没有实际发送到服务端，会让你误以为后端返回的结果是基于旧实例状态生成的，可以通过浏览器开发者工具的网络面板确认请求是否真实发送、状态码是否为200而非304。

正确实现方案 #

Scoped服务天生不支持跨请求存储状态，你要实现的筛选状态留存需求可以选择以下方案实现：

• 无状态方案：前端维护全量筛选条件，每次AJAX请求把当前所有筛选参数完整提交到后端，后端不存储任何会话状态，拿到参数直接查询云端数据即可，这是稳定性最高、适配分布式部署场景的方案。
• 分布式缓存方案：前端为当前筛选会话生成唯一标识存在Cookie或LocalStorage中，后端用分布式缓存（如Redis、云端托管缓存服务）按会话标识存储对应的筛选状态，每次请求携带会话标识读取对应状态即可，注意不要用本地内存缓存存储，多实例部署时会出现状态不一致问题。
• 用户维度存储方案：针对已登录用户，可以直接把筛选偏好、历史状态关联用户ID存储在数据库中，每次请求按用户ID读取即可。

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