一个普通开发的框架自修之旅

回郑州发展的念头与技术栈思考

在南方工作的这几年，加班是常态，身体也开始发出警告。趁着还年轻，想把生活和工作拉回更可持续的节奏，于是动了回郑州发展的念头（境况可能无太大变化）。最近面试了几家公司，发现不少团队在问 Furion 或 ABP 的使用经验，当听到我并未深入使用时，话题往往就戛然而止。

这让我开始思考：ASP.NET Core WebAPI 本身已是一套成熟稳定的技术栈，配合微软生态，既能支撑单体应用，也能落地微服务架构。基于它封装一套贴合自己习惯的模块化脚手架，真的有那么难吗？

---

对比 Java 生态后的反思

其实对比 Java 生态会更清晰：Spring 框架就是 Java 世界的 ASP.NET Core WebAPI，是官方提供的基础能力集合。

Java 社区极少有人抛开 Spring 去用其他商业框架，企业招聘也不会把“是否会用某商用框架”作为核心筛选条件。大家普遍是在 Spring 基础上，根据业务封装自己的 starter 和脚手架。

但 .NET 生态的现状有些奇怪——明明官方技术链已足够完整（依赖注入、配置、日志、中间件等一应俱全），Aspire 又进一步补足了云原生编排能力，可部分团队仍倾向于将第三方商业框架视为唯一正确路径，仿佛不用 Furion 或 ABP 就无法正常开发。这种思路其实舍本逐末了。

---

小公司为什么也能做脚手架

小公司或团队完全有能力基于官方技术链，封装出轻量、可控的脚手架。
不必非用第三方框架不可，也不必重复造轮子。

自己动手的好处是清晰可控：

• 每个组件为什么存在
• 每个抽象为什么这样设计
• 后期调整起来也没有历史包袱

---

我决定做一个长期合集

带着这个念头，我决定开一个长期合集，用 ASP.NET Core WebAPI 配合 Aspire，逐步搭建一套支持插件化模块与微服务的基础设施。

过程中会记录一些 MEAI 等新技术的实践心得，也会参考 ABP 等成熟框架的设计理念。

这既是对过去几年工作的梳理，也是给自己留一份可维护、可扩展的代码参考——毕竟业务代码写多了，总需要一些能沉下心来的工程实践来找回手感。

---

关于这个合集

我并非技术大牛，只是一个在一线写了几年业务代码的普通开发者。这个规划或许偏长、也许烂尾，但我会量力而行，有节奏地推进。

每完成一个功能模块，就写一篇实践笔记填进来，作为过程文档，记录设计取舍与落地细节。

坦白说，所谓“脚手架”，多半是在现有工具链上做二次封装，把重复工作抽象成可复用的模式，本质上是一组工程化的实践集合。它不花哨，但能提升协作效率与项目可维护性。

如果你也在关注 如何低成本地搭建项目骨架，希望这个缓慢更新的过程能有些参考价值吧。