ASP.NET MVC 死了吗？别急着回答。我上周刚在一个老项目的维护文档里翻到它，代码是2013年写的，跑得好好的。另一头，新项目组在争论要不要把微服务拆得更细。没人提MVC，它就像办公室角落里那台还能用的打印机——没人夸，但谁都不敢关。

框架这东西，最怕的不是老，是没人懂。ASP.NET MVC 的请求生命周期，像一条笔直的流水线：URL路由把请求送到Controller，Controller 从 Model 抓数据，塞进 View，最后吐回HTML。每一步都明确，没有魔法。你写一个 `public ActionResult Index()`，它就真的返回一个视图。这种直白，在当年是革命性的——比 WebForms 那套 ViewState 和事件驱动干净太多。我记得第一次自己搭起MVC项目时，看着控制台里干净的日志，心里想的是：原来代码可以这么透明。

但透明有代价。你得自己处理表单验证、防伪造令牌、模型绑定错误。没有拖拽控件，没有自动回发。很多人骂它陡峭，其实不是陡峭，是它把选择权还给了你——就像手动挡汽车，会开的人觉得爽，嫌麻烦的人去开了自动挡，也就是后来的 Razor Pages 或 Blazor。

有个细节我一直记得。MVC 的 `HtmlHelper` 扩展方法里，`@Html.TextBoxFor(m => m.Name)` 能自动绑定模型属性，还带验证消息。这套强类型视图在当年是杀手级功能，编译期就能抓出拼写错误。你换个属性名，视图里直接红波浪线。这种安全感，是 JavaScript 自由拼字符串给不了的。后来前端框架火起来，很多人说 Razor 语法臃肿，但我看那些 React 里的 JSX，本质上不也是把 HTML 和 C# 换成 HTML 和 JavaScript 混在一起？谁也别笑谁。

真正让 ASP.NET MVC 显得过时的，不是技术本身，是生态的转移。现在新项目默认用 .NET Core 的 Minimal API，几行代码就能起个接口。你不需要 Controller 文件夹，不需要 Area，甚至不需要路由表——`app.MapGet("/hello", () => "Hi")`，完事。这种极简确实爽，但代价是它把架构决策全推给你了。MVC 至少告诉你：Controller 里别写SQL，ViewModel 别放业务逻辑。它用文件夹结构逼你守规矩。Minimal API 呢？你可以在 lambda 里干任何事，没人拦你。自由是自由，但三个月后回来看代码，你可能想抽自己。

我见过最讽刺的场景：一个团队宣称“抛弃MVC，拥抱微服务”，结果每个微服务内部又悄悄用起了 MVC 模式——Controller 改叫 Endpoint，View 改叫 Response Model，路由改叫 Path。换个名字而已，流水线还在。为什么？因为人脑处理复杂交互时，就是需要分层。Model 管数据，View 管展示，Controller 管协调。这就像厨房里切菜、炒菜、装盘分开，效率才高。你非要说“我不用切菜板”，那你直接在灶台上切吗？

所以别问它死没死。问你自己：你写的代码，用户改个密码，你能在十分钟内定位到是哪个方法处理了表单提交吗？能的话，你用什么框架都行。不能的话，ASP.NET MVC 那套约束反而能救你。它不酷，不新，但像一个老教练——不会给你花哨动作，只会盯着你练基本步。而基本步，永远不过时。