单请求内传值到视图：ViewData/ViewBag与HttpContext.Items的区别

先明确两个对象的基础属性：

HttpContext.Items：可在当前请求全生命周期内读写的键值对集合，设计目标是供请求处理链路所有环节共享数据。
单请求内做控制器到视图的临时传值，常规推荐用ViewBag或ViewData。

HttpContext在控制器Action中可以直接访问：

public class HomeController : Controller
{
    public IActionResult About()
    {
        var pathBase = HttpContext.Request.PathBase;
        // 写值示例：HttpContext.Items["currentPath"] = pathBase;
        return View();
    }
}

在Razor视图中也可以通过Context属性直接访问：

@{
    var username = Context.User.Identity.Name;
    // 读值示例：var path = Context.Items["currentPath"];
}

Action调用的其他外部服务，也可以通过注入IHttpContextAccessor拿到HttpContext，读写Items里的内容。

两者在控制器传视图场景下的核心区别可以归纳为4点：

• 作用域边界完全不同
  HttpContext.Items是请求级的全局共享存储，没有访问边界：从请求进服务器经过的第一个中间件，到最后响应返回前的所有处理逻辑（中间件、过滤器、控制器、各类注入服务、视图渲染）都能读写Items里的数据。
  ViewBag/ViewData是控制器和视图之间的专属传值通道，作用域非常窄：它是Controller类实例的内部属性，在中间件执行、控制器还没实例化的阶段根本不存在，Action调用的外部服务也碰不到这部分数据，视图渲染完成后数据就直接释放，不会泄露到其他处理环节。
• 生命周期绑定逻辑不同
  HttpContext.Items和整个请求的HttpContext绑定，只要是同一个请求，哪怕内部做了路径重写、转发到其他Action处理，Items里存的数据都不会丢，直到请求完整结束才会销毁。只有客户端重定向这类发起全新请求的操作，才会生成新的Items集合。
  ViewBag/ViewData和当前Action的执行流程绑定，只要当前Action执行完切换到其他Action（比如服务器端跳转、异常进入错误处理页），原来存的ViewBag/ViewData数据就会被清空，新的Action会生成自己的全新ViewData字典。
• 设计定位完全不同
  HttpContext.Items从一开始就不是给控制器传视图做的，它的作用是存跨组件共用的请求级公共数据，比如链路追踪ID、中间件解析出来的租户信息、全请求通用的临时状态。如果硬拿它传值到视图，很容易出键名冲突——毕竟请求链路上的其他中间件、第三方组件也会往Items里写数据，万一重名直接就把你的值覆盖了，排查起来非常麻烦。
  ViewBag/ViewData天生就是为MVC控制器向视图传值设计的：ViewData是字典结构，ViewBag是套在ViewData外面的动态语法糖，俩存的是同一份数据。它的存储是当前控制器和对应视图独有的，不会和其他组件的存储撞键，语义上就是「当前Action传给对应视图的临时数据」，是这个场景的标准用法。
• 数据隔离性不同
  往HttpContext.Items里写值本质是在请求里放全局变量，链路上任何逻辑都能随便改，很容易出现意料之外的数据污染。而ViewBag/ViewData是控制器和视图之间的专属通道，数据会默认传递给关联的布局页、当前直接渲染的部分视图，不会暴露给其他处理逻辑，隔离性好很多。

实际开发里如果只是控制器给视图传临时数据，优先用ViewBag/ViewData，传结构化数据直接用强类型ViewModel就行，HttpContext.Items留给全链路共享数据的场景用，不要混用。

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