关于 Minimal API，前几年已经被讲得太热了。演讲里最常见的套路，是现场敲几行 MapGet()，大家一看，哇，没 controller、没 attribute、没一堆样板代码，像是突然从仪式感厚重的 ASP.NET 世界里钻出一条轻便小路。
但热闹过去之后，真正值得聊的反而不是“它能少写多少”，而是它逼团队重新面对了一个本来就该回答的问题：我们过去那些架构层次，到底是必要设计，还是多年积累下来的工作习惯？
Bipin Joshi 这篇文章好就好在没有继续吹 Minimal API 多新、多酷，而是直接回到更成熟的视角：当样板代码退场，留下来的其实不是语法快感，而是裸露出来的设计判断。
Minimal API 真正打掉的，不只是 boilerplate，而是默认的遮羞布
在 Minimal API 出来之前，ASP.NET Core 做 HTTP 服务通常有一套很熟的动作：建 controller、挂 route attribute、构造函数注入服务、注册依赖、配 filter、建 DTO、把整条链路拼起来。这里面当然有很多合理部分，但时间久了，合理结构很容易慢慢变成条件反射。
于是一个很小的 endpoint，也要先穿过整套“看起来很正规”的外壳。文件多一点、层次厚一点、模板全一点，团队就更容易产生一种心理安全感：这项目看着像样，说明架构是成熟的。
Minimal API 最有杀伤力的地方，不是它提供了更短的写法，而是它突然把 endpoint 变得过于直接。比如：
var app = WebApplication.CreateBuilder(args).Build();
app.MapGet("/status", () => "OK");
app.Run();你会立刻发现，很多过去被框架和模板包起来的东西，现在不再自动替你撑场面了。没有那层样板之后，设计是不是清楚、边界是不是明确、依赖是不是合理，全都更直接地暴露出来。
样板代码少了之后，暴露出来的不只是代码本身，更是团队到底有没有想清楚为什么这样设计。
热潮退去以后，Minimal API 真正改写的是“复杂性默认合法”这件事
Bipin 文章里最值钱的判断，是他说 Minimal API 并没有消灭 controller，也没有取代分层架构。它真正改变的是默认起点。
以前很多团队的默认姿势是：先把复杂结构摆上，再在里面填业务。简单，反而需要刻意克制。现在情况反过来了。你可以先从一个很轻的 endpoint 开始，再一层层加中间件、抽服务、补组织结构。于是问题变成：这些复杂性到底有没有充分理由。
这个变化看起来像风格差异，实际上很深。因为一旦简单成了默认值，架构就不再是“先继承一整套模板再说”，而必须回答：
- 这个 endpoint 真需要 controller 吗？
- 这里的抽象是在解决真实摩擦，还是为了让代码更像某种标准范式？
- 这个服务体量，真的配得上那么厚的分层吗？
Minimal API 没有拿走架构，它只是把“架构必须自证合理”这件事重新摆回桌面。
少代码不等于好设计，Minimal API 也不是免思考通行证
这篇文章没有落入另一个常见坑，我挺喜欢。很多人第一次接触 Minimal API，容易走向另一个极端：既然可以少文件、少层次，那就把所有 endpoint 都挤进少数几个文件里，handler 越写越胖，业务逻辑一路蔓延进路由定义，依赖注入也开始四处散。
这种写法表面上“很轻”，本质上只是把复杂度压缩打包了，并没有真的消失。
所以 Minimal API 成熟之后，团队慢慢意识到一个很朴素的事实：minimal syntax（最小语法）不等于 minimal architecture（最小架构）。系统一旦长大，命名、组织、边界、职责拆分这些老问题还是会回来，而且一个都不会少。
AI 时代这个提醒尤其重要。因为现在生成一堆 endpoint 代码实在太容易了，模型很擅长迅速铺开 handler、binding、validation、service call，甚至还能顺手帮你拆几个 extension method。可如果没有清楚的边界意识，AI 最容易做的事，就是把原本零散的混乱更快地扩展成更大的混乱。
它会让代码先出现，但不会替你证明结构就是对的。
Minimal API 像是一种“架构去表演化”修正
Bipin 提到过去十年里大家太熟悉的那套景象：microservices 越拆越多，clean architecture 图越画越大，domain、application、infrastructure、shared kernel、base class、cross-cutting abstraction 一个不少。这里面当然有场景是合理的，但也确实有不少项目只是“照着成熟团队的样子摆成熟姿势”。
说难听点，就是架构 vanity（架构虚荣）。
小服务也想拥有企业级脚手架，prototype 也恨不得先配齐三层目录，内部工具还没上线就先讨论可扩展性和统一约束。最后团队花了很多精力维护一个“看起来专业”的结构，却不一定真的解决了当前问题。
Minimal API 这些年提供的，更像一场温和的纠偏。它不是革命，不是宣布 MVC 过时，也不是说分层都错了。它只是默默提醒大家：
- 小服务不一定要企业级脚手架
- 原型不需要提前把未来十年的扩展性都供起来
- 内部工具没必要先走一遍完整仪式
这类提醒，在今天反而更重要。因为 AI 会让“把一整套架子快速搭出来”变得更廉价，团队如果没有克制，很容易把并不需要的复杂性批量生产出来。
真正困难的不是加一层，而是忍住先别加
文章里有个词我觉得抓得很准，叫 restraint，也就是克制。
这其实是 Minimal API 留下来的最大礼物。不是更少代码，而是更强迫你练习“先别急着上复杂性”的能力。加一层 abstraction 往往让人有安全感，看上去像在为未来负责；先停一下，问一句“我现在到底在解决什么问题”，反而更难。
Minimal API 的好处，就是它把这个暂停动作变成默认姿势。你可以先把 endpoint 做出来，等真的出现重复、摩擦、协作边界、治理需求，再逐步抽服务、分模块、加约束。这个顺序的变化很关键：不是先假设复杂性会来，所以提前供奉复杂性；而是复杂性真的来了，再让它拿出身份证。
这也是我觉得它最适合当下的原因。AI 把实现速度拉得很高，团队更需要的是一种不会被速度裹挟的机制。Minimal API 提供的恰恰不是答案，而是一个更诚实的起点。
它最适合什么场景，也最怕什么场景
Bipin 对适用边界写得挺稳。Minimal API 在这些地方通常很顺手：微服务、网关、内部 API、快速原型、事件驱动入口、serverless 场景。因为这些系统往往职责集中，endpoint 本身就是很自然的设计单位，少一点样板，反而更清楚。
但它也确实不是什么都适合。大型领域模型、跨团队协作很重的系统、治理规范要求很强的环境、长期自然生长又缺架构看护的代码库，Minimal API 容易暴露出另一个问题：框架不再替你提供很多护栏了。如果团队本身没有稳定约束，代码很快就会从“简洁”滑向“随意”。
这也是为什么今天讨论 Minimal API，最没价值的问题已经不是“该不该用”，而是“在什么边界内用，用到什么程度停”。
对今天的 .NET 团队来说，真正要学的不是 MapGet，而是复杂性记账
把这篇文章放回今天来看，我觉得最值得带走的不是某种技术立场，而是一种更成熟的工程姿势：复杂性应该被当成成本，而不是默认美德。
Minimal API 的历史意义，正在于它把这笔账摊开了。controller 可以继续用，分层可以继续用，甚至某些项目照样值得上完整结构；但从现在开始，你最好知道自己为什么要这么做，而不是因为模板本来就长这样。
AI 已经把样板生成这件事做得很便宜了，这反而让“为什么需要这些样板”成为更重要的问题。模型可以在几分钟内给你吐出 controller、DTO、service、repository、mapping、validation 全家桶，但它不会替你判断这个服务到底值不值得背上这些维护成本。
所以 Minimal API 留下来的真正遗产，不是“更少文件”，而是一个更难回避的问题：当框架不再替你表演成熟，团队有没有能力自己做出成熟判断？
热潮过后，留下来的其实是更好的提问方式
如果要把 Bipin 这篇文章压成一句话，我会这么总结：Minimal API 最终没有改变架构本身，它改变的是我们看待架构的态度。
从前大家容易把样板、层次、目录和仪式感误认成严谨；现在这层幻觉被拿掉了。你仍然可以选择复杂结构，但复杂不再天然代表专业，简单也不再自动等于草率。真正值钱的是判断：什么时候该保持轻，什么时候该补结构，什么时候又是在用“未来也许需要”给今天的过度设计找借口。
这才是 Minimal API 热潮退去后真正留下来的东西。不是更少的代码，而是更少的想当然。
参考
- Minimal APIs After the Hype: What Remains When Boilerplate Is Gone? — Bipin Joshi
- Minimal APIs overview — Microsoft Learn