备注引用：抖音"哲玄前端"《大前端全栈实践》
最近在学习全栈开发的过程中，接触到了一个叫 Elpis-core 的 Node.js 框架。说实话，刚开始我以为又是一个轮子，但深入了解后发现这个框架的设计思路真的很有意思。
作为一个主要写前端的开发者，我对服务端框架的理解一直停留在"能跑就行"的层面。但 Elpis-core 让我第一次真正理解了什么叫"约定优于配置"，也让我开始思考一个好的框架应该是什么样子的。
第一印象：这个目录结构有点意思
刚拿到这个项目的时候，我被它的目录结构吸引了：
app/
├── controller/ # 处理请求的地方
├── service/ # 业务逻辑
├── middleware/ # 中间件
├── router/ # 路由
├── extend/ # 扩展功能
└── config/ # 配置文件
看起来很眼熟对吧？有点像 Egg.js 的感觉。但是当我开始写代码的时候，发现了一个很神奇的事情：我几乎不需要写任何配置文件。
比如我在 controller 目录下创建一个 user-profile.js 文件，框架会自动把它映射成 app.controller.userProfile。这种自动化的处理让我这个懒人非常满意 😄
让我印象深刻的几个设计
1. 启动过程很优雅
这个框架的启动过程设计得很有条理，不像我之前写的那些乱七八糟的代码：
// 启动就这么简单
module.exports = {
start(options = {}) {
const app = new Koa();
// 先加载环境配置
app.env = envLoader();
// 然后按顺序加载各种模块
middlewareLoader(app);
controllerLoader(app);
serviceLoader(app);
// ... 其他加载器
app.listen(port);
}
}
每个加载器都有自己的职责，而且加载顺序是经过深思熟虑的。这让我想起了我之前写的那些 require 满天飞的代码，真是惨不忍睹...
2. 文件加载器真的很聪明
最让我惊喜的是它的文件加载机制。我只需要按照约定创建文件，框架就会自动帮我处理好一切：
- 文件名自动转驼峰：
user-profile.js变成userProfile - 支持嵌套目录：
admin/user.js会变成app.controller.admin.user - 自动实例化：不用我手动
new来new去
这种设计让我想起了 Rails 的 "魔法"，虽然有时候会觉得太神奇了，但用起来确实很爽。
3. 环境管理很贴心
开发、测试、生产环境的切换也很简单：
// 就是这么直观
const env = {
isLocal: () => process.env._ENV === 'local',
isBeta: () => process.env._ENV === 'beta',
isProduction: () => process.env._ENV === 'prod'
}
不用再写一堆 if-else 来判断环境了。
实际用起来的感受
写 API 变得很简单
以前写接口的时候，我总是要考虑很多东西：路由怎么配置、参数怎么校验、错误怎么处理...
但用了这个框架后，写个接口变得很直观：
// controller 里就专心处理业务逻辑
class ProjectController extends BaseController {
async getList(ctx) {
const result = await this.service.project.getList();
this.success(ctx, result); // 统一的成功响应
}
}
BaseController 提供了统一的响应格式，我再也不用每个接口都写一遍 ctx.body = {...} 了。
中间件的使用体验不错
框架内置了一些常用的中间件：
- 参数校验（再也不用手写一堆 if 判断了）
- 签名验证（API 安全性有保障）
- 异常处理（出错了也不会让用户看到奇怪的报错）
而且如果需要自定义中间件，也很容易扩展。
extend 目录是个好设计
想要给框架加功能的时候，只需要在 extend 目录下加个文件就行了。比如我加了个日志功能，就可以在任何地方用 app.logger.info() 了。
这种扩展方式比直接改框架代码要优雅多了。
从技术角度分析一下
学习这个框架的过程中，我发现它用了不少经典的设计模式，虽然我以前只是在书上看过，但在这里看到了实际应用。
工厂模式的巧妙运用
框架的加载器其实就是一个工厂，它会根据文件路径动态创建实例：
// 大概是这个意思
const ControllerClass = require(filePath)(app);
controller[name] = new ControllerClass();
这样我就不用手动管理这些实例了，框架帮我都搞定了。
基类的设计很实用
// 所有 Controller 都继承这个基类
class BaseController {
success(ctx, data) { /* 统一的成功响应 */ }
fail(ctx, message) { /* 统一的错误响应 */ }
}
这种设计让我想起了面向对象课上学的继承，原来在实际项目中是这么用的。
配置管理用了策略模式
不同环境的配置文件会根据当前环境自动选择：
// 根据环境选择不同的配置
const configs = {
local: require('./config.local.js'),
beta: require('./config.beta.js'),
prod: require('./config.prod.js')
}
这比我以前写的一堆 if-else 要优雅多了。
用了一段时间后的感受
开发效率确实提高了
以前写个简单的 CRUD 接口，我可能需要花半天时间配置各种东西。现在基本上创建几个文件，写点业务逻辑就搞定了。
特别是那个自动加载机制，真的省了很多事。我再也不用在文件顶部写一堆 require 了。
代码变得更规范了
因为框架有明确的约定，我的代码结构变得很清晰：
- Controller 就专门处理请求
- Service 就专门写业务逻辑
- 配置就放在 config 目录
这样团队协作的时候，大家都知道去哪里找什么代码。
也有一些小问题
当然，这种"约定优于配置"的方式也有缺点。有时候我想做一些特殊的定制，就会发现不太容易。不过对于大部分场景来说，这些约定已经够用了。
我的一些思考
学习这个框架让我重新思考了几个问题：
约定真的很重要
以前我总觉得灵活性最重要，什么都要可配置。但现在发现，好的约定能让开发变得更简单。就像 Rails 说的那样，"约定优于配置"确实有道理。
自动化能解决很多问题
框架帮我自动处理了文件加载、实例创建、路由映射等等。这让我意识到，很多重复性的工作其实都可以通过工具来解决。
分层架构的价值
Controller-Service 的分层让代码逻辑更清晰。以前我经常把所有逻辑都写在一个文件里，现在知道了职责分离的重要性。
什么场景下会用到这个框架
根据我的使用经验，这个框架比较适合：
- 写 API 接口：特别是那种标准的 CRUD 操作
- 做 BFF 层：前后端分离项目的中间层
- 快速原型开发：验证想法的时候很好用
- 小型管理后台：企业内部系统什么的
如果是特别复杂的业务场景，可能还是需要更重型的框架。
总结一下
学习 Elpis-core 这段时间，最大的收获不是学会了怎么用这个框架，而是理解了一些设计思想：
约定真的比配置香。以前我总觉得什么都可配置才叫灵活，现在发现合理的约定能让开发效率提升很多。
自动化很重要。能让机器做的事情就不要让人做，这样既减少了出错的可能，也让开发者能专注于业务逻辑。
分层架构有必要。Controller、Service 的分离让代码逻辑更清晰，维护起来也更容易。
虽然这个框架相对来说比较轻量，但它的设计思想很值得学习。特别是对于我这种主要写前端的开发者来说，了解这些服务端的设计理念对全栈开发很有帮助。
如果你也在学习 Node.js 服务端开发，推荐可以看看这个项目的源码，应该会有不少收获。
参考资料：
- 抖音"哲玄前端"《大前端全栈实践》
标签： Node.js、Koa、框架设计、全栈开发
有什么问题欢迎在评论区讨论，我也还在学习中，大家一起进步 🤝
