至于从入口开始看，框架与业务的边界在哪里？不过，

刚拿到项目时看着根目录下极简的 index.js内心其实是慌的：“就这几行代码？按理说，Koa 实例呢，中间件注册呢？路由挂载呢，老实说，业务代码怎么跑起来的？”

const ElpisCore = require;ElpisCore.start({
name这方面，'Elpis'。homePage: '/view/page1'
});

痛点直击： 习惯了在 app.js 里写满 app.userequire 路由文件、手动连数据库的传统 Koa 开发模式。突然面对这种“开箱即用”的黑盒启动方式，会产生强烈的失控感——框架到底帮我干了什么？万一出错我该去哪查，

深入 elpis-core/index.js 后发现，主要就做了三件事：创建 Koa 实例、确定项目根方法、启动加载器流程。

app.options = options;app.baseDir = process.cwd;其实，// 痛点：为什么不用 __dirname？因为打包/部署时工作目录可能变，cwd 永远指向输入命令的目录
app.businessPath = path.resolve;// 约定大于配置：业务代码必须放在 app 目录
app.env = env;

理解深度： process.cwd 配合 businessPath 建立了**框架与业务的物理边界**。框架代码在 elpis-core业务代码在 /app。Loader 的所有扫描起点都锚定在这里。这就是“约定比更好配置”的落地——**不想写配置文件？那就乖乖按目录结构放文件。**

Loader 机制：从“手动引入地狱”到“目录即配置”

主要痛点：“每新建一个 Controller/Service/Middleware，都要去入口文件手动 import 一次import 写多了不仅烦还容易漏、顺序还会错。”

Loader 的价值：把“文件程序结构”映射为“运行时对象树”。

以 ControllerLoader 为例：

1. 扫描:glob.sync);
2. 方法转属性:'app/controller/project.js' -> 'project'
3. 驼峰化:'api-params-verify.js' -> 'apiParamsVerify'
4. 实例化 & 挂载:app.controller.project = new ControllerModule;app.middlewares.apiParamsVerify = middlewareFn;

// 想象一下没有 Loader 的痛苦场景
// const projectController = require;// const userController = require;// app.use)...
//
// 有了 Loader：
// 新建文件 app/controller/order.js -> 自动拥有 app.controller.order
// 新建文件 app/middleware/jwt-verify.js -> 自动拥有 app.middlewares.jwtVerify
// 零侵入、零配置、零遗漏。

 设计启示： kebab-case -> camelCase)。是为了让 JS 调用符合语言习惯（app.middlewares.jwtVerify),再也不用写丑陋的app.middlewares))。

Controller & Service 实例化：为什么非要 new Class？

初学者疑惑 ： "直接导出对象 { getList {} } 不香吗？为什么非要 class + new + constructor 注入上下文?"

// BaseController 基类主要原因
class BaseController {
constructor { // 注意：这里通常接收 ctx 或 app
this.app = app;// 拿到全局应用对象
this.config = app.config;// 拿到配置
this.service = app.service;// >>>>>>>关键 : 拿到 Service 层能力 <<<<<< <<
        this.ctx = ctx ;
    }
    success  { this.ctx.body = { code :0 , data };}
    fail  { this.ctx.body = { code :-1 , msg };}
}

// ProjectController extends BaseController module.exports=class ProjectController extends BaseController{ async getList{ // this.service.project.getList -- 链路打通!按理说，const data=await this.service.project.getList;this.success;} }

• > 上下文绑定 : > 每个请求进来,Controller 是按需实例化。构造函数把 ctx,app,config,service > "塞"进实例,方法内直接 this.xxx > 调用,告别层层透参。
• >>>依赖倒置雏形 :>>>>> Controller 不关心 Service 是怎么实现的,只认 app.service.xxx > 接口。框架启动时完成注入，其实，>>>>>
• >>>框架 性 :>>>>>以后要加数据库。加缓存,加日志,只需在基类 constructor 加一行,全项目 Controller 自动拥有。>>>>