企业官网建设流程全解析

做 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，编译期就能检查字段是否存在。

四种方式最核心的区别在于“存哪”、“活多久”、“要不要转型”。我把这些维度整理成一张表，方便你对照：

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(); }

视图里读取：

<h1>@ViewData["PageTitle"]</h1>

这里有两个细节很多人会忽略。第一，ViewData 存进去的是 object，在 Razor 里直接输出时，Razor 会调用它的 ToString()，所以简单展示没问题；但如果要参与运算或判断，必须先转型。比如：

@{ decimal price = Convert.ToDecimal(ViewData["Price"] ?? 0); } <p>@price.ToString("0.00")</p>

第二，读取一个不存在的 key 不会抛异常，返回 null。这既是优点也是缺点：视图里 @ViewData["NotFound"] 不会让页面崩溃，但如果是因为拼错了 key，你会得到一个空白输出，排查起来全靠细心。

如果你往 ViewData 里放的是一个集合，视图里可以这样遍历：

<ul> @foreach (var item in ViewData["Items"] as List<string>) { <li>@item</li> } </ul>

注意那个as List<string>，如果类型不匹配，as 表达式返回 null，foreach 会直接抛 NullReferenceException。这种代码写多了，你就知道为什么我推荐强类型了。

2.2 ViewBag 的动态语法与隐藏关系

ViewBag 用起来确实清爽：

ViewBag.PageTitle = "商品管理"; ViewBag.NavActive = "product";

视图：

<h1>@ViewBag.PageTitle</h1>

但“清爽”是有代价的。ViewBag 的属性名在编译期没有任何检查，你写 ViewBag.PageTtle，IDE 不会报错，运行时也不会有编译错误，页面输出的就是空白。这种错误在大型项目里非常隐蔽，往往要等到测试阶段才发现。

再强调一次，ViewBag 和 ViewData 是同一份字典。你可以在控制器里写 ViewBag.Name = "张三"，然后视图里用 @ViewData["Name"] 取出来。反过来也一样。这个特性在新老代码交接时特别有用：老代码用 ViewData，新代码用 ViewBag，两者可以共存。我在一个后台管理系统改造项目里，就靠这个特性，把几十个视图从 ViewData 逐步迁移到 ViewBag，再最终迁移到 ViewModel，一行业务逻辑都没动。

2.3 局限与避坑：为什么不适合传复杂数据

想一个问题：如果你要把一个 Product 对象传给视图，用 ViewBag 怎么做？

ViewBag.Product = product;

视图里怎么用？

@{ var product = ViewBag.Product as Product; } <h1>@product.Name</h1>

如果不加as Product，直接写 @ViewBag.Product.Name，Razor 会尝试在运行期做动态绑定，速度会变慢，而且如果 ViewBag.Product 是 null，抛出的异常比强类型更难看懂。

再想第二个问题：同一个视图如果被多个控制器方法复用，A 方法塞了 ViewBag.Title，B 方法忘了塞，页面上就是一片空白，你收不到任何编译期提醒。在团队开发中，这几乎等于埋雷。

还有一个性能上的小细节：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 class="alert alert-success">@TempData["SuccessMessage"]</div> }

这里用 ! 判断而不是直接输出，因为第一次输出之后再次刷新，TempData 已经被移除，条件不成立，提示消失。这正是我们想要的效果。

3.2 最经典的用法：PRG 模式

PRG（Post-Redirect-Get）是 Web 开发中一个经典模式：表单 POST 提交 -> 服务器处理成功 -> 重定向到 GET 页面。这么做最大的好处是防止用户刷新浏览器时重复提交表单。

如果没有 PRG，用户提交表单后停留在 POST 结果的页面，一按 F5，浏览器会提示是否重新提交表单，用户点确认，同一份数据就写进了数据库两次。加入 RedirectToAction 之后，最后一个请求变成了 GET，刷新只是重新拉取页面，不会再次触发 POST。

TempData 在 PRG 模式里承担的角色，就是“把 POST 处理结果带到下一个 GET 页面”的中间人。POST 方法里写 TempData，GET 页面里读，数据穿过重定向这道墙，又不影响用户后续的刷新行为。

我见过不少新手把消息塞在 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 定义与传递的标准写法

先定义一个 ViewModel：

