做 ASP.NET Core 开发这些年我见过不少人在控制器和视图之间传值这件事上栽跟头。明明控制器里查了一堆数据视图上却显示不出来明明用了 TempData刷新一下就消失了还有的人干脆把整个数据库上下文从控制器塞给视图搞得页面和业务逻辑搅成一团。项目里加个功能、改个页面本来十分钟的活硬生生折腾一晚上。这篇文章就专门把“ASP.NET Core 控制器与视图之间的传值方式”这一件事讲透。我会先把 ViewData、ViewBag、TempData、强类型 ViewModel 这四种主流方案的工作原理讲清楚再给一个完整可跑的商品管理案例从控制器到视图一行行过代码最后把我自己踩过的坑和排查套路整理成速查表。不管你是刚接触 ASP.NET Core 的新手还是写了两三年 MVC 但一直靠“复制粘贴能用就行”的老油条照着这篇文章捋一遍以后传值基本不会再出幺蛾子。1. 传值方案全景先把手上的牌摸清楚1.1 四种主流传值渠道的底层本质很多人把 ViewData、ViewBag、TempData 混为一谈其实它们的关系比想象中更近。ViewData 的本质是 ViewDataDictionary一个以字符串为 key、object 为 value 的字典。控制器往里面塞值视图按 key 取值整个过程在同一个 HTTP 请求的生命周期内有效。因为 value 是 object从视图里拿出来通常要做一次类型转换。ViewBag 是 C# 4.0 引入 dynamic 特性后对 ViewData 做的一层动态包装。你写 ViewBag.Title编译器实际上会把它转换成对 ViewData[Title] 的访问。它和 ViewData 共享同一份底层字典你往 ViewBag 里放了一个属性用 ViewData 也能按对应 key 取出来。这里有个冷知识ViewData 的 key 比较是不区分大小写的因为 ViewDataDictionary 内部用的是忽略大小写的字符串比较器所以 ViewBag.ProductName 和 ViewBag.productname 其实指向同一个槽位。TempData 表面上也是一个字典底层同样是 ViewDataDictionary但存储位置默认在 Session 里生命周期跨越两次请求而且读取一次之后就会被标记删除。这个“读一次就销毁”的机制是它最大的特点也是最大的坑。使用 TempData 之前一定要确认 Program.cs 里已经启用了 Session否则运行时大概率会抛和依赖注入相关的异常。强类型 ViewModel 则完全不是字典那一套。它就是一个普通 C# 类把页面需要的所有数据封装成属性控制器返回 View(vm) 时把实例传给视图视图顶部用 model 指令声明类型之后在页面上通过 Model. 前缀强类型访问。它不依赖字符串 key编译期就能检查字段是否存在。四种方式最核心的区别在于“存哪”、“活多久”、“要不要转型”。我把这些维度整理成一张表方便你对照维度ViewDataViewBagTempData强类型 ViewModel底层结构ViewDataDictionaryViewData 的动态包装ViewDataDictionary存 Session普通 C# 类生命周期当前请求当前请求跨请求默认读一次清除当前请求类型检查无取出来是 object无编译期不检查属性无取出来是 object有编译期检查智能提示无无无有典型场景页面标题、零散参数少量零散参数表单提交后的跳转提示页面主体数据1.2 选型思路什么场景用哪种方案光知道区别还不够实际项目里到底怎么选这才是关键。我给你一套基于经验的判断框架照着选基本不会错只要传的是页面主体数据——列表、详情、表单回填对象——一律用强类型 ViewModel。它是最不容易出错、最好维护的方案。如果只是传两三个零散字符串比如页面标题、面包屑文本、搜索关键词回填用 ViewBag 或 ViewData 都行我个人习惯用 ViewBag写起来少打几个字符。如果是从 A 控制器方法跳转到 B 控制器方法中间还带着一条“保存成功”之类的提示消息或者临时状态用 TempData。如果数据还要被前端 JavaScript 使用与其在 ViewBag 里塞 JSON 字符串不如直接在 Razor 视图里把 Model 序列化成一个对象交给前端这也是现在比较推荐的做法。对于团队项目我通常会定一条红线除了极少数静态零散文本业务数据一律走强类型。这样代码审查时不用去猜某个 ViewData[xxx] 是从哪个控制器塞进来的更不用在十几个视图之间靠搜索确认 key 的拼写。2. ViewData 与 ViewBag动态传值的老搭档2.1 ViewData 的字典式用法直接看代码。控制器里这么写public IActionResult Index() { ViewData[PageTitle] 商品管理; ViewData[NavActive] product; return View(); }视图里读取h1ViewData[PageTitle]/h1这里有两个细节很多人会忽略。第一ViewData 存进去的是 object在 Razor 里直接输出时Razor 会调用它的 ToString()所以简单展示没问题但如果要参与运算或判断必须先转型。比如{ decimal price Convert.ToDecimal(ViewData[Price] ?? 0); } pprice.ToString(0.00)/p第二读取一个不存在的 key 不会抛异常返回 null。这既是优点也是缺点视图里 ViewData[NotFound] 不会让页面崩溃但如果是因为拼错了 key你会得到一个空白输出排查起来全靠细心。如果你往 ViewData 里放的是一个集合视图里可以这样遍历ul foreach (var item in ViewData[Items] as Liststring) { liitem/li } /ul注意那个as Liststring如果类型不匹配as 表达式返回 nullforeach 会直接抛 NullReferenceException。这种代码写多了你就知道为什么我推荐强类型了。2.2 ViewBag 的动态语法与隐藏关系ViewBag 用起来确实清爽ViewBag.PageTitle 商品管理; ViewBag.NavActive product;视图h1ViewBag.PageTitle/h1但“清爽”是有代价的。ViewBag 的属性名在编译期没有任何检查你写 ViewBag.PageTtleIDE 不会报错运行时也不会有编译错误页面输出的就是空白。这种错误在大型项目里非常隐蔽往往要等到测试阶段才发现。再强调一次ViewBag 和 ViewData 是同一份字典。你可以在控制器里写 ViewBag.Name 张三然后视图里用 ViewData[Name] 取出来。反过来也一样。这个特性在新老代码交接时特别有用老代码用 ViewData新代码用 ViewBag两者可以共存。我在一个后台管理系统改造项目里就靠这个特性把几十个视图从 ViewData 逐步迁移到 ViewBag再最终迁移到 ViewModel一行业务逻辑都没动。2.3 局限与避坑为什么不适合传复杂数据想一个问题如果你要把一个 Product 对象传给视图用 ViewBag 怎么做ViewBag.Product product;视图里怎么用{ var product ViewBag.Product as Product; } h1product.Name/h1如果不加as Product直接写 ViewBag.Product.NameRazor 会尝试在运行期做动态绑定速度会变慢而且如果 ViewBag.Product 是 null抛出的异常比强类型更难看懂。再想第二个问题同一个视图如果被多个控制器方法复用A 方法塞了 ViewBag.TitleB 方法忘了塞页面上就是一片空白你收不到任何编译期提醒。在团队开发中这几乎等于埋雷。还有一个性能上的小细节ViewBag 走的是 dynamic每次属性访问都有额外的动态绑定开销。单次访问影响可以忽略但如果在一个大循环里反复读 ViewBag 里的数据差距就能跑出来。我自己实测过在一个十万次循环里通过 ViewBag 读一个 int比用一个强类型局部变量慢了一个数量级以上。当然这种写法本身就说明代码设计有问题正常业务不该这么用。3. TempData跨请求传值与 PRG 模式3.1 工作原理与“读一次即删”机制TempData 的生命周期跨两次请求这是它和 ViewData 最本质的区别。它的工作流程是第一次写入时数据被保存到 Session默认情况下也可以配置成 Cookie 或自定义提供程序同时打上“待读取”标记在下一次请求里只要该 key 被读取过请求结束时就会从 Session 中移除。这个机制对“一次性消息”非常合适。比如表单保存成功后你希望用户能看到一个绿色提示条并且刷新页面后提示不再出现——这就是典型的一次性消息场景。控制器代码[HttpPost] public IActionResult Create(ProductAddViewModel model) { if (!ModelState.IsValid) { return View(model); } _productService.Add(model); TempData[SuccessMessage] 商品添加成功; return RedirectToAction(Index); }布局页里统一渲染if (TempData[SuccessMessage] ! null) { div classalert alert-successTempData[SuccessMessage]/div }这里用 ! 判断而不是直接输出因为第一次输出之后再次刷新TempData 已经被移除条件不成立提示消失。这正是我们想要的效果。3.2 最经典的用法PRG 模式PRGPost-Redirect-Get是 Web 开发中一个经典模式表单 POST 提交 - 服务器处理成功 - 重定向到 GET 页面。这么做最大的好处是防止用户刷新浏览器时重复提交表单。如果没有 PRG用户提交表单后停留在 POST 结果的页面一按 F5浏览器会提示是否重新提交表单用户点确认同一份数据就写进了数据库两次。加入 RedirectToAction 之后最后一个请求变成了 GET刷新只是重新拉取页面不会再次触发 POST。TempData 在 PRG 模式里承担的角色就是“把 POST 处理结果带到下一个 GET 页面”的中间人。POST 方法里写 TempDataGET 页面里读数据穿过重定向这道墙又不影响用户后续的刷新行为。我见过不少新手把消息塞在 ViewData 里然后 RedirectToAction结果重定向之后 ViewData 全部丢失页面永远显示不出提示。这种问题刚毕业的同事经常问明白了 TempData 的跨请求特性后就不会再犯了。3.3 Peek 与 Keep想让数据多活一会儿TempData 默认读一次就删这是特性但在某些场景会变成麻烦。比如你有一个提示消息希望在“编辑页”和“详情页”连续两页都显示同一个提示。第一次读的时候如果直接访问 TempData[Msg]这个 key 就被标记删除了第二次再读就变成 null。解决方案有两个TempData.Peek(Msg)只读取不标记删除。但只解决“读几次”的问题读过之后数据仍然会在当前请求结束时被清理。TempData.Keep(Msg)手动保留指定的 key让它不在当前请求结束时被移除。也可以不带参数调用 TempData.Keep()表示保留所有 TempData。我建议按顺序使用一次性提示直接用普通读取同一个提示确实需要跨两页显示用 Peek如果业务逻辑更复杂需要多次读取并且跨更长流程那就干脆升级成显式 Session 存储或者重新从数据库读取不要把 TempData 硬当成 Session 用。4. 强类型 ViewModel项目长期正确的选择4.1 为什么要用 ViewModel这一节我要说服你在项目里尽可能用强类型。核心理由有三条。类型安全。控制器和视图之间传递的是一个真正类型的对象属性名拼错了编译直接报错不会等到运行时页面空白。对团队项目来说这省下来的排查时间不是一点半点。可维护性。页面需要的数据结构一目了然。新同事接手打开 ProductDetailViewModel.cs 就知道这个页面需要什么不用满控制器去翻 ViewBag 赋值。便于复用与测试。ViewModel 是普通 C# 类可以单独写单元测试也可以被多个控制器方法复用——列表页和导出功能可能都需要同一组字段组合。4.2 定义与传递的标准写法先定义一个 ViewModelpublic class ProductDetailViewModel { public Product Product { get; set; } public ListProduct RelatedProducts { get; set; } public string CurrentUserName { get; set; } public bool CanEdit { get; set; } }控制器public IActionResult Detail(int id) { var product _productService.GetById(id); if (product null) { return NotFound(); } var viewModel new ProductDetailViewModel { Product product, RelatedProducts _productService.GetRelated(product.CategoryId, 4), CurrentUserName User.Identity.Name, CanEdit _permission.Check(id) }; return View(viewModel); }视图model ProductDetailViewModel h1Model.Product.Name/h1 pModel.Product.Description/p if (Model.CanEdit) { a asp-actionEdit asp-route-idModel.Product.Id编辑/a } h2相关商品/h2 ul foreach (var item in Model.RelatedProducts) { liitem.Name/li } /ul注意视图第一行model ProductDetailViewModel这里的类型需要在对应命名空间下或者在 _ViewImports.cshtml 里全局引入。我习惯把 ViewModel 放在独立命名空间然后在 _ViewImports.cshtml 里批量 using这样每个视图都不用写重复的 using 语句。4.3 ViewModel 的项目规范根据我的经验ViewModel 用得多了之后项目里最大的问题就是命名和位置混乱。整理几个简单规范能让项目干净很多目录结构ViewModel 放在 Models/ViewModels 下或者单独的 ViewModels 目录跟 EF 实体分开一眼就能看出哪些是页面模型、哪些是数据库模型。命名规范统一以 ViewModel 后缀结尾如 ProductDetailViewModel、OrderListViewModel。有些团队习惯用 xxxModel.cs也可以关键是全项目统一。内容规范ViewModel 只放视图要渲染的字段不要把 EF 实体整个暴露出去更不要把 IQueryable 或仓储对象塞进 ViewModel——那等于把数据库访问拖进了页面层。表单场景ViewModel 同时承担输入模型角色配合 DataAnnotations 做输入校验。一个类既承载输出数据也承载用户提交的输入一模型两用。这里有一个常见误区有些人为了省事直接把 EF 实体作为 model 传到视图。小项目看着方便实际一旦遇到需要展示实体之外的信息比如“当前用户是否可编辑”、“这个价格是否含税”要么塞 ViewData要么给实体加一堆不相关属性代码很快会变乱。拆出 ViewModel 是从一开始就该做的决定。5. 完整实操商品管理的传值全流程5.1 场景与项目准备为了把上面这些方式串起来我们做一个小的商品管理功能包含三个页面Index列表页搜索关键词回显 商品列表Detail详情页商品信息 相关商品 权限判断 操作成功提示Edit编辑页表单回填 校验失败回显这里用 ASP.NET Core 6/7/8 通用写法NuGet 包就是标准的 Microsoft.AspNetCore.Mvc。数据库层直接用内存服务代替不引入 EF免得代码被无关细节干扰。项目结构大致长这样Controllers/ ProductController.cs Models/ViewModels/ ProductDetailViewModel.cs ProductEditViewModel.cs Views/Product/ Index.cshtml Detail.cshtml Edit.cshtml Services/ IProductService.cs ProductService.cs5.2 控制器端完整代码public class ProductController : Controller { private readonly IProductService _productService; public ProductController(IProductService productService) { _productService productService; } public IActionResult Index(string keyword) { var products _productService.Search(keyword); // 零散回传信息用 ViewBag ViewBag.Keyword keyword; ViewBag.Count products.Count; return View(products); // 强类型核心数据走模型 } public IActionResult Detail(int id) { var product _productService.GetById(id); if (product null) return NotFound(); var vm new ProductDetailViewModel { Product product, RelatedProducts _productService.GetRelated(product.CategoryId, 4), CanEdit true // 演示简化正式项目换成权限判断 }; return View(vm); } public IActionResult Edit(int id) { var product _productService.GetById(id); if (product null) return NotFound(); var vm new ProductEditViewModel { Id product.Id, Name product.Name, CategoryId product.CategoryId, Price product.Price }; return View(vm); } [HttpPost] [ValidateAntiForgeryToken] public IActionResult Edit(ProductEditViewModel model) { if (!ModelState.IsValid) { return View(model); } _productService.Update(model); TempData[SuccessMessage] 商品信息已更新; return RedirectToAction(nameof(Detail), new { id model.Id }); } }这段代码里三种传值方式都用上了ViewBag 负责搜索关键词、数据条数这类边角信息强类型 ViewModel 负责列表、详情、表单回填TempData 负责编辑成功后的跳转提示。5.3 视图端消费数据的写法Index.cshtmlmodel ListProduct h1商品列表/h1 form methodget asp-actionIndex input typetext namekeyword valueViewBag.Keyword placeholder搜索商品 / button typesubmit搜索/button /form p共 ViewBag.Count 个商品/p ul foreach (var product in Model) { li a asp-actionDetail asp-route-idproduct.Idproduct.Name/a /li } /ul这里有个容易忽略的点搜索框的 value 用的 ViewBag.Keyword。其实查询字符串本身也能回显但让 Controller 在服务器端统一赋值回显更稳定可靠尤其是在查询字符串被编码或做过分词处理之后。用 ViewBag 做搜索条件回显是我觉得它少数不可替代的场景。Detail.cshtmlmodel ProductDetailViewModel if (TempData[SuccessMessage] ! null) { div classalert alert-successTempData[SuccessMessage]/div } h1Model.Product.Name/h1 pModel.Product.Description/p if (Model.CanEdit) { a asp-actionEdit asp-route-idModel.Product.Id编辑/a } h2相关商品/h2 ul foreach (var related in Model.RelatedProducts) { lirelated.Name/li } /ulDetail 页面把两套传值方式完整体现出来ViewModel 承载主体数据TempData 承载跳转提示。Edit.cshtmlmodel ProductEditViewModel form asp-actionEdit methodpost input typehidden asp-forId / div label商品名称/label input asp-forName classform-control / span asp-validation-forName classtext-danger/span /div div label分类/label select asp-forCategoryId asp-itemsViewBag.Categories/select /div div label价格/label input asp-forPrice classform-control / span asp-validation-forPrice classtext-danger/span /div button typesubmit保存/button /form这里涉及一个常见组合下拉框的数据源用 ViewBag 传 SelectList在 Razor 里直接塞给 asp-items 参数很方便。要注意的是如果校验失败返回视图ViewBag.Categories 必须重新赋值否则返回页面时下拉框是空的。可以在 Edit 的 POST 方法里在校验失败分支中重新查一次分类列表。5.4 运行效果与自测清单跑起来之后我们可以验证几个关键行为顺便把它当自测清单在列表页输入“手机”点击搜索地址栏出现?keyword手机搜索框里依然回显“手机”。点击某个商品进入详情标题、描述、相关商品全部正常渲染登录用户能看到“编辑”链接。点击编辑表单正确回填。把名称清空点保存页面停在编辑页校验错误信息显示在对应字段下方刚才输入的其他值没有丢失这是强类型模型配合标签辅助器自动回显的效果底层是 ModelState。修改完成后保存跳回详情页顶部出现绿色提示“商品信息已更新”再刷新一次提示消失。这五条自测就是一次完整的闭环。每条背后对应的传值机制分别是ViewBag 回显、强类型 ViewModel 渲染、强类型回填、ModelState 回显、TempData 一次性提示。6. 常见问题排查与避坑技巧6.1 ViewBag 或 ViewData 在页面拿到 null排查思路按优先级来先确认控制器真的进到了对应方法而不是被某个过滤器拦下、或直接 404 了。可以临时加个日志输出确认。再检查 key 是否拼写一致。ViewBag.ProductName 和 ViewBag.ProductName 看起来一样但空格、缩写差异都会导致取不到值。虽然 ViewData 字典不区分大小写但它区分字符本身是否完全相同。然后确认没有发生重定向。如果控制器里 return RedirectToActionViewBag/ViewData 的数据在当前请求结束就没了必须换成 TempData。最后检查是不是加载了另一个同名视图特别是区域项目里很容易踩到区域视图和普通视图冲突的问题。调试这类问题最直接的手段是在视图最上方把整个 ViewData 打出来foreach (var item in ViewData) { divitem.Key item.Value/div }看到 key 列表再用肉眼比对代码里写的 key几十秒就能定位。6.2 TempData 刷新一次就没了或反过来一直不消失先说“刷新就没了”这其实是正常行为TempData 设计就是读一次即删。你需要在第二个页面也读到同一个值用 TempData.Peek(Key) 代替普通读取。如果只是想在当前请求结束后保留到下一次请求用 TempData.Keep(Key)。再说“一直不消失”通常是因为你在同一个请求里读了好几次第一次读的时候标记了删除但同一请求里第二次读数据还在因为删除动作发生在请求结束时。如果代码里每次都用 Peek数据可能一直留在 Session 里直到过期。检查一下是不是哪里用了 Peek 或者 Keep并且没有显式调用 Remove。另一个坑是自定义类型。TempData 默认存储在 Session 中In-Process 会话一般没问题但如果你把 Session 配置成 Redis、SQL Server 等外部存储存入 TempData 的对象会被序列化自定义类型必须支持序列化否则运行时报错。所以我建议 TempData 只放 string、int 这类简单值。复杂数据需要跨请求时要么显式放 Session要么重新查一次数据库。6.3 强类型视图一直报“模型为 null”或 500最常见的原因是 model 指令拼错或者页面使用了错误的命名空间。还有一种隐蔽情况POST 表单回传时视图用的是 ProductEditViewModel但控制器方法签名的参数类型是 Product类型不匹配导致整个 model 是 nullModelState 也判不完全。这种错误编译器不一定能发现要重点检查控制器方法的参数类型与视图的 model 类型是否一致。另外表单回传时字段的 name 属性必须和模型属性名匹配。使用 asp-for 标签辅助器会自动生成正确的 name但如果你手写input nameproductName就和模型的 Name 属性匹配不上。所以能用标签辅助器就用标签辅助器别手写表单。6.4 集合传值的那些坑视图里声明model ListProduct控制器返回时传的却是 IEnumerable 这种情况下部分 API 能兼容但如果你在视图里调用了依赖具体 List 类型的方法比如 Model.Add编译就会报错。建议视图声明时用 IReadOnlyList 或 IEnumerable 控制器传什么都能接住。还有一种更隐蔽的情况ViewBag.Items 传了个集合视图里用as ListProduct结果 null往往是控制器里放的其实是别的类型比如从匿名对象转换来的。这种问题查起来很费时间我的建议是集合类型的数据一律走 ViewModel不要放 ViewBag。6.5 ModelState 回显的数据来源之谜表单校验失败返回视图时你会发现输入框的值“自动回来了”这是 MVC 的 ModelState 机制在起作用并不是完全来自你返回的 model 对象。具体来说如果 ModelState 里已经存在某个 keyRazor 渲染 asp-for 输入框时会优先使用 ModelState 里的值而不是 Model 的属性值。这个机制带来一个好处校验失败时用户输入什么就回显什么而不是回显数据库里的旧值。但它也有个对应的坑如果你在控制器方法里返回 View(model) 之前手动修改了 model.Name会发现页面上显示的还是 ModelState 里的旧值你的修改被“吞”了。遇到这种情况要么在修改后调用 ModelState.Remove(Name)要么把修改逻辑放在模型绑定之前。这个细节很多人不知道我也是排查了很久才意识到。我自己做项目时的体会是传值这件事虽然基础但它其实是 MVC 架构里“控制器和视图之间契约”的核心。把这套契约定义清楚整个项目的可维护性能提升一个档次。最后再分享一个小技巧在 _ViewImports.cshtml 里统一引入 ViewModel 命名空间顺便给布局页设置一个默认标题变量每个视图顶部就只有一行 model 声明代码看起来干净得多。希望这篇整理能帮你少走一些弯路。