为什么值得把基础设施沉到框架里

开一个新站点的前两个小时，通常不是在写业务，而是在重复接一样的管道：数据库、缓存、日志、认证、接口文档、后台任务。每接一个项目就重来一遍，配置还会慢慢走样。

SmileX 的取舍是：这些一次性能力全部沉到框架，业务侧只保留一行。

SmileXApp.Run<Program>(args);

需要追加自己的服务与端点时，再换成显式的三段式写法。

单向分层

依赖方向是单向且不可逆的：

  • SmileX.Abstractions 只放契约，零依赖，接口与 DTO 都在这里。
  • SmileX.Core 放异常体系、扩展方法与 Redis 常用操作。
  • SmileX.Data 负责 SqlSugar 接入、实体基类与仓储基类。
  • SmileX.Api 把上面几层拼成可以直接跑的 Web 框架。

应用层只能引用 SmileX.Api，框架层永远不反向引用应用层。这条线守住之后，框架才能被多个站点复用而不被某一个站点绑架。

默认值优先，而不是配置优先

框架的默认配置刻意选了本机就能跑起来的组合：SQLite 落文件、缓存与后台任务共用一个 Redis 地址、日志同时写文件与控制台。空配置即可启动，是刻意的设计目标。

需要覆盖时，优先级从低到高依次是：内置默认值、appsettings、用户机密、环境变量、命令行、代码回调。越靠后越接近部署现场，也越容易被临时调整。

哪些东西没有开关

控制器、静态文件、全局异常处理、链路追踪、健康检查、Swagger、Hangfire，这些一律常驻，不提供关闭开关。少一个开关，就少一种只有某个环境才会出现的状态。

真正需要按环境区分的，反而是那些看起来最基础的东西：HTTPS 跳转交给业务站点自己决定，后台界面在生产环境强制要求配置账号密码。

小结

框架的价值不在于功能多，而在于把「每个项目都要做一遍」的事情变成「一次都不用做」。剩下的精力，留给真正的业务。