# mm 开发场景决策指南

## 规则（Rules）

根据需求类型选择最合适的开发方式，避免过度设计。**所有开发操作前必须先调用 `get_run_path` 获取运行路径。**

## 方法（Methods）

### 步骤1：分析需求类型

| 需求类型 | 适合方式 | 依附关系 | 对应的 work |
|:---------|:---------|:---------|:------------|
| 新增独立功能模块（如CMS、商城） | 创建 App | 顶层模块 | `develop_mm_app` |
| 给已有 App 加功能（如微信支付） | 创建 Plugin | 必须属于某个 App | `develop_mm_plugin` |
| 页面中复用片段（如文章列表） | 创建 Pendant | 属于某个 App | `develop_mm_pendant` |
| 给前端换皮肤 | 开发 Template | 项目级 | `develop_mm_template` |
| 定时执行任务（如数据同步） | 创建 Task | 项目级 | `develop_mm_task` |
| 给客户端提供数据接口 | 在 Plugin 中创建 API 接口 | 必须属于某个 Plugin | `develop_mm_api` |
| 请求拦截/预处理/分发/后处理 | 配置 Event | App 级或 Plugin 级 | `develop_mm_api_event` |
| 复用工具函数 | 封装 Com | 项目级公共模块 | `script_mm_com` |

### 步骤2：Event 场景细化判断

Event 覆盖请求生命周期的 5 个阶段，根据需求选择对应阶段：

| 需求 | 选择 stage | 典型做法 |
|:-----|:----------|:---------|
| 权限校验、参数预处理、URL转换 | `before` | 在业务处理前拦截，校验后放行或拒绝 |
| 安装检测、环境验证、数据完整性 | `check` | 在参数校验阶段插入检查逻辑 |
| 核心业务分发、委托 API 处理 | `main` | 通过 `$.admin.api().run(ctx, db)` 分发 |
| 模板渲染前数据准备 | `render` | 注入模型数据到模板上下文 |
| 响应后处理、数据转换、URL签名 | `after` | 修改响应内容、添加签名等 |

### 步骤3：判断依据

- **新业务域** → 创建 App（如 CMS、商城、物联网）
- **已有 App 的扩展功能** → 创建 Plugin（如腾讯云接入、支付）
- **跨页面复用** → 创建 Pendant（如导航栏、文章列表块）
- **定时处理** → 创建 Task（如数据备份、URL 提交）
- **请求拦截/分发** → 创建 Event（before→check→main→render→after 五阶段）
- **提供数据接口** → 在已有 Plugin 中创建 API（API 不能独立存在）

## 技巧（Tips）

- 一个 App 可以有多个 Plugin，一个 Plugin 可以有多个 API
- 功能归属原则：功能属于哪个业务域就放在哪个 App 下
- 不确定时优先选择 Plugin（热插拔，影响范围小）
- API 接口不能独立存在，必须附属于某个 App 的 Plugin
- Event 分 App 级和 Plugin 级：全局拦截用 App 级，插件内部预处理用 Plugin 级
- Event + API 组合：Event 负责路由/分发，API 负责业务处理