# 系统架构

**我是卡若。**

架构不是为了画图好看，是为了**省事**和**赚钱**。

我们的架构设计，核心围绕两个字：**分离**。
- 内容和代码分离。
- 前端和后端分离。
- 静态和动态分离。

## 1. 架构全景图

```mermaid
graph TD
    subgraph "内容生产 (Content)"
        Typora[本地写作] --> Git[Git 仓库]
        Git --> AutoSync[自动同步脚本]
    end

    subgraph "应用层 (Next.js)"
        AutoSync --> FileSys[文件系统 book/]
        FileSys --> Backend[后端 API]
        Backend --> Frontend[前端 UI]
    end

    subgraph "用户触达 (User)"
        Frontend --> Wechat[微信环境]
        Frontend --> Browser[手机浏览器]
    end
```

## 2. 核心设计理念

### 2.1 “内容即产品”
我们的核心资产不是代码，是 `book/` 目录下的文章。
- 代码丢了可以重写，文章丢了就完了。
- 所以，文章用 Markdown 存，Git 管，最安全。

### 2.2 前后端分离 (即使在 Next.js 里)
为了以后能扩展（比如招人开发，或者把后端换成 Java），我们在代码逻辑上做了强制隔离。
- 详见：**[前后端架构分离策略](file:///Users/karuo/Documents/个人/2、我写的书/《一场soul的创业实验》/开发文档/2、架构/前后端架构分离策略.md)**

### 2.3 极简部署
- 不要 Docker（除非必要）。
- 不要 K8s。
- 既然是 Node.js 项目，PM2 或者 Vercel 就够了。宝塔面板配个 Webhook 自动拉代码，是最适合个人开发者的方案。

## 3. 关键约束

1.  **本地优先**: 写作在本地，代码开发也在本地。
2.  **稀疏检出 (Sparse Checkout)**: 如果你只负责写作，就别拉取代码；如果你负责开发，就拉取全部。
3.  **单向流动**: 数据流向是 `Markdown -> API -> UI`。除非是评论或订单，否则 UI 不反向修改 Markdown。

## 4. 详细技术栈

详见：**[技术选型与全景图](file:///Users/karuo/Documents/个人/2、我写的书/《一场soul的创业实验》/开发文档/2、架构/技术选型与全景图.md)**

---
**总结：**
保持架构的简单性，就是保持业务的灵活性。能在文件里解决的，就别上数据库；能在 Next.js 里解决的，就别拆微服务。
