5.7 演示模式
概述
演示模式（app.demo）为对外演示站设计：读操作照常、写操作一律拦截。一套配置让演示站可浏览、可登录、但不可篡改数据。
工作原理（middleware/demo.go）
text
app.demo = true 时（中间件链第 4 层）：
放行：
* GET / HEAD / OPTIONS（读操作，演示站可浏览）
* 公开白名单路径（/api/login、/api/captcha 等，保证演示站可登录）
拦截：
* 其余写操作（POST / PUT / PATCH / DELETE）
→ code=1015 "演示环境，禁止操作!"
app.demo = false（生产默认）：中间件直接放行，零开销配置
yaml
app:
demo: false # 演示模式：为 true 时写操作一律拒绝，读操作与登录类公开接口放行拦截行为细节
| 请求 | demo=true 行为 |
|---|---|
| GET /api/user/page | ✅ 放行（浏览） |
| POST /api/login | ✅ 放行（公开白名单，演示站可登录） |
| GET /api/captcha | ✅ 放行（公开白名单） |
| POST /api/user/add | ❌ 1015 演示环境，禁止操作! |
| PUT /api/user/update | ❌ 1015 |
| DELETE /api/user/delete/1 | ❌ 1015 |
| POST /api/upload/uploadFile | ❌ 1015 |
设计取舍
text
为什么按 HTTP 方法而非路径白名单拦截：
* 写操作方法（POST/PUT/PATCH/DELETE）与语义严格对应，无遗漏风险
* 免维护"哪些写接口可放行"的清单
* 登录/验证码是 GET 或公开白名单路径，天然不受影响
代价：demo 模式下无法演示"新增/编辑"交互——这是有意的取舍，
数据安全优先于演示完整性。使用建议
环境隔离
- 演示站：
app.demo: true+ 独立数据库 + 独立 jwt.secret - 本地开发：
app.demo: false（否则改不动数据还以为是权限问题） - 生产：
app.demo: false（发布检查清单项）
排障
| 症状 | 判断 |
|---|---|
| 写操作全部报"演示环境，禁止操作!" | app.demo: true，改回 false 并重启 |
| 只有部分写操作被拦 | 不应出现——demo 按方法拦截无差别生效；若出现检查是否 429 限流或 403 权限的干扰 |
| 演示站登录后点什么都报 1015 | 正常现象，公开白名单仅覆盖登录链路 |