public class ProductDetailViewModel { public Product Product { get; set; } public List<Product> 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 <h1>@Model.Product.Name</h1> <p>@Model.Product.Description</p> @if (Model.CanEdit) { <a asp-action="Edit" asp-route-id="@Model.Product.Id">编辑</a> } <h2>相关商品</h2> <ul> @foreach (var item in Model.RelatedProducts) { <li>@item.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.cs

5.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.cshtml：

@model List<Product> <h1>商品列表</h1> <form method="get" asp-action="Index"> <input type="text" name="keyword" value="@ViewBag.Keyword" placeholder="搜索商品" /> <button type="submit">搜索</button> </form> <p>共 @ViewBag.Count 个商品</p> <ul> @foreach (var product in Model) { <li> <a asp-action="Detail" asp-route-id="@product.Id">@product.Name</a> </li> } </ul>

这里有个容易忽略的点：搜索框的 value 用的 @ViewBag.Keyword。其实查询字符串本身也能回显，但让 Controller 在服务器端统一赋值，回显更稳定可靠，尤其是在查询字符串被编码或做过分词处理之后。用 ViewBag 做搜索条件回显，是我觉得它少数不可替代的场景。

Detail.cshtml：

@model ProductDetailViewModel @if (TempData["SuccessMessage"] != null) { <div class="alert alert-success">@TempData["SuccessMessage"]</div> } <h1>@Model.Product.Name</h1> <p>@Model.Product.Description</p> @if (Model.CanEdit) { <a asp-action="Edit" asp-route-id="@Model.Product.Id">编辑</a> } <h2>相关商品</h2> <ul> @foreach (var related in Model.RelatedProducts) { <li>@related.Name</li> } </ul>

Detail 页面把两套传值方式完整体现出来：ViewModel 承载主体数据，TempData 承载跳转提示。

Edit.cshtml：

@model ProductEditViewModel <form asp-action="Edit" method="post"> <input type="hidden" asp-for="Id" /> <div> <label>商品名称</label> <input asp-for="Name" class="form-control" /> <span asp-validation-for="Name" class="text-danger"></span> </div> <div> <label>分类</label> <select asp-for="CategoryId" asp-items="@ViewBag.Categories"></select> </div> <div> <label>价格</label> <input asp-for="Price" class="form-control" /> <span asp-validation-for="Price" class="text-danger"></span> </div> <button type="submit">保存</button> </form>

这里涉及一个常见组合：下拉框的数据源用 ViewBag 传 SelectList，在 Razor 里直接塞给 asp-items 参数很方便。要注意的是，如果校验失败返回视图，ViewBag.Categories 必须重新赋值，否则返回页面时下拉框是空的。可以在 Edit 的 POST 方法里，在校验失败分支中重新查一次分类列表。

5.4 运行效果与自测清单

跑起来之后，我们可以验证几个关键行为，顺便把它当自测清单：

1. 在列表页输入“手机”点击搜索，地址栏出现?keyword=手机，搜索框里依然回显“手机”。
2. 点击某个商品进入详情，标题、描述、相关商品全部正常渲染，登录用户能看到“编辑”链接。
3. 点击编辑，表单正确回填。
4. 把名称清空点保存，页面停在编辑页，校验错误信息显示在对应字段下方，刚才输入的其他值没有丢失（这是强类型模型配合标签辅助器自动回显的效果，底层是 ModelState）。
5. 修改完成后保存，跳回详情页，顶部出现绿色提示“商品信息已更新”；再刷新一次，提示消失。

这五条自测就是一次完整的闭环。每条背后对应的传值机制分别是：ViewBag 回显、强类型 ViewModel 渲染、强类型回填、ModelState 回显、TempData 一次性提示。

6. 常见问题排查与避坑技巧

6.1 ViewBag 或 ViewData 在页面拿到 null

排查思路按优先级来：

• 先确认控制器真的进到了对应方法，而不是被某个过滤器拦下、或直接 404 了。可以临时加个日志输出确认。
• 再检查 key 是否拼写一致。ViewBag.ProductName 和 ViewBag.ProductName 看起来一样，但空格、缩写差异都会导致取不到值。虽然 ViewData 字典不区分大小写，但它区分字符本身是否完全相同。
• 然后确认没有发生重定向。如果控制器里 return RedirectToAction，ViewBag/ViewData 的数据在当前请求结束就没了，必须换成 TempData。
• 最后检查是不是加载了另一个同名视图，特别是区域项目里很容易踩到区域视图和普通视图冲突的问题。

调试这类问题最直接的手段，是在视图最上方把整个 ViewData 打出来：

@foreach (var item in ViewData) { <div>@item.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 是 null，ModelState 也判不完全。这种错误编译器不一定能发现，要重点检查控制器方法的参数类型与视图的 @model 类型是否一致。

另外，表单回传时字段的 name 属性必须和模型属性名匹配。使用 asp-for 标签辅助器会自动生成正确的 name，但如果你手写<input name="productName">，就和模型的 Name 属性匹配不上。所以能用标签辅助器就用标签辅助器，别手写表单。

6.4 集合传值的那些坑

视图里声明@model List<Product>，控制器返回时传的却是 IEnumerable ，这种情况下部分 API 能兼容，但如果你在视图里调用了依赖具体 List 类型的方法（比如 Model.Add），编译就会报错。建议视图声明时用 IReadOnlyList 或 IEnumerable ，控制器传什么都能接住。

还有一种更隐蔽的情况：ViewBag.Items 传了个集合，视图里用as List<Product>结果 null，往往是控制器里放的其实是别的类型，比如从匿名对象转换来的。这种问题查起来很费时间，我的建议是：集合类型的数据一律走 ViewModel，不要放 ViewBag。

6.5 ModelState 回显的数据来源之谜

表单校验失败返回视图时，你会发现输入框的值“自动回来了”，这是 MVC 的 ModelState 机制在起作用，并不是完全来自你返回的 model 对象。具体来说，如果 ModelState 里已经存在某个 key，Razor 渲染 asp-for 输入框时会优先使用 ModelState 里的值，而不是 Model 的属性值。

这个机制带来一个好处：校验失败时用户输入什么就回显什么，而不是回显数据库里的旧值。但它也有个对应的坑：如果你在控制器方法里，返回 View(model) 之前手动修改了 model.Name，会发现页面上显示的还是 ModelState 里的旧值，你的修改被“吞”了。遇到这种情况，要么在修改后调用 ModelState.Remove("Name")，要么把修改逻辑放在模型绑定之前。这个细节很多人不知道，我也是排查了很久才意识到。

我自己做项目时的体会是：传值这件事虽然基础，但它其实是 MVC 架构里“控制器和视图之间契约”的核心。把这套契约定义清楚，整个项目的可维护性能提升一个档次。最后再分享一个小技巧：在 _ViewImports.cshtml 里统一引入 ViewModel 命名空间，顺便给布局页设置一个默认标题变量，每个视图顶部就只有一行 @model 声明，代码看起来干净得多。希望这篇整理能帮你少走一些弯路。