# 5.7 演示模式

:::tip 概述
演示模式（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 模式下无法演示"新增/编辑"交互——这是有意的取舍，
     数据安全优先于演示完整性。
```

## 使用建议

::: warning 环境隔离
+ 演示站：`app.demo: true` + 独立数据库 + 独立 jwt.secret
+ 本地开发：`app.demo: false`（否则改不动数据还以为是权限问题）
+ 生产：`app.demo: false`（发布检查清单项）
:::

## 排障

| 症状 | 判断 |
|------|------|
| 写操作全部报"演示环境，禁止操作!" | `app.demo: true`，改回 false 并重启 |
| 只有部分写操作被拦 | 不应出现——demo 按方法拦截无差别生效；若出现检查是否 429 限流或 403 权限的干扰 |
| 演示站登录后点什么都报 1015 | 正常现象，公开白名单仅覆盖登录链路 |