# 后端架构与业务逻辑

**我是卡若。**

后端不仅仅是读写数据库，它是**业务逻辑的翻译官**。

我们要把“私域引流”、“内容分发”这些生意话术，翻译成代码逻辑。

## 1. 核心业务模块

### 1.1 内容服务 (Content Service)
这是最基础的。
-   **逻辑**:
    -   扫描 `book/` 目录，生成目录树 (Tree)。
    -   解析 Markdown，提取 Frontmatter (标题、日期、标签)。
    -   **缓存策略**: 既然是读文件，IO 慢。要在内存里做一个 LRU 缓存，读取一次后由内存直接返回，直到文件发生变更。

### 1.2 配置服务 (Config Service)
我的微信号、群二维码、价格，这些东西会变，不能写死在代码里。
-   **实现**:
    -   一个 `config/settings.json` 文件（或者未来的 MongoDB `settings` 表）。
    -   接口: `GET /api/config`。
    -   前端拿到配置，动态展示微信号。

### 1.3 引流服务 (Lead Service)
这是赚钱的关键。
-   **埋点逻辑**:
    -   记录 `UserView` (用户看了哪章)。
    -   记录 `UserClick` (用户点了“加微信”)。
    -   虽然不存库，但可以先打到日志文件里，或者调一个飞书的 Webhook，实时通知我“有人对这章感兴趣”。

## 2. 接口设计原则

-   **RESTful**: 资源导向。`GET /articles`, `GET /articles/:id`。
-   **统一响应体**:
    ```typescript
    interface ApiResponse<T> {
      code: number; // 0 成功, >0 错误
      data: T;
      msg: string;
    }
    ```

## 3. 目录结构 (后端专用)

```
app/api/
├── content/           # 内容相关
├── config/            # 全局配置
└── track/             # 埋点上报

lib/
├── content/
│   ├── parser.ts      # Markdown 解析器
│   └── cache.ts       # 内存缓存
├── config/
│   └── loader.ts      # 配置加载器
└── db/                # 数据库连接 (预留)
```

## 4. 扩展性预留

-   **鉴权中间件**: 现在是裸奔，未来加 `middleware.ts` 拦截 `/admin` 开头的请求。
-   **任务队列**: 未来如果生成文档太慢，就扔到 Redis 队列里异步处理。

---
**卡若说：**
后端代码要写得像瑞士军刀一样，功能明确，结实耐用。
