更新 readme.md

调整部分名称

Docs/acknowledgment.md

@@ -0,0 +1,65 @@
+# 致谢与互引
+
+> *“这个项目之所以存在，是因为有一群更早的存在，以及一个更大的生态。”*
+
+---
+
+## 核心依赖
+
+frpc-console 站在以下项目的肩膀上：
+
+- **[FRP](https://github.com/fatedier/frp)** —— 这个项目存在的理由。一个稳定、高效的内网穿透工具，是 frpc-console 管理的对象。
+- **[SQLite](https://www.sqlite.org/)** —— 嵌入式数据库的典范。它让 frpc-console 不需要额外部署数据库服务，符合“降低维护成本”的总体目标。
+- **[Go](https://go.dev/)** —— 编译为单一二进制，跨平台，低内存占用。没有 Go，就没有 frpc-console 目前的部署体验。
+
+---
+
+## 框架与库
+
+- **[Gin](https://github.com/gin-gonic/gin)** —— 高性能 Go Web 框架，为 API Server 提供基础。
+- **[Vue 3](https://github.com/vuejs/vue)** —— 渐进式 JavaScript 框架，承载了 Web UI 的交互体验。
+
+---
+
+## 生态互引
+
+### FRP 生态互补工具
+
+- **[MoonProxy](https://github.com/MoonProxyHQ/moonproxy-desktop)** —— 基于 Tauri v2 + Vue 3 + Rust 构建的跨平台 FRP 桌面客户端（frpc GUI），面向 macOS 与 Windows，让内网穿透开箱即用。MIT 协议开源。
+
+### FRP 生态同类工具
+
+*暂无互引。如果您知道有同类项目愿意建立互引关系，欢迎通过 Issue 或 PR 联系我们。*
+
+---
+
+## 设计启发
+
+这个项目的许多设计决策，受到以下内容的影响：
+
+- **《The Art of Unix Programming》** —— “Do one thing and do it well.”
+- **SQLite 的设计哲学** —— 长期稳定比新功能更重要。
+- **OpenBSD 的开发理念** —— 默认安全，拒绝默认开放。
+- **Tailscale 的部署体验** —— 安装一次，忘记它。
+
+---
+
+## 致谢
+
+感谢所有在真实环境中运行 frpc-console 的用户。你们的每一次部署，都是对这套工程方法的验证。
+
+[lxh2875931338（XHLiang0）](https://git.whitetop.xyz/lxh2875931338) —— 这是项目的开发者，同时也是项目真正的第一个用户。
+
+---
+
+## 如何贡献
+
+如果你在使用 frpc-console 的过程中有新的发现、改进建议，或者想参与互引，欢迎：
+
+- 提交 [Issue](https://git.whitetop.xyz/lxh2875931338/frpc-console/issues)
+- 发起 Pull Request（请针对 `test` 分支）
+- 在相关社区分享你的部署经验
+
+---
+
+*frpc-console 的成长，离不开整个开源生态的滋养。感谢每一位为之贡献的人。*

Docs/architecture.md

@@ -0,0 +1,287 @@
+# 架构设计
+
+> *“代码定义了它如何工作，架构定义了它如何活着。”*
+
+---
+
+## 架构总览
+
+frpc-console 是一个**轻量级生命周期管理工具**，它的架构设计围绕着三个核心目标：
+
+1. **低资源占用** — 在边缘设备上也能运行
+2. **高可靠性** — 面板可挂，业务不能停
+3. **零依赖部署** — 单一二进制，开箱即用
+
+
+### 整体架构图
+
+```mermaid
+graph TB
+    subgraph User["用户侧"]
+        Browser["浏览器"]
+        CLI["命令行"]
+    end
+
+    subgraph Console["frpc-console"]
+        WebUI["Web UI<br/>(Vue 3 + 深色磨砂玻璃)"]
+        APIServer["API Server<br/>(Gin)"]
+        Lifecycle["生命周期管理器"]
+        ConfigMgr["配置管理器<br/>(TOML 解析/生成)"]
+        ProcessMgr["进程管理器<br/>(SetSid / PID 1 接管)"]
+        DB["SQLite<br/>(用户/隧道/配置)"]
+        Static["静态资源<br/>(内嵌)"]
+    end
+
+    subgraph FRP["被管理对象"]
+        FRPC["frpc 进程"]
+        TOML["frpc.toml"]
+    end
+
+    Browser --> WebUI
+    CLI --> APIServer
+    WebUI --> APIServer
+    APIServer --> DB
+    APIServer --> ConfigMgr
+    ConfigMgr --> TOML
+    APIServer --> Lifecycle
+    Lifecycle --> ProcessMgr
+    ProcessMgr --> FRPC
+    FRPC --> TOML
+    Static -.-> WebUI
+```
+
+> **说明：** `Static`（前端静态资源）在编译时通过 `embed` 直接打包进二进制，运行时无需额外加载。因此图中以虚线表示其与 WebUI 的关联，且不占用独立部署单元。
+
+---
+
+## 部署模型
+
+frpc-console 支持两种部署模型，架构核心逻辑完全一致，只是运行环境不同。
+
+### 二进制部署模型
+
+```
+┌──────────────────────────────────────────┐
+│           操作系统 (Linux/Windows)        │
+│                                          │
+│  ┌────────────────────────────────────┐  │
+│  │         frpc-console               │  │
+│  │  ┌──────────────────────────────┐ │  │
+│  │  │  Web UI  │  API Server       │ │  │
+│  │  ├──────────────────────────────┤ │  │
+│  │  │  生命周期管理 / 配置管理      │ │  │
+│  │  └──────────┬───────────────────┘ │  │
+│  └─────────────┼──────────────────────┘  │
+│                │ SetSid + 独立会话        │
+│                ▼                          │
+│  ┌────────────────────────────────────┐  │
+│  │         frpc 子进程                │  │
+│  │  (被 PID 1 接管，独立生命周期)     │  │
+│  └────────────────────────────────────┘  │
+│                                          │
+│  ┌────────────────────────────────────┐  │
+│  │   数据目录: /opt/frpc-console/data │  │
+│  │   ├── frpc-console.db              │  │
+│  │   ├── frpc.toml                    │  │
+│  │   ├── frpc (二进制)                │  │
+│  │   ├── frpc.pid                     │  │
+│  │   └── version.ini                  │  │
+│  └────────────────────────────────────┘  │
+└──────────────────────────────────────────┘
+```
+
+**关键机制：**
+
+- frpc-console 启动时，通过 `SetSid` 为 frpc 创建**独立会话**
+- frpc 进程完全脱离父进程的生命周期控制
+- 即使 console 崩溃或被 kill，frpc 会被 init（PID 1）接管，继续运行
+
+### Docker 部署模型
+
+```
+┌──────────────────────────────────────────┐
+│              Docker Host                  │
+│                                          │
+│  ┌────────────────────────────────────┐  │
+│  │   Container: frpc-console          │  │
+│  │  ┌──────────────────────────────┐ │  │
+│  │  │  Web UI  │  API Server       │ │  │
+│  │  ├──────────────────────────────┤ │  │
+│  │  │  生命周期管理 / 配置管理      │ │  │
+│  │  └──────────┬───────────────────┘ │  │
+│  │             │ 启动 frpc            │  │
+│  │             ▼                      │  │
+│  │  ┌──────────────────────────────┐ │  │
+│  │  │  frpc 子进程 (容器内)        │ │  │
+│  │  └──────────────────────────────┘ │  │
+│  └──────────────┬─────────────────────┘  │
+│                 │ Volume 挂载             │
+│                 ▼                          │
+│  ┌────────────────────────────────────┐  │
+│  │  数据卷: /opt/frpc-console/data   │  │
+│  │  ├── frpc-console.db              │  │
+│  │  ├── frpc.toml                    │  │
+│  │  ├── frpc.pid                     │  │
+│  │  └── version.ini                  │  │
+│  └────────────────────────────────────┘  │
+│                                          │
+│  重启策略: --restart=always               │
+└──────────────────────────────────────────┘
+```
+
+**关键机制：**
+
+- 容器配置 `--restart=always`，console 退出时 Docker 自动重启
+- 数据目录通过 Volume 挂载持久化
+- 容器重启后自动重新拉起 frpc
+
+---
+
+## 核心模块
+
+### 1. Web UI（前端）
+
+- **框架：** Vue 3
+- **风格：** 深色磨砂玻璃视觉
+- **设计原则：** 需要时清晰易用，不需要时不打扰
+- **构建产物：** 静态资源通过 Go embed 内嵌于二进制
+
+### 2. API Server
+
+- **框架：** Gin
+- **认证：** Session / JWT
+- **职责：** 提供 RESTful API，处理前端请求
+
+### 3. 生命周期管理器
+
+负责 frpc 进程的完整生命周期：
+
+| 操作 | 行为 |
+|---|---|
+| 启动 | 根据当前 frpc.toml 启动 frpc 进程 |
+| 停止 | 向 frpc 发送终止信号 |
+| 重启 | 停止 → 重新加载配置 → 启动 |
+| 状态检查 | 读取 PID 文件，验证进程是否存在 |
+| 热加载 | 修改配置后自动重启 frpc（无需手动操作） |
+
+### 4. 配置管理器
+
+- 解析和生成 TOML 格式的 frp 配置文件
+- 支持从现有 frpc.toml 导入
+- 修改配置后自动触发重启
+
+### 5. 进程管理器
+
+- 通过 `SetSid` 创建独立会话（Linux）
+- frpc 二进制内置在部署包中，无需额外下载
+- 记录 PID 到文件，用于状态检查和进程管理
+- Windows 版本使用相应的进程管理 API
+
+### 6. SQLite 数据库
+
+- **表结构：**
+  - `users` — 管理员账户
+  - `tunnels` — 隧道配置
+  - `configs` — 全局配置
+- **备份机制：** 部署脚本在降级前自动备份数据库文件
+- **位置：** `data/frpc-console.db`
+
+---
+
+## 关键交互流程
+
+### 启动流程
+
+```mermaid
+sequenceDiagram
+    participant User
+    participant Console
+    participant FRPC
+
+    User->>Console: 启动 frpc-console
+    Console->>Console: 读取 data/frpc.toml
+    alt 配置文件存在
+        Console->>FRPC: 启动 frpc (SetSid)
+        FRPC-->>Console: PID 写入 frpc.pid
+        Console-->>User: 服务就绪
+    else 配置文件不存在
+        Console-->>User: 等待 WebUI 导入配置
+        User->>Console: WebUI 导入 frpc.toml
+        Console->>FRPC: 启动 frpc
+    end
+```
+
+### 配置更新流程
+
+```mermaid
+sequenceDiagram
+    participant User
+    participant WebUI
+    participant API
+    participant ConfigMgr
+    participant FRPC
+
+    User->>WebUI: 修改隧道配置
+    WebUI->>API: PUT /api/tunnels/:id
+    API->>ConfigMgr: 更新配置
+    ConfigMgr->>ConfigMgr: 写入 data/frpc.toml
+    ConfigMgr-->>API: 配置已更新
+    API-->>WebUI: 200 OK
+    API->>FRPC: 重启 frpc (热加载)
+    FRPC-->>API: 启动成功
+```
+
+---
+
+## 资源边界
+
+### 运行时资源
+
+| 资源 | 典型值 | 说明 |
+|---|---|---|
+| CPU（idle） | ~0% | 无后台轮询 |
+| 内存（idle） | < 20MB | 无额外守护进程 |
+| 存储（二进制） | ~15MB | 静态编译，无依赖 |
+| 存储（数据） | < 1MB | SQLite + 配置文件 |
+
+> 真实设备实测数据见 [工程设计哲学 - 稳定性与可观测性](./engineering-philosophy.md#稳定性与可观测性)
+
+### 文件系统布局
+
+```
+/opt/frpc-console/                    # 默认部署目录
+├── data/                             # 数据目录（持久化）
+│   ├── frpc-console.db               # SQLite 数据库
+│   ├── frpc.toml                     # 当前 frpc 配置
+│   ├── frpc                          # FRP 二进制（内置）
+│   ├── frpc.pid                      # frpc 进程 PID
+│   ├── frpc.log                      # frpc 日志（可选）
+│   └── version.ini                   # 当前版本标识
+├── frpc-console                      # 主二进制（二进制部署）
+└── .old_backup_*                     # 旧版本备份（迁移时生成）
+```
+
+---
+
+## 架构演进
+
+当前架构不是一次性设计完成的，而是经历了以下阶段：
+
+1. **最初**：一个简单的 Web UI，通过命令行调用 frpc
+2. **发现问题**：SSH 断开后 frpc 也跟着退出 → 引入 SetSid
+3. **发现问题**：配置文件修改需要手动重启 → 引入热加载
+4. **发现问题**：ARMHF 设备跑不动 Docker → 引入二进制部署
+5. **发现问题**：边缘设备内存不足 → 优化运行时内存占用
+6. **发现问题**：更新时数据丢失 → 引入事务性部署脚本
+7. **持续演化中**：每次真实部署都可能带来新的架构调整
+
+---
+
+## 相关文档
+
+- [工程设计哲学](./engineering-philosophy.md) — 架构决策背后的设计原则
+- [设计决策记录](./design-decisions.md) — 每个“为什么”的详细记录
+- [边缘节点部署](./edge-node.md) — 在受限环境中的架构适配
+- [更新策略](./update-strategy.md) — 版本管理和升级机制
+- [部署指南](./INSTALL_DOCKER.md) — Docker 部署详细步骤
+- [二进制安装指南](./INSTALL_BINARY.md) — 二进制部署详细步骤

Docs/deployment-engine-design.md

@@ -0,0 +1,355 @@
+# 部署引擎设计
+
+> *部署不是执行命令。*  
+>
+> *部署是让一个未知环境变得可预测的过程。*
+>
+> *不理解环境的部署脚本，只能算是穿着风衣的命令。*
+
+---
+
+## 为什么需要部署引擎
+
+`deploy.sh` 不是安装脚本。它是部署引擎。
+
+安装脚本解决的是“怎么把文件放到正确的位置”。部署引擎解决的是“如何让一个未知环境进入可运行状态”。
+
+用户的机器从来都不是一致的。在实际部署中，可能遇到：
+
+- Docker 未安装
+- Docker 已安装但未启动
+- `daemon.json` 不存在
+- `daemon.json` 存在但为空
+- `daemon.json` 存在但格式非法
+- `registry-mirrors` 不存在
+- `registry-mirrors` 存在但全部不可用
+- `registry-mirrors` 存在但部分不可用
+- `jq` 未安装
+- Git 未安装
+- `frpc-console` 容器已存在
+- `frpc-console` 容器正在运行
+- 当前版本高于目标版本（降级）
+- 当前版本低于目标版本（升级）
+- LTS 与 Preview 通道混用
+
+因此：**部署不是执行命令。部署首先是环境诊断。**
+
+`deploy.sh` 的设计目标：
+
+1. **探测** —— 了解当前环境的状态
+2. **分析** —— 判断当前状态与目标状态之间的差距
+3. **规划** —— 生成最小必要变更的执行计划
+4. **确认** —— 让用户在执行前理解即将发生的变化
+5. **执行** —— 按照计划执行变更
+6. **验证** —— 确认变更生效且系统正常
+7. **清理** —— 移除临时产物，保持系统整洁
+
+---
+
+## 部署生命周期
+
+`deploy.sh` 的执行流程可以用以下状态流转图表示：
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│                     Environment Detection                      │
+│  OS / ARCH / Git / Curl / Wget / Docker / jq / Container       │
+└─────────────────────────────────────────────────────────────────┘
+                              │
+                              ▼
+┌─────────────────────────────────────────────────────────────────┐
+│                       State Analysis                           │
+│  镜像源状态 / 容器状态 / 版本状态 / 通道状态                    │
+└─────────────────────────────────────────────────────────────────┘
+                              │
+                              ▼
+┌─────────────────────────────────────────────────────────────────┐
+│                     Deployment Planning                        │
+│  生成变更清单：镜像源配置 / 工具安装 / 代码拉取 / 镜像构建     │
+└─────────────────────────────────────────────────────────────────┘
+                              │
+                              ▼
+┌─────────────────────────────────────────────────────────────────┐
+│                      User Confirmation                         │
+│  展示计划 → 等待确认 → 允许自定义配置                          │
+└─────────────────────────────────────────────────────────────────┘
+                              │
+                              ▼
+┌─────────────────────────────────────────────────────────────────┐
+│                         Execution                              │
+│  备份（降级时）→ 安装工具 → 拉取代码 → 配置镜像源 → 构建镜像   │
+│  → 清理旧容器 → 启动新容器 → 写入版本                          │
+└─────────────────────────────────────────────────────────────────┘
+                              │
+                              ▼
+┌─────────────────────────────────────────────────────────────────┐
+│                        Verification                            │
+│  镜像内容 / 容器状态 / 数据库可用性 / 版本一致性 / frpc PID     │
+└─────────────────────────────────────────────────────────────────┘
+                              │
+                              ▼
+┌─────────────────────────────────────────────────────────────────┐
+│                          Cleanup                               │
+│  清理旧镜像（保留最近 N 个）/ 清理临时文件                      │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+每个阶段都是独立的、可观测的、可失败的。任何一个阶段失败，系统都不会进入下一个阶段。
+
+---
+
+## 状态机设计
+
+`deploy.sh` 的核心不是“执行命令”，而是“状态转换”。
+
+以 Docker 镜像源检测为例：
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│                      初始状态                                    │
+│                daemon.json 存在性未知                            │
+└─────────────────────────────────────────────────────────────────┘
+                              │
+                              ▼
+┌─────────────────────────────────────────────────────────────────┐
+│                     daemon.json 不存在                          │
+│                         状态: no_file                           │
+│                         动作: 创建并写入                        │
+└─────────────────────────────────────────────────────────────────┘
+                              │
+                              ▼
+┌─────────────────────────────────────────────────────────────────┐
+│                  daemon.json 存在但格式非法                     │
+│                     状态: (检测到非法)                          │
+│                  动作: 备份 → 重建为 {}                         │
+└─────────────────────────────────────────────────────────────────┘
+                              │
+                              ▼
+┌─────────────────────────────────────────────────────────────────┐
+│               daemon.json 存在但无 registry-mirrors             │
+│                        状态: no_key                             │
+│                    动作: 写入可用镜像源                         │
+└─────────────────────────────────────────────────────────────────┘
+                              │
+                              ▼
+┌─────────────────────────────────────────────────────────────────┐
+│           registry-mirrors 存在且全部可用                       │
+│                   状态: has_valid_ordered                       │
+│                      动作: 跳过（无变更）                       │
+└─────────────────────────────────────────────────────────────────┘
+                              │
+                              ▼
+┌─────────────────────────────────────────────────────────────────┐
+│        registry-mirrors 存在但可用源排在不可用源之后            │
+│               状态: has_valid_reorder_needed                    │
+│                   动作: 重排（可用源前置）                      │
+└─────────────────────────────────────────────────────────────────┘
+                              │
+                              ▼
+┌─────────────────────────────────────────────────────────────────┐
+│              registry-mirrors 全部不可用                        │
+│                     状态: all_invalid                           │
+│              动作: 插入可用默认源（如存在）                     │
+└─────────────────────────────────────────────────────────────────┘
+                              │
+                              ▼
+┌─────────────────────────────────────────────────────────────────┐
+│                   默认镜像源全部不可用                          │
+│                 状态: default_unavailable                       │
+│              动作: 跳过（提示用户手动配置）                     │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+这个状态机的核心原则是：
+
+> **只在需要时修改。只在确认后执行。每次修改都是可逆的或有备份的。**
+
+所有状态都通过 `jq` 检测，所有修改都通过 `jq` 执行，所有原始配置都被备份。
+
+---
+
+## 幂等设计
+
+`deploy.sh` 是幂等的。多次执行的结果与一次执行相同。
+
+幂等性通过以下方式保证：
+
+### 1. 条件执行
+
+```bash
+# 只在容器存在时执行删除
+if docker ps -a | grep -q frpc-console; then
+    docker stop frpc-console
+    docker rm frpc-console
+fi
+```
+
+### 2. 状态检测前置
+
+```bash
+# 检测到用户配置全部可用时跳过修改
+if [ "$MIRROR_STATUS" = "has_valid_ordered" ]; then
+    WRITE_DAEMON=false
+    RESTART_DOCKER=false
+fi
+```
+
+### 3. 版本标记
+
+```bash
+# 每次构建使用唯一标签，不覆盖已有镜像
+IMAGE_TAG="${SEMVER}-lts-$(date +%Y%m%d)"
+```
+
+### 4. 增量修改而非覆盖
+
+镜像源配置采用“插入到最前面”而非“替换整个文件”的策略，保留用户原有配置。
+
+幂等性的意义在于：
+
+> **用户可以在任何时候重新运行 `deploy.sh`，而不必担心系统被破坏。**
+
+---
+
+## 事务完整性
+
+`deploy.sh` 采用类似数据库事务的设计原则：
+
+### 1. 变更前备份
+
+降级操作会触发数据库备份：
+
+```bash
+if [ "$TGT_SEMVER" \< "$CUR_SEMVER" ]; then
+    BACKUP_DIR="/opt/frpc-console-backups/${TIMESTAMP}_${CHANNEL}"
+    cp -r "$DEPLOY_DIR" "$BACKUP_DIR/frpc-console"
+fi
+```
+
+修改 `daemon.json` 前也会备份原文件：
+
+```bash
+cp "$DAEMON_JSON" "${DAEMON_JSON}.bak.$(date +%Y%m%d-%H%M%S)"
+```
+
+### 2. 变更后验证
+
+每次写入后都验证目标状态是否达成：
+
+- 写入镜像源后验证 JSON 有效性
+- 启动容器后验证容器状态
+- 写入版本后验证版本一致性
+- 启动后验证 frpc 进程是否存在
+
+### 3. 失败不继续
+
+任何关键步骤失败都会中断部署，不会进入下一阶段：
+
+```bash
+if [ $? -ne 0 ]; then
+    print_error "Docker 构建失败"
+    exit 1
+fi
+```
+
+---
+
+## 验证不是可选项
+
+大多数安装脚本在“安装完成”后即结束。`deploy.sh` 在“安装完成”后才开始验证。
+
+验证链：
+
+```
+构建完成
+    │
+    ▼
+验证镜像内容 ──→ 失败则退出
+    │
+    ▼
+启动容器
+    │
+    ▼
+验证容器状态 ──→ 失败则退出
+    │
+    ▼
+验证数据库可用性
+    │
+    ▼
+验证版本一致性 ──→ 警告但不退出
+    │
+    ▼
+验证 frpc 子进程 ──→ 警告但不退出
+```
+
+验证的目的是区分“部署完成”和“部署成功”。
+
+- **部署完成**：脚本执行完毕
+- **部署成功**：所有组件正常运行
+
+`deploy.sh` 提供明确的信号来区分这两种状态。
+
+---
+
+## 边界条件处理
+
+边界条件是部署脚本最大的不确定性来源。`deploy.sh` 在处理边界时遵循一个原则：**先假设它可能出问题，再设计应对方式。**
+
+以下边界条件已被识别并处理：
+
+### 已处理的边界
+
+- `daemon.json` 不存在 → 创建
+- `daemon.json` 为空 → 写入 `{}`
+- `daemon.json` 格式非法 → 备份并重建
+- `jq` 未安装 → 尝试安装，失败则降级处理
+- `registry-mirrors` 不存在 → 写入可用源
+- `registry-mirrors` 全部不可用 → 插入可用默认源
+- 用户镜像源全部失效 → 插入可用默认源到最前面
+- 默认镜像源全部不可用 → 跳过配置，提示用户手动处理
+- 旧版本文件在根目录 → 自动迁移到 `data/`
+- 容器已存在 → 停止并删除
+- 容器正在运行 → 优雅停止
+- 降级操作 → 自动备份，用户确认
+- LTS ↔ Preview 通道切换 → 备份数据库，用户确认
+- 旧镜像积累 → 保留最近 N 个，自动清理
+
+### 处理原则
+
+每新增一个边界条件，都是在扩展一个同一个决策表：当 `环境变量 X` 处于 `状态 Y` 时，引擎应该执行 `动作 Z`。这些条目不相互覆盖，而是叠加在同一个状态机之上，彼此通过前置条件互锁。
+
+这种方式的优点是：边界条件越多，系统对环境的适应能力越强，但状态机的核心结构不需要跟着膨胀。
+
+---
+
+## 与工程设计哲学的关系
+
+`deployment-engine-design.md` 与 `engineering-philosophy.md` 的关系是：
+
+| 文档 | 回答的问题 |
+|:---|:---|
+| `engineering-philosophy.md` | 为什么这样设计？ |
+| `deployment-engine-design.md` | 这些设计如何落地？ |
+| `deploy.sh` | 落地后的最终产物 |
+
+三者形成一条完整的链路：
+
+```
+哲学 → 架构 → 部署引擎 → 代码
+```
+
+哲学文档定义“为什么”，部署引擎文档定义“如何实现”，`deploy.sh` 是“实现的最终形态”。
+
+---
+
+## 结语
+
+> `deploy.sh` 不是安装脚本。
+>
+> 它是 `frpc-console` 的部署引擎。
+>
+> 它负责：环境探测、状态分析、部署规划、用户确认、执行动作、结果验证、环境清理。
+>
+> 它的设计目标是：**在尽量不打扰用户已有环境的前提下，把部署成功率提高到接近 100%。**
+
+这份文档记录了它为什么长成这样。

Docs/design-decisions.md

@@ -0,0 +1,168 @@
+# 设计决策
+
+> *“这不是 API 文档，这是设计记录。它回答的不是‘怎么用’，而是‘为什么会变成这样’。”*
+
+---
+
+## 关于这份文档
+
+frpc-console 的许多设计，如果只看最终结果，可能会让人觉得“奇怪”或“不按常理出牌”。
+
+这份文档记录的就是这些“奇怪”背后的原因。
+
+每一个决策，都来自真实部署中遇到的问题——而不是预先的设计。
+
+---
+
+## 为什么叫 Console，而不是 Manager？
+
+这个命名不是随意选的。
+
+| | Manager | Console |
+|---|---|---|
+| 暗示 | 管理权、控制中心 | 入口、操作界面 |
+| 角色 | 大脑 | 工具 |
+| 依赖关系 | 业务依赖 Manager | Console 依赖业务 |
+
+**结论：**
+
+frpc-console 不接管 FRP，不成为 FRP 的依赖。它只是一个入口，让你在需要的时候操作 FRP。
+
+用完之后，关闭浏览器，FRP 还在跑。
+
+这就是 Console 和 Manager 的区别。
+
+---
+
+## 为什么没有 CI/CD？
+
+这个项目没有复杂的 CI/CD 发布流程。不是做不到，而是选择不做。
+
+**原因：**
+
+- CI/CD 在云端跑，部署在真实环境跑。两者之间隔着一个“信任”的黑洞。
+- 如果发布流程和用户安装流程是两套不同的路径，维护者永远无法保证用户侧的真实体验。
+- 每一次部署，都应该在真实环境中被验证。
+
+**所以：**
+
+部署脚本就是发布流水线。开发过程中使用的更新链路，就是最终用户使用的更新链路。
+
+没有特权通道，没有隐藏开关。你用的，就是我用的。
+
+---
+
+## 为什么没有 Patch 版本？
+
+版本号格式：`2.5-LTS-260804-203825`
+
+详见：[更新策略](./update-strategy.md)
+
+---
+
+## 为什么支持 ARMHF？
+
+详见：[边缘节点部署](./edge-node.md)
+
+---
+
+## 为什么采用 Preview / LTS 双线版本？
+
+详见：[更新策略](./update-strategy.md)
+
+---
+
+## 为什么“存储换内存”？
+
+在边缘设备上，存储和内存的成本结构完全颠倒：
+
+| | 服务器 | 边缘设备 |
+|---|---|---|
+| 存储 | 昂贵（NVMe SSD） | 便宜（SD 卡 / eMMC） |
+| 内存 | 便宜（可扩展） | 昂贵（不可扩展，BGA 焊接） |
+
+**结论：**
+
+镜像大几十 MB，可以接受。内存多占 10MB，不能接受。
+
+牺牲存储空间，换来 50MB 以内的内存占用——这笔账在边缘设备上怎么算都不亏。
+
+---
+
+## 为什么用 SQLite，不用 PostgreSQL / MySQL？
+
+- 边缘设备跑不动 PostgreSQL
+- 不需要网络连接
+- 单文件备份，复制即迁移
+- 零配置，零维护
+
+符合“降低维护成本”的总体目标。
+
+---
+
+## 为什么使用 Gin 和 Vue，而不是更轻的框架？
+
+这是一个有意识的选择。
+
+frpc-console 的 Web 部分需要提供完整的图形化操作界面，不是一个简单的 API 服务。使用成熟的框架，换取开发效率和稳定性。
+
+**但要注意：**
+
+框架的选择不影响运行时资源占用。前端资源在首次加载后缓存，后端 Gin 在 idle 状态下几乎没有额外开销。
+
+---
+
+## 为什么默认不写日志？
+
+边缘设备存储有限（SD 卡 / eMMC）。
+
+默认不写日志，避免存储被写满导致设备不可用。
+
+用户需要时，可以显式开启日志功能。
+
+---
+
+## 为什么 openSUSE 在部署脚本中排第一？
+
+详见：[工程设计哲学](./engineering-philosophy.md) 中的“用户不是测试员”和“Real World First”原则。
+
+---
+
+## 为什么 Docker 和 Binary 都支持？
+
+因为使用场景不同：
+
+| 场景 | 推荐方式 |
+|---|---|
+| 现代服务器（有 Docker） | Docker |
+| 边缘设备（无 Docker） | Binary |
+| 开发者测试 | Docker |
+| 开发测试（无 Docker）| Binary |
+| 生产环境（有 Docker） | Docker |
+| 生产环境（无 Docker） | Binary |
+
+**核心原则：** 无论运行在哪里，体验应该保持一致。
+
+---
+
+## 为什么叫“阴阳模式”？
+
+详见：[工程设计哲学](./engineering-philosophy.md) 中的“阴阳模式”章节。
+
+---
+
+## 这些决策的共同点
+
+所有设计决策，都指向同一个问题：
+
+**一个长期运行的基础设施工具，应该是什么样？**
+
+答案不是“功能最多”，不是“界面最美”，而是：
+
+**降低长期维护的成本。**
+
+每一个“为什么”的答案，最终都落在这句话上。
+
+---
+
+*这份文档会持续更新。每一次新的设计决策，都会被记录在这里。*

Docs/edge-node.md

@@ -0,0 +1,154 @@
+# 边缘节点部署
+
+> *“真正需要管理工具的，往往不是机房里那台 64 核 256GB 的服务器，而是弱电箱里那块连散热片都没有的 ARM 开发板。”*
+
+---
+
+## 真实场景
+
+frpc-console 对边缘节点的支持，不是来自“市场调研”。
+
+它来自以下设备：
+
+- **全志 H3**（256MB / 512MB 内存），运行社区的精简版 ARMbian 或官方剪枝版 Debian，放在弱电箱里跑 frp 穿透
+- **RK3506**（128MB / 256MB 版本共存），没有 Docker，甚至没有 systemd
+- 老旧 ARM 开发板（ARMv7l / ARM-HF），原本可能是一块电视盒子，刷上 ARMbian 之后被重新利用
+
+这些设备的共同特征：
+
+- 存储介质：SD 卡 / eMMC（便宜，容量大，但读写速度不敏感）
+- 内存：128MB ~ 512MB（**没有任何拓展条件**）
+- 系统环境：极简化，不常用的工具基本都被剪枝，极端情况下很可能只有 Kernel + BusyBox + init
+- 网络环境：长期在线，但带宽有限
+- 物理位置：没有理由长期触及（弱电箱、吊顶、室外机柜）
+
+它们承担的工作却并不边缘：
+
+- 内网穿透
+- 远程维护通道
+- IoT 设备接入
+- 边缘计算节点
+
+---
+
+## 边缘环境特征
+
+### 存储 vs 内存：成本结构的倒挂
+
+在边缘设备上，存储和内存的成本结构与服务器完全不同：
+
+| | 服务器 | 边缘设备 |
+|---|---|---|
+| 存储 | 昂贵（NVMe SSD） | 便宜（SD 卡 / eMMC） |
+| 内存 | 便宜（可扩展） | 昂贵（不可扩展，BGA 焊接） |
+
+这意味着：
+
+**镜像大几十 MB，可以接受。内存多占 10MB，不能接受。**
+
+所以 frpc-console 的 Docker 镜像虽然包含了完整的构建环境和依赖，但它不会在运行时消耗额外内存。镜像大小和运行时内存占用，在边缘场景下是两个独立且优先级完全不同的指标。
+
+### 缺失的依赖
+
+边缘设备可能缺失以下内容：
+
+- **Docker**：很多 ARMHF 设备跑不动 Docker，或者根本没有 Docker 的预编译包
+- **systemd**：精简系统中可能只有 init 或 busybox-init
+- **glibc**：某些环境只提供 uClibc 或 musl
+- **包管理器**：内存小到一定程度的时候，它的存在堪称奢望
+
+因此，**二进制部署是边缘节点的唯一可行方案**。
+
+---
+
+## frpc-console 对边缘节点的适配
+
+### 1. 二进制静态编译
+
+frpc-console 采用 Go 编写，编译时使用 `CGO_ENABLED=0`：
+
+- 不依赖 glibc
+- 单一二进制文件
+- 可运行于 musl 环境（Alpine、BusyBox）
+- 不需要任何运行时依赖
+
+### 2. 多架构支持
+
+| 架构 | 说明 |
+|---|---|
+| x86_64 / AMD64 | 标准服务器 |
+| ARM64 / Aarch64 | 现代 ARM 设备（树莓派 3/4/5） |
+| ARMHF / ARMv7l | 老旧 ARM 设备（全志 H3、RK3506） |
+
+### 3. 无 systemd 运行方式
+
+在只有 init + BusyBox 的环境中：
+
+```bash
+# 直接运行
+./frpc-console &
+
+# 或通过 init 启动（写入 /etc/init.d/）
+```
+
+frpc-console 自身会通过 `Setsid` 为 frpc 创建独立会话，确保 frpc 在 console 退出后仍被 PID 1 接管。
+
+### 4. 数据目录设计
+
+```
+/opt/frpc-console/data/
+├── frpc-console.db    # SQLite 数据库
+├── frpc.toml          # FRP 配置文件
+├── frpc               # FRP 二进制（内置，无需额外下载）
+├── frpc.pid           # frpc 进程 PID
+├── frpc.log           # frpc 日志（可选）
+└── version.ini        # 当前版本标识
+```
+
+所有数据在同一个目录下，备份只需复制整个文件夹。
+
+### 5. 无日志默认策略
+
+边缘设备存储有限，所以：
+
+- 默认不写入日志文件
+- 日志仅在用户明确开启时写入
+- 避免 SD 卡被日志写满导致设备不可用
+
+---
+
+## 部署注意事项
+
+### 推荐的最小硬件规格
+
+| 场景 | CPU | 内存 | 存储 |
+|---|---|---|---|
+| 最小运行 | ARMv7 / ARM-HF | 128MB | 50MB（二进制 + 数据库） |
+| 推荐运行 | ARMv7 / ARM64 | 256MB | 100MB |
+| 舒适运行 | ARM64 / x86_64 | 512MB | 200MB |
+
+### 不建议部署的场景
+
+- **内存低于 64MB**：很极限，需要系统本身有极强的剪枝水准，以保证基础内存消耗不高于20M，但这并不现实
+- **存储低于 20MB**：没有足够的空间存放二进制和数据
+- **内核版本过低**（< 3.x）：某些系统调用可能不支持
+- **刷了OpenWRT的软/硬路由**：这种建议去下opkg的源包，而不是看向我们这个项目。
+
+### 网络要求
+
+- 边缘节点的网络出口带宽一般有限，首次访问 WebUI 时加载的静态资源（约 1-2MB）可能需要稍长时间
+- 后续操作仅传输 JSON 数据，流量极小
+
+---
+
+## 为什么这件事值得单独记录？
+
+因为主流开源项目在讨论 ARM 支持时，讨论的是“树莓派 4B（4GB 版本）”。
+
+而真正部署在边缘的设备，可能只有 256MB 内存，甚至连 Docker 都没有。
+
+frpc-console 对 ARMHF 的支持，不是“支持的架构列表里多了一项”，而是：
+
+**这个工具可以跑到那些真正藏在弱电箱里、承担网络基础设施工作的小板子上。**
+
+这才是边缘节点部署的意义。

Docs/engineering-philosophy.md

@@ -0,0 +1,305 @@
+# 工程设计哲学
+
+> *“Every line of code is a decision. Every document is an explanation of that decision.”*
+>
+> *（每一行代码都是一次设计决策，而每一份文档，都是对这次决策的解释。）*
+
+> *“Infrastructure software should disappear after deployment.”*
+>
+> *（基础设施软件，在部署完成以后，就应该消失。）*
+
+很多工具追求功能。
+
+很多工具追求界面。
+
+很多工具追求自动化。
+
+**但frpc-console 从来没有试图成为功能最多的 FRP 管理工具。**
+
+**它真正想解决的问题，是让一套 FRP 基础设施，在部署完成之后，能够稳定运行很多年，而几乎不需要再次打扰使用者。**
+
+如果一个工具每天提醒你更新，每天提醒你配置，每天提醒你维护——那么它已经失败了。
+
+部署，只发生一次。
+
+运行，却持续很多年。
+
+所以整个 frpc-console 都围绕这一件事情设计：
+
+**安装。配置。运行。然后——忘记它。**
+
+---
+
+## 为什么会有这个项目？
+
+最初，这只是一个给自己 Homelab 用的小工具。
+
+我需要一套简单、可靠的方式管理本地运行的 frpc。
+
+后来，在不断使用、不断重构的过程中，我意识到：
+
+真正的问题，从来不是"有没有一个管理页面"。
+
+而是：
+
+**如果 FRP 是一项长期运行的基础设施，它应该长什么样？**
+
+于是，这个项目开始慢慢偏离最初的方向。
+
+它不再只是一个 Web 面板，而是开始关注：
+
+- 生命周期管理
+- 长期维护
+- 多种部署方式
+- 极简运行环境
+- 用户真实的使用场景
+
+直到今天。
+
+---
+
+## 核心问题
+
+**一个长期运行的基础设施工具，应该是什么样？**
+
+这个问题的答案，驱动了 frpc-console 的所有设计。
+
+它不是一个功能列表，而是一套判断标准：
+
+- 功能应该增加，还是减少？
+- 部署应该复杂，还是简单？
+- 更新应该频繁，还是稳定？
+- 工具应该显眼，还是隐身？
+
+每个问题的答案，都指向同一个方向：
+
+**降低长期维护的成本。**
+
+---
+
+## 设计目标
+
+frpc-console 希望成为这样一种工具：
+
+**安装。配置。运行。然后，忘记它。**
+
+真正优秀的基础设施，不应该每天提醒用户自己的存在。
+
+它应该像交换机、路由器、UPS 一样——平时不会想到它，但需要的时候，它一直在那里。
+
+---
+
+## 设计哲学
+
+### 工具应该降低复杂度，而不是增加复杂度
+
+GUI 的意义，并不是隐藏配置文件，而是**降低维护成本**。
+
+如果一个图形界面最终比命令行更复杂，那么它已经偏离了存在的意义。
+
+### 每增加一个功能，都意味着新的维护成本
+
+功能不是越多越好。
+
+一个功能只有在真正改善体验时才值得存在。否则，宁可不做。
+
+这也是为什么：有些别人认为"理所当然"的功能，这里没有。不是不会，而是不值得。
+
+### 用户不是测试员
+
+这个项目的大多数设计，都来自于真实使用。
+
+开发者，也是第一个用户。
+
+如果一个设计连我自己都不愿意每天面对，那么它不会进入正式版本。
+
+### Docker 不是目标
+
+Docker 很重要，Binary 同样重要。
+
+真正重要的是：**无论运行在哪里，体验应该保持一致。**
+
+Docker、x86、ARM64、ARMHF，甚至极简 Linux——都应该拥有同样的管理体验。
+
+### Real World First
+
+这个项目的很多设计，都来自于真实部署，而不是 Demo。
+
+例如：
+
+- Docker 更新顺序
+- Git 拉取时机
+- 编译流程
+- 边缘部署
+- 二进制运行
+- BusyBox 环境
+
+很多看起来"奇怪"的实现，其实都来自于**踩坑**。
+
+不是设计出来的，而是试出来的。
+
+### 存储换内存，在嵌入式平台上不是交易，是生存策略
+
+镜像可以大几十 MB，但内存必须省。
+
+因为存储卡便宜，内存颗粒贵。
+
+对于 RK3506（128/256MB 版本共存）或全志 H3（256/512MB 并存）这类平台——
+
+牺牲一点存储空间（镜像大了几十 MB），换来 50MB 以内的内存占用，这笔账怎么算都不亏。
+
+---
+
+## 稳定性与可观测性
+
+"安装、配置、运行，然后忘记它"。
+
+但忘记，不等于失控。
+
+frpc-console 在设计上始终保持一个原则：
+
+**工具自身的开销，不应该成为需要被关注的对象。**
+
+所以：
+
+- 主进程在 idle 状态下 CPU 占用接近 0%
+- 内存占用控制在 20MB 以内
+- 没有额外的后台守护进程
+- 没有定期轮询的健康检查
+- 不会主动写入日志文件，除非你明确开启
+
+在真实设备上，frpc 和 frpc-console 同时运行时，两者加起来不到 30MB。
+
+这意味着，它不会成为你需要"照顾"的对象。
+
+---
+
+## 关键设计决策
+
+### 阴阳模式：面板可以挂，隧道不能停
+
+这是 frpc-console 与同类项目最核心的区别。
+
+**大多数管理工具走的是"阳阴模式"：**
+面板是大脑，业务是肢体。大脑一旦停止工作，肢体也就瘫痪了。
+
+**frpc-console 走的是"阴阳模式"：**
+业务是根基，面板是工具。
+
+- **阴**：看不见的业务流（frpc 进程、TOML 配置文件）
+- **阳**：看得见的管理面板（Web 界面、API 服务）
+
+二进制部署时，frpc-console 通过 `Setsid` 为 frpc 创建独立会话，使其完全脱离父进程的生命周期控制。
+
+即使 console 退出，frpc 也会被 init 进程（PID 1）接管，继续稳定运行。
+
+Docker 部署时，容器使用 `--restart=always`，console 退出时 Docker 自动重启并重新拉起 frpc。
+
+两种部署方式的本质一致：
+
+**面板是"阳"，服务于"阴"；"阴"不依赖"阳"而存在。**
+
+> **管理面板可以丢，业务功能打死不能停。**
+
+### 为什么叫 Console，而不是 Manager？
+
+这个命名不是随意选的。
+
+- **Manager** 暗示"管理权"，暗示它是一个控制中心，是大脑。
+- **Console** 暗示"入口"，暗示它是一个操作界面，是工具。
+
+这个区别，直接体现了项目的设计立场：
+
+**frpc-console 不接管 FRP，不成为 FRP 的依赖。它只是一个入口，让你在需要的时候，通过它来操作 FRP。**
+
+用完之后，关闭浏览器，FRP 还在跑。
+
+这就是 Console 和 Manager 的区别。
+
+### 为什么没有 CI/CD？
+
+这个项目没有复杂的 CI/CD 发布流程。
+
+不是做不到，而是选择不做。
+
+因为：
+
+- CI/CD 在云端跑，部署在真实环境跑。两者之间隔着一个"信任"的黑洞。
+- 如果发布流程和用户安装流程是两套不同的路径，维护者永远无法保证用户侧的真实体验。
+- 每一次部署，都应该在真实环境中被验证。
+
+所以，frpc-console 的部署脚本本身就是发布流水线：
+
+- 拉取代码 → 构建镜像 → 启动容器 → 写入版本 → 检查进程
+- 支持 `--dry-run` 预览、`--check` 环境检测
+- 降级前自动备份数据库
+- 保留最近 3 个镜像，便于回滚
+
+开发过程中使用的更新链路，就是最终用户使用的更新链路。
+
+没有特权通道，没有隐藏开关。
+
+你用的，就是我用的。
+
+因此，每一次更新，实际上都在验证整个部署流程。
+
+### 为什么支持 ARMHF？
+
+因为很多时候，真正需要这种工具的，并不是性能很强的服务器。
+
+而是一块全志 H3、RK3506，或者老旧 ARM 开发板——放在弱电箱里的边缘节点。
+
+它们可能没有 Docker，没有 systemd，甚至只有：
+
+- Kernel
+- BusyBox
+- init
+
+但它们依然承担着网络基础设施的工作。
+
+对于这些设备来说，图形化管理反而比高性能服务器更重要。
+
+### 为什么采用 Preview / LTS 双线版本？
+
+- **Preview**：用于验证新的设计与实现（test 分支）
+- **LTS**：保持稳定，并持续滚动维护（main 分支）
+
+某些修复不会等待下一个大版本。
+
+因为对于基础设施而言，**稳定比版本号更重要**。
+
+---
+
+## 这个项目不是什么
+
+这个项目：
+
+- 不追求成为功能最多的 FRP 管理平台
+- 不追求重新定义 FRP
+- 不追求构建自己的生态
+- 不追求让用户每天打开它
+
+它只是希望：
+
+**把复杂留给软件，把简单留给用户。**
+
+---
+
+## 最后
+
+如果有一天，你已经忘记 frpc-console 安装在哪里，也忘记它上一次更新是什么时候。
+
+但是：
+
+- FRP 依然稳定运行
+- 偶尔需要修改配置
+- 打开浏览器
+- 两分钟完成
+- 关闭
+- 继续忘记它
+
+那么，它已经完成了自己的使命。
+
+---
+
+*这份文档会持续更新。因为 frpc-console 的设计，本身就是一个不断演化的过程。每一次真实部署中遇到的新问题，都可能成为下一版设计哲学的注脚。*

Docs/update-strategy.md

@@ -0,0 +1,142 @@
+# 更新策略
+
+一句话：
+
+更新策略不是为了更新
+
+而是为了让你可以几年以后</br>
+依旧知道自己运行的是哪个版本
+
+---
+
+## 版本号格式
+
+frpc-console 的版本号遵循以下格式：
+
+```
+<semver>-<channel>-<date>-<time>
+```
+
+**示例：** `2.5-LTS-260804-203825`
+
+| 组成部分 | 说明 | 示例 |
+|---|---|---|
+| **semver** | 语义版本号（主版本.次版本） | `2.5` |
+| **channel** | 发布通道 | `LTS` / `Preview` |
+| **date** | 构建日期（YYMMDD） | `260804` |
+| **time** | 构建时间（HHMMSS） | `203825` |
+
+---
+
+## 为什么没有 Patch 版本？
+
+你可能已经注意到了：
+
+**版本号里只有主版本和次版本（如 `2.5`），没有 patch 号。**
+
+这不是疏忽，而是有意识的设计选择。
+
+原因很简单：
+
+- frpc-console 的发行逻辑是标准的滚动式发行逻辑，而非完全由版本号驱动
+- 因此，frpc-console 的更新粒度是基于**构建时间戳**的，每一个不同的构建时间点，对应的可能是不一样的版本
+- 每一次构建都是一个独立的版本，通过日期时间精确标识
+- `2.5-LTS-260804-203825` 和 `2.5-LTS-260805-091422` 之间，不需要、也不应该用第三个数字来区分
+
+---
+
+## 双通道：LTS / Preview
+
+项目采用双线开发模式，对应两个不同的分支：
+
+### LTS（Long-Term Support）
+
+- **分支：** `main`
+- **定位：** 稳定版，生产环境推荐
+- **特征：** 低更新频率，可以在不接收任何冷热更新的情况下，长时间稳定自持
+- **适用场景：** 生产环境、Homelab 主节点、长期运行设备
+
+### Preview
+
+- **分支：** `test`
+- **定位：** 技术预览版，包含最新设计和实验性功能
+- **特征：** 极高更新频率，很多时候会伴随大量不稳定commit，稳定性并不佳
+- **适用场景：** 开发者用测试环境、尝鲜用户、边缘节点验证
+
+---
+
+## 更新机制
+
+### 部署脚本中的更新逻辑
+
+`deploy.sh` 脚本在每次运行时，会从远程仓库读取当前分支的最新版本：
+
+```bash
+# 从远程读取 version.ini
+SEMVER=$(curl -sSL https://git.whitetop.xyz/.../version.ini)
+
+# 根据通道生成完整版本号
+if [ "$channel" = "lts" ]; then
+    TARGET_VERSION="${SEMVER}-lts-$(date +%Y%m%d)"
+else
+    TARGET_VERSION="${SEMVER}-preview-$(date +%Y%m%d-%H%M%S)"
+fi
+```
+
+每次运行部署脚本，都会生成一个新的版本号，并写入 `data/version.ini`。
+
+### 版本比较
+
+部署脚本在更新前会检查当前版本和目标版本：
+
+```bash
+CURRENT_VERSION=$(cat /opt/frpc-console/data/version.ini)
+CUR_SEMVER=$(echo "$CURRENT_VERSION" | sed -E 's/^([0-9]+\.[0-9]+).*$/\1/')
+TGT_SEMVER=$(echo "$TARGET_VERSION" | sed -E 's/^([0-9]+\.[0-9]+).*$/\1/')
+```
+
+如果检测到**语义版本降级**（例如从 `2.6` 降到 `2.5`），脚本会：
+
+1. 发出警告
+2. 自动备份当前数据目录
+3. 等待用户确认后才继续
+
+### 通道固定原则
+
+一旦选择了一个通道（LTS 或 Preview），后续升级时**不应切换通道**：
+
+- LTS → LTS：允许，正常升级
+- Preview → Preview：允许，正常升级
+- LTS → Preview：**不推荐**，可能引入未经充分验证的变更
+- Preview → LTS：**不推荐**，可能发生版本降级
+
+如果确实需要切换通道，部署脚本会在抓取源码前，自动备份你的数据库到安全位置，但是脚本本身也存在可能的不稳定因素，此时请保证你的手中至少有一份可用的较新的toml文件，可供部署完成后恢复
+
+---
+
+## 镜像保留策略
+
+Docker 部署时，脚本会自动保留最近 **3 个** 镜像：
+
+```bash
+KEEP_IMAGES=3
+```
+
+这 3 个镜像足够用于回滚，又不会占用过多存储空间（边缘节点存储有限）。
+
+---
+
+## 为什么这套策略是合理的？
+
+1. **基础设施工具不需要频繁的版本号膨胀。** 一年发布一个大版本，中间用 LTS 累积修复，比每个小补丁都发一个新版本更符合长期运行环境的预期。
+
+2. **构建日期比 patch 号更有信息量。** `2.5-LTS-260804` 一眼就能看出是 2026 年 8 月 4 日构建的 LTS 版本，不需要查 changelog。
+
+3. **用户不需要关心 patch。** 用户只需要知道当前是 LTS 还是 Preview，以及发布日期。具体的修复内容，在更新日志里。
+
+---
+
+## 相关文档
+
+- 部署脚本的更新逻辑详见：[部署指南 - Docker版](./install_docker.md) 和 [部署指南-二进制版](./install_binary.md)
+- 版本号的设计背景详见：[工程设计哲学](./engineering-philosophy.md)

deploy.sh

@@ -24,9 +24,33 @@ DEFAULT_DEPLOY_DIR="/opt/frpc-console"
 IMAGE_NAME="frpc-console"
 KEEP_IMAGES=3
 
-# ---------- 状态变量 ----------
+# ---------- 镜像加速配置 ----------
+DEFAULT_MIRRORS=(
+    "https://docker.1panel.live"
+    "https://docker.1panel.dev"
+    "https://docker.1ms.run"
+)
+DAEMON_JSON="/etc/docker/daemon.json"
+MIRROR_CHECK_TIMEOUT=5
+
+# ---------- 镜像加速状态变量 ----------
+MIRROR_STATUS=""
+DEFAULT_STATUS=""
+WRITE_DAEMON=false
+RESTART_DOCKER=false
+REORDER=false
+INSERT_DEFAULT=false
+HAS_REGISTRY_MIRRORS_KEY=false
+AVAILABLE_MIRRORS=()
+USER_MIRRORS_AVAILABLE=()
+USER_MIRRORS_UNAVAILABLE=()
+USER_MIRRORS_ALL=()
+MIRROR_DETECT_OUTPUT=""
+
+# ---------- 其他状态变量 ----------
 OS=""; OS_VERSION=""; ARCH=""
 HAS_GIT=false; HAS_CURL=false; HAS_WGET=false; HAS_DOCKER=false
+HAS_JQ=false
 NEED_INSTALL_GIT=false; NEED_INSTALL_CURL=false; NEED_INSTALL_WGET=false
 PORT=${DEFAULT_PORT}
 DEPLOY_DIR=${DEFAULT_DEPLOY_DIR}
@@ -36,6 +60,7 @@ SKIP_CONFIRM=false; CHECK_ONLY=false; DRY_RUN=false
 CHANNEL=""; BRANCH=""; TARGET_VERSION=""; IMAGE_TAG=""
 CURRENT_VERSION=""
 
+# ---------- 打印函数 ----------
 print_info() { echo -e "${BLUE}[INFO]${NC} $1"; }
 print_success() { echo -e "${GREEN}[✓]${NC} $1"; }
 print_warn() { echo -e "${YELLOW}[⚠]${NC} $1"; }
@@ -65,6 +90,7 @@ parse_args() {
     done
 }
 
+# ---------- 权限检测 ----------
 check_root() {
     if [ "$EUID" -ne 0 ]; then
         print_error "请使用 root 权限运行此脚本"
@@ -73,6 +99,7 @@ check_root() {
     fi
 }
 
+# ---------- 系统检测 ----------
 detect_os() {
     if [ -f /etc/os-release ]; then
         . /etc/os-release
@@ -96,11 +123,13 @@ detect_arch() {
     esac
 }
 
+# ---------- 工具检测 ----------
 check_tools() {
     command -v git &> /dev/null && HAS_GIT=true || NEED_INSTALL_GIT=true
     command -v curl &> /dev/null && HAS_CURL=true || NEED_INSTALL_CURL=true
     command -v wget &> /dev/null && HAS_WGET=true || NEED_INSTALL_WGET=true
     command -v docker &> /dev/null && HAS_DOCKER=true
+    command -v jq &> /dev/null && HAS_JQ=true || HAS_JQ=false
 }
 
 check_container() {
@@ -112,6 +141,444 @@ check_container() {
     fi
 }
 
+# ---------- 镜像加速：连通性检测 ----------
+check_mirror_available() {
+    local url="$1"
+    local http_code
+    http_code=$(curl -s --max-time "$MIRROR_CHECK_TIMEOUT" -o /dev/null -w "%{http_code}" \
+        "${url}/v2/" 2>/dev/null)
+    if [[ "$http_code" =~ ^2[0-9][0-9]$ ]] || [ "$http_code" = "401" ] || [ "$http_code" = "403" ]; then
+        return 0
+    fi
+    return 1
+}
+
+# ---------- 镜像加速：安装 jq ----------
+install_jq() {
+    print_info "尝试安装 jq..."
+    case $OS in
+        opensuse*|suse*|opensuse-tumbleweed|opensuse-slowroll|opensuse-leap)
+            zypper install -y jq 2>/dev/null || true
+            ;;
+        ubuntu|debian|linuxmint)
+            apt update -qq 2>/dev/null && apt install -y jq 2>/dev/null || true
+            ;;
+        centos|rhel|fedora|rocky|almalinux)
+            yum install -y jq 2>/dev/null || true
+            ;;
+        alpine)
+            apk add jq 2>/dev/null || true
+            ;;
+        arch|manjaro|endeavouros)
+            pacman -S --needed --noconfirm jq 2>/dev/null || true
+            ;;
+        *)
+            return 1
+            ;;
+    esac
+    command -v jq &> /dev/null && HAS_JQ=true || HAS_JQ=false
+    if [ "$HAS_JQ" = true ]; then
+        print_success "jq 安装成功"
+        return 0
+    else
+        print_warn "jq 安装失败，将使用 sed 模式（功能受限）"
+        return 1
+    fi
+}
+
+# ---------- 镜像加速：确保 daemon.json 存在且有效 ----------
+ensure_daemon_json_valid() {
+    if [ -f "$DAEMON_JSON" ] && [ -s "$DAEMON_JSON" ]; then
+        if jq -e '.' "$DAEMON_JSON" >/dev/null 2>&1; then
+            return 0
+        else
+            local backup_path="${DAEMON_JSON}.bak.$(date +%Y%m%d-%H%M%S)"
+            cp "$DAEMON_JSON" "$backup_path"
+            print_warn "daemon.json 格式非法，已备份至: $backup_path"
+            echo '{}' > "$DAEMON_JSON"
+            print_info "已重建为有效的 JSON 文件"
+            return 0
+        fi
+    elif [ -f "$DAEMON_JSON" ] && [ ! -s "$DAEMON_JSON" ]; then
+        local backup_path="${DAEMON_JSON}.bak.$(date +%Y%m%d-%H%M%S)"
+        cp "$DAEMON_JSON" "$backup_path" 2>/dev/null || true
+        print_warn "daemon.json 为空文件，已备份至: $backup_path"
+        echo '{}' > "$DAEMON_JSON"
+        print_info "已重建为有效的 JSON 文件"
+        return 0
+    else
+        print_info "daemon.json 不存在，将创建"
+        echo '{}' > "$DAEMON_JSON"
+        return 0
+    fi
+}
+
+# ---------- 镜像加速：检测阶段 ----------
+check_docker_mirrors() {
+    print_step "检测 Docker 镜像源配置..."
+
+    # 1. 检测三个默认地址的连通性
+    print_info "检测默认镜像源连通性 (超时 ${MIRROR_CHECK_TIMEOUT}s)..."
+    local default_available_count=0
+    for mirror in "${DEFAULT_MIRRORS[@]}"; do
+        if check_mirror_available "$mirror"; then
+            AVAILABLE_MIRRORS+=("$mirror")
+            default_available_count=$((default_available_count + 1))
+            print_info "  ✅ $mirror 可用"
+        else
+            print_info "  ❌ $mirror 不可用"
+        fi
+    done
+
+    if [ ${#AVAILABLE_MIRRORS[@]} -eq 0 ]; then
+        DEFAULT_STATUS="default_unavailable"
+        print_warn "所有默认镜像源均不可用，将跳过镜像加速配置"
+    elif [ ${#AVAILABLE_MIRRORS[@]} -eq ${#DEFAULT_MIRRORS[@]} ]; then
+        DEFAULT_STATUS="default_all_available"
+        print_success "所有默认镜像源均可用"
+    else
+        DEFAULT_STATUS="default_partial"
+        print_info "部分默认镜像源可用 (${#AVAILABLE_MIRRORS[@]}/${#DEFAULT_MIRRORS[@]})"
+    fi
+
+    # 2. 检查 daemon.json
+    if [ ! -f "$DAEMON_JSON" ]; then
+        MIRROR_STATUS="no_file"
+        HAS_REGISTRY_MIRRORS_KEY=false
+        print_info "daemon.json 不存在"
+        generate_mirror_detect_output
+        return 0
+    fi
+
+    # 3. 检测 jq 是否可解析
+    if ! jq -e '.' "$DAEMON_JSON" >/dev/null 2>&1 2>/dev/null; then
+        print_warn "daemon.json 格式不标准，将备份并重建"
+        local backup_path="${DAEMON_JSON}.bak.$(date +%Y%m%d-%H%M%S)"
+        cp "$DAEMON_JSON" "$backup_path"
+        print_info "已备份至: $backup_path"
+        echo '{}' > "$DAEMON_JSON"
+        print_warn "已重建 daemon.json，请确认是否需要将其他自定义配置迁回"
+        MIRROR_STATUS="no_file"
+        HAS_REGISTRY_MIRRORS_KEY=false
+        generate_mirror_detect_output
+        return 0
+    fi
+
+    # 4. 检查是否存在 registry-mirrors 字段
+    local has_key
+    has_key=$(jq -e 'has("registry-mirrors")' "$DAEMON_JSON" 2>/dev/null)
+    if [ "$has_key" != "true" ]; then
+        HAS_REGISTRY_MIRRORS_KEY=false
+        MIRROR_STATUS="no_key"
+        print_info "daemon.json 中无 registry-mirrors 字段"
+        generate_mirror_detect_output
+        return 0
+    fi
+
+    HAS_REGISTRY_MIRRORS_KEY=true
+
+    # 5. 读取 registry-mirrors 数组
+    local mirror_list
+    mirror_list=$(jq -r '."registry-mirrors" // [] | .[]' "$DAEMON_JSON" 2>/dev/null)
+    if [ -z "$mirror_list" ]; then
+        MIRROR_STATUS="empty_array"
+        print_info "registry-mirrors 为空数组"
+        generate_mirror_detect_output
+        return 0
+    fi
+
+    # 6. 读取用户配置所有地址（保持顺序）
+    USER_MIRRORS_ALL=()
+    while IFS= read -r mirror; do
+        if [ -n "$mirror" ]; then
+            USER_MIRRORS_ALL+=("$mirror")
+        fi
+    done <<< "$mirror_list"
+
+    # 7. 检测用户配置中每个地址的连通性
+    print_info "检测用户配置的镜像源连通性..."
+    USER_MIRRORS_AVAILABLE=()
+    USER_MIRRORS_UNAVAILABLE=()
+
+    for mirror in "${USER_MIRRORS_ALL[@]}"; do
+        if check_mirror_available "$mirror"; then
+            USER_MIRRORS_AVAILABLE+=("$mirror")
+            print_info "  ✅ $mirror (用户配置) 可用"
+        else
+            USER_MIRRORS_UNAVAILABLE+=("$mirror")
+            print_info "  ❌ $mirror (用户配置) 不可用"
+        fi
+    done
+
+    # 8. 判断状态
+    if [ ${#USER_MIRRORS_AVAILABLE[@]} -gt 0 ]; then
+        local need_reorder=false
+        local seen_unavailable=false
+        for mirror in "${USER_MIRRORS_ALL[@]}"; do
+            local is_avail=false
+            for a in "${USER_MIRRORS_AVAILABLE[@]}"; do
+                if [ "$a" = "$mirror" ]; then
+                    is_avail=true
+                    break
+                fi
+            done
+            if [ "$is_avail" = true ] && [ "$seen_unavailable" = true ]; then
+                need_reorder=true
+                break
+            fi
+            if [ "$is_avail" = false ]; then
+                seen_unavailable=true
+            fi
+        done
+
+        if [ "$need_reorder" = true ]; then
+            MIRROR_STATUS="has_valid_reorder_needed"
+            print_info "可用镜像源排在不可用镜像源之后，需要重排"
+        else
+            MIRROR_STATUS="has_valid_ordered"
+            print_info "用户镜像源配置正常，无需调整"
+        fi
+    else
+        MIRROR_STATUS="all_invalid"
+        print_warn "用户配置全部不可用"
+    fi
+
+    generate_mirror_detect_output
+}
+
+# ---------- 镜像加速：生成检测输出 ----------
+generate_mirror_detect_output() {
+    MIRROR_DETECT_OUTPUT=""
+
+    if [ "$DEFAULT_STATUS" = "default_unavailable" ]; then
+        MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}${YELLOW}⚠ 所有默认镜像源均不可用，将跳过镜像加速配置${NC}\n"
+        MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}如果 Docker 构建失败，请检查网络或手动配置镜像源。\n"
+        return
+    fi
+
+    local avail_list=""
+    for m in "${AVAILABLE_MIRRORS[@]}"; do
+        avail_list="${avail_list}  ✓ ${m}\n"
+    done
+
+    case "$MIRROR_STATUS" in
+        no_file|no_key|empty_array)
+            MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}${YELLOW}未检测到 registry-mirrors 配置。${NC}\n\n"
+            if [ ${#AVAILABLE_MIRRORS[@]} -gt 0 ]; then
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}将写入以下可用镜像源：\n\n${avail_list}\n"
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}写入位置：${DAEMON_JSON}\n"
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}${YELLOW}Docker 将在配置完成后自动重启以应用配置。${NC}\n"
+                WRITE_DAEMON=true
+                RESTART_DOCKER=true
+                REORDER=false
+                INSERT_DEFAULT=true
+            else
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}${RED}无可用的默认镜像源，将跳过配置。${NC}\n"
+                WRITE_DAEMON=false
+                RESTART_DOCKER=false
+                REORDER=false
+                INSERT_DEFAULT=false
+            fi
+            ;;
+
+        has_valid_ordered)
+            MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}${GREEN}检测完成。用户已配置可用的镜像源：${NC}\n\n"
+            for m in "${USER_MIRRORS_AVAILABLE[@]}"; do
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}  ✓ ${m}\n"
+            done
+            if [ ${#USER_MIRRORS_UNAVAILABLE[@]} -gt 0 ]; then
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}\n${YELLOW}不可用地址：${NC}\n"
+                for m in "${USER_MIRRORS_UNAVAILABLE[@]}"; do
+                    MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}  ✗ ${m}\n"
+                done
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}\n可用地址已排在不可用地址之前，无需修改。\n"
+            else
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}\n所有地址均可用，无需修改。\n"
+            fi
+            WRITE_DAEMON=false
+            RESTART_DOCKER=false
+            REORDER=false
+            INSERT_DEFAULT=false
+            ;;
+
+        has_valid_reorder_needed)
+            MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}${YELLOW}检测完成。用户配置中存在不可用或顺序不当的镜像源。${NC}\n\n"
+            MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}当前配置顺序：\n"
+            local idx=1
+            for m in "${USER_MIRRORS_ALL[@]}"; do
+                local status=""
+                local found=false
+                for a in "${USER_MIRRORS_AVAILABLE[@]}"; do
+                    if [ "$a" = "$m" ]; then
+                        found=true
+                        break
+                    fi
+                done
+                if [ "$found" = true ]; then
+                    status="${GREEN}✅ 可用${NC}"
+                else
+                    status="${RED}❌ 不可用${NC}"
+                fi
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}  ${idx}. ${m}  ${status}\n"
+                idx=$((idx + 1))
+            done
+            MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}\n${YELLOW}将重新排序：可用地址前置，不可用地址后移。${NC}\n"
+            MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}\n新顺序：\n"
+            local new_idx=1
+            for m in "${USER_MIRRORS_AVAILABLE[@]}"; do
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}  ${new_idx}. ${m}  ${GREEN}✅${NC}\n"
+                new_idx=$((new_idx + 1))
+            done
+            for m in "${USER_MIRRORS_UNAVAILABLE[@]}"; do
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}  ${new_idx}. ${m}  ${RED}❌${NC}\n"
+                new_idx=$((new_idx + 1))
+            done
+            MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}\n${YELLOW}Docker 将在配置完成后自动重启以应用配置。${NC}\n"
+            WRITE_DAEMON=true
+            RESTART_DOCKER=true
+            REORDER=true
+            INSERT_DEFAULT=false
+            ;;
+
+        all_invalid)
+            if [ ${#AVAILABLE_MIRRORS[@]} -gt 0 ]; then
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}${YELLOW}检测完成。用户配置的镜像源全部不可用：${NC}\n\n"
+                for m in "${USER_MIRRORS_UNAVAILABLE[@]}"; do
+                    MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}  ✗ ${m}\n"
+                done
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}\n${GREEN}检测到可用镜像源：${NC}\n\n"
+                for m in "${AVAILABLE_MIRRORS[@]}"; do
+                    MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}  ✓ ${m}\n"
+                done
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}\n${YELLOW}将把可用地址插入到用户配置最前面。${NC}\n"
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}${YELLOW}Docker 将在配置完成后自动重启以应用配置。${NC}\n"
+                WRITE_DAEMON=true
+                RESTART_DOCKER=true
+                REORDER=false
+                INSERT_DEFAULT=true
+            else
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}${RED}检测完成。用户配置的镜像源全部不可用：${NC}\n\n"
+                for m in "${USER_MIRRORS_UNAVAILABLE[@]}"; do
+                    MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}  ✗ ${m}\n"
+                done
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}\n${RED}默认镜像源也全部不可用。将跳过镜像加速配置。${NC}\n"
+                MIRROR_DETECT_OUTPUT="${MIRROR_DETECT_OUTPUT}${YELLOW}如果 Docker 构建失败，请检查网络连接，或手动配置 /etc/docker/daemon.json 中的 registry-mirrors。${NC}\n"
+                WRITE_DAEMON=false
+                RESTART_DOCKER=false
+                REORDER=false
+                INSERT_DEFAULT=false
+            fi
+            ;;
+    esac
+
+    echo ""
+    print_title
+    print_subtitle "Docker 镜像源检测结果"
+    echo ""
+    echo -e "$MIRROR_DETECT_OUTPUT"
+    print_title
+    echo ""
+}
+
+# ---------- 镜像加速：配置执行阶段 ----------
+configure_docker_mirrors() {
+    if [ "$WRITE_DAEMON" != true ]; then
+        print_info "无需修改 Docker 镜像源配置"
+        return 0
+    fi
+
+    print_step "配置 Docker 镜像源..."
+
+    if [ "$HAS_JQ" = false ]; then
+        print_warn "jq 未安装，尝试安装..."
+        if ! install_jq; then
+            print_error "jq 安装失败，无法配置镜像源"
+            print_error "请手动配置 /etc/docker/daemon.json 中的 registry-mirrors"
+            return 1
+        fi
+    fi
+
+    local new_mirrors=()
+    if [ "$REORDER" = true ]; then
+        new_mirrors=("${USER_MIRRORS_AVAILABLE[@]}" "${USER_MIRRORS_UNAVAILABLE[@]}")
+        print_info "[反馈] 动作: 重排镜像源顺序"
+    elif [ "$INSERT_DEFAULT" = true ]; then
+        if [ "$MIRROR_STATUS" = "no_file" ] || [ "$MIRROR_STATUS" = "no_key" ] || [ "$MIRROR_STATUS" = "empty_array" ]; then
+            new_mirrors=("${AVAILABLE_MIRRORS[@]}")
+            print_info "[反馈] 动作: 写入可用默认镜像源 (无已有配置)"
+        else
+            new_mirrors=("${AVAILABLE_MIRRORS[@]}" "${USER_MIRRORS_UNAVAILABLE[@]}")
+            print_info "[反馈] 动作: 插入可用默认镜像源到最前面 (用户配置全部不可用)"
+        fi
+    else
+        print_info "无需修改镜像源配置"
+        return 0
+    fi
+
+    print_info "[反馈] 新镜像列表: ${new_mirrors[*]}"
+
+    if ! ensure_daemon_json_valid; then
+        print_error "无法创建或修复 daemon.json"
+        return 1
+    fi
+
+    local backup_path="${DAEMON_JSON}.bak.$(date +%Y%m%d-%H%M%S)"
+    cp "$DAEMON_JSON" "$backup_path"
+    print_info "[反馈] 已备份: $backup_path"
+
+    local json_mirrors
+    json_mirrors=$(printf '%s\n' "${new_mirrors[@]}" | jq -R . | jq -s . 2>/dev/null)
+    if [ -z "$json_mirrors" ] || [ "$json_mirrors" = "[]" ]; then
+        print_error "[反馈] 构建 JSON 镜像数组失败或为空"
+        return 1
+    fi
+    print_info "[反馈] json_mirrors: $json_mirrors"
+
+    print_info "[反馈] 执行 jq 写入操作..."
+    if ! jq --argjson mirrors "$json_mirrors" '."registry-mirrors" = $mirrors' \
+        "$DAEMON_JSON" > "${DAEMON_JSON}.tmp" 2> "${DAEMON_JSON}.error"; then
+        print_error "[反馈] jq 执行失败"
+        if [ -f "${DAEMON_JSON}.error" ]; then
+            print_error "[反馈] 错误详情:"
+            cat "${DAEMON_JSON}.error" | while read -r line; do
+                print_error "  $line"
+            done
+            rm -f "${DAEMON_JSON}.error"
+        fi
+        rm -f "${DAEMON_JSON}.tmp"
+        return 1
+    fi
+
+    if [ ! -f "${DAEMON_JSON}.tmp" ] || [ ! -s "${DAEMON_JSON}.tmp" ]; then
+        print_error "[反馈] 临时文件为空或不存在"
+        rm -f "${DAEMON_JSON}.tmp"
+        return 1
+    fi
+
+    if ! jq -e '.' "${DAEMON_JSON}.tmp" >/dev/null 2>&1; then
+        print_error "[反馈] 生成的临时文件不是有效的 JSON"
+        rm -f "${DAEMON_JSON}.tmp"
+        return 1
+    fi
+
+    mv "${DAEMON_JSON}.tmp" "$DAEMON_JSON"
+    print_success "daemon.json 已更新"
+
+    if [ "$RESTART_DOCKER" = true ]; then
+        print_step "重启 Docker 服务..."
+        if systemctl restart docker 2>/dev/null; then
+            print_success "Docker 重启完成"
+            sleep 2
+        else
+            print_error "Docker 重启失败，请手动重启后重新运行脚本"
+            exit 1
+        fi
+    fi
+
+    print_success "镜像源配置完成"
+    return 0
+}
+
 # ---------- 版本管理 ----------
 read_version_from_remote() {
     local branch="$1"
@@ -244,6 +711,14 @@ print_environment_summary() {
 # ---------- 部署计划 ----------
 generate_plan() {
     PLAN=""
+    if [ "$WRITE_DAEMON" = true ]; then
+        PLAN="${PLAN}  • 配置 Docker 镜像源"
+        if [ "$RESTART_DOCKER" = true ]; then
+            PLAN="${PLAN}（写入可用地址，并重启 Docker）\n"
+        else
+            PLAN="${PLAN}\n"
+        fi
+    fi
     if [ "$NEED_INSTALL_GIT" = true ] || [ "$NEED_INSTALL_CURL" = true ] || [ "$NEED_INSTALL_WGET" = true ]; then
         local pkgs=""
         [ "$NEED_INSTALL_GIT" = true ] && pkgs="${pkgs} git"
@@ -252,12 +727,12 @@ generate_plan() {
         PLAN="${PLAN}  • 安装必要工具:${pkgs}\n"
     fi
     PLAN="${PLAN}  • 拉取 frpc-console 源码 (${BRANCH} 分支)\n"
-    PLAN="${PLAN}  • 构建 Docker 镜像: ${IMAGE_NAME}:${IMAGE_TAG}\n"
-    PLAN="${PLAN}  • 目标版本: ${TARGET_VERSION}\n"
     if [ "$CONTAINER_EXISTS" = true ]; then
         PLAN="${PLAN}  • 停止并删除旧容器\n"
     fi
-    PLAN="${PLAN}  • 启动 frpc-console 容器 (端口 ${PORT})"
+    PLAN="${PLAN}  • 构建 Docker 镜像: ${IMAGE_NAME}:${IMAGE_TAG}\n"
+    PLAN="${PLAN}  • 启动容器 (端口 ${PORT})\n"
+    PLAN="${PLAN}  • 写入版本文件并验证"
 }
 
 print_deployment_plan() {
@@ -384,14 +859,12 @@ do_deploy() {
     mkdir -p bin static
     print_success "代码拉取完成 (分支: ${BRANCH})"
 
-    # ----- 停止旧容器 -----
-    if [ "$CONTAINER_EXISTS" = true ]; then
-        print_step "停止旧容器..."
-        if [ "$CONTAINER_RUNNING" = true ]; then
-            docker stop frpc-console 2>/dev/null || true
-        fi
-        docker rm frpc-console 2>/dev/null || true
-        print_success "旧容器已清理"
+    # ============================================================
+    # 镜像加速配置：拉取代码之后、docker build 之前执行
+    # ============================================================
+    if ! configure_docker_mirrors; then
+        print_error "镜像源配置失败，请检查后重试"
+        exit 1
     fi
 
     # ----- 准备部署目录 -----
@@ -465,6 +938,23 @@ do_deploy() {
         print_info "已标记 ${IMAGE_NAME}:preview"
     fi
 
+    # ============================================================
+    # 强制清理旧容器（独立检测，不依赖之前缓存的变量）
+    # ============================================================
+    print_step "检查并清理旧容器..."
+    if docker ps -a --format '{{.Names}}' 2>/dev/null | grep -q "^frpc-console$"; then
+        print_info "检测到已存在的 frpc-console 容器"
+        if docker ps --format '{{.Names}}' 2>/dev/null | grep -q "^frpc-console$"; then
+            print_info "容器正在运行，停止中..."
+            docker stop frpc-console 2>/dev/null || true
+        fi
+        print_info "删除旧容器..."
+        docker rm frpc-console 2>/dev/null || true
+        print_success "旧容器已清理"
+    else
+        print_info "未检测到旧容器"
+    fi
+
     # ----- 启动新容器 -----
     print_step "启动 frpc-console 容器..."
     docker run -d \
@@ -594,6 +1084,8 @@ main() {
     check_tools
     check_container
 
+    check_docker_mirrors
+
     select_channel
     generate_target_version "$CHANNEL" "$BRANCH"
 

frp.go

@@ -25,12 +25,12 @@ var FrpcTemplateContent string
 
 var (
 	cachedFrpcPath string
-	frpsPathMutex  sync.Mutex
+	frpcPathMutex  sync.Mutex
 )
 
 func getFrpcPath() (string, error) {
-	frpsPathMutex.Lock()
-	defer frpsPathMutex.Unlock()
+	frpcPathMutex.Lock()
+	defer frpcPathMutex.Unlock()
 
 	if cachedFrpcPath != "" {
 		if _, err := os.Stat(cachedFrpcPath); err == nil {
@@ -144,7 +144,6 @@ func GenerateFrpcConfig() error {
 		return fmt.Errorf("渲染模板失败: %w", err)
 	}
 
-	// 所有文件写入 ./data/ 目录
 	if err := os.MkdirAll("./data", 0755); err != nil {
 		return fmt.Errorf("创建 data 目录失败: %w", err)
 	}
@@ -219,6 +218,15 @@ func StartFrpc() error {
 		return fmt.Errorf("启动 frpc 失败: %w", err)
 	}
 
+	// 回收子进程（防止僵尸进程）
+	go func() {
+		if err := cmd.Wait(); err != nil {
+			log.Printf("frpc 子进程退出: %v", err)
+		}
+		// 子进程退出后清理 PID 文件
+		os.Remove("./data/frpc.pid")
+	}()
+
 	if err := os.WriteFile("./data/frpc.pid", []byte(fmt.Sprintf("%d", cmd.Process.Pid)), 0644); err != nil {
 		return fmt.Errorf("保存 PID 失败: %w", err)
 	}

readme.md

@@ -2,285 +2,57 @@
   <img src="static/logo.svg" alt="frpc-console" width="360" />
 </p>
 
-
 # frpc-console
 
-> 轻量级 frpc 管理面板 —— 为你的内网穿透插上翅膀
-
 [![Release](https://img.shields.io/gitea/v/release/lxh2875931338/frpc-console?gitea_url=https://git.whitetop.xyz)](https://git.whitetop.xyz/lxh2875931338/frpc-console/releases)
 [![Go Version](https://img.shields.io/badge/Go-1.21+-00ADD8?style=flat&logo=go)](https://golang.org/)
 [![License](https://img.shields.io/badge/License-MIT-blue.svg)](LICENSE)
 
+**专为超长期frpc部署而设计。**
+
+一个基于实际工程实践而构建的——轻量级生命周期控制台。
+
+**安装一次。配置一次。然后——忘记它。**
+
 ---
 
-## 📖 简介
+## 📖 文档索引
+| 目录 | 简要说明 |
+|---|---|
+| [📖 工程设计哲学](./Docs/engineering-philosophy.md) | 为什么它会长成今天这样 |
+| [🔄 更新策略](./Docs/update-strategy.md)  | Preview / LTS |
+| [🚀 部署引擎设计](./Docs/deployment-engine-design.md)  | deploy 的完整架构设计 |
+| [🏗 架构设计](./Docs/architecture.md)  | 整体架构设计思路 |
+| [⚙ 设计决策](./Docs/design-decisions.md)  | 为什么没有 CI？为什么叫 Console？ |
+| [🌐 边缘节点](./Docs/edge-node.md)  | 为什么支持 BusyBox、ARMHF |
 
-**frpc-console** 是一个专为 [frp](https://github.com/fatedier/frp) 设计的轻量级管理工具。本项目旨在以无限接近原生占用的情况下，实现完全图形化的控制工具（毕竟 WebUI 也算图形化，对吧？）
+---
 
-### ✨ 核心特性
+> *“最好的基础设施工具，是当你部署完毕、配置妥当之后，便几乎感觉不到它还在运行的那一个。”*
 
-- 🔐 **首次启动引导** —— Web 端完成管理员注册，无需 CLI 交互
-- 📋 **隧道全生命周期管理** —— 增删改查 + 一键启用/禁用
-- 📦 **导入/导出 TOML** —— 无缝迁移现有 frpc 配置
-- 🔄 **配置热加载** —— 修改即生效，无需重启 frpc
-- 🖥️ **多平台支持** —— Windows / Linux / ARM 全平台兼容
-- 🐳 **容器化就绪** —— 提供 Docker 镜像，开箱即用
-- 🎨 **深色磨砂玻璃 UI** —— 现代化视觉体验，日夜皆宜
+如果想了解这句话背后的设计思考：
+
+📖 阅读[《工程设计哲学》→](./Docs/engineering-philosophy.md) 
 
 ---
 
 ## 🚀 快速开始
 
-### 🐧 二进制安装（推荐）
+选择适合您环境的部署方法：
 
-适用于 Linux / Windows，无需 Docker，单文件运行。
+- [二进制安装指南](./Docs/install_binary.md)
+- [Docker 安装指南](./Docs/install_docker.md)
 
-👉 详见：[二进制安装指南](./INSTALL_BINARY.md)
+首次访问：
 
-### 🐳 Docker 部署（一键脚本）
+1. 注册管理员账户。
+2. 导入你的 `frpc.toml`。
 
-适用于 Linux 服务器，自动编译 + 自动部署。
+然后——
 
-```bash
-curl -sSL https://git.whitetop.xyz/lxh2875931338/frpc-console/raw/main/deploy.sh | sudo bash
-```
-
-👉 详见：[Docker 安装指南](./INSTALL_DOCKER.md)
-
-### 🔧 源码编译
-
-适合开发者或需要自定义配置的用户。
-
-```bash
-git clone https://git.whitetop.xyz/lxh2875931338/frpc-console.git
-cd frpc-console
-go mod tidy
-go build -o frpc-console .
-./frpc-console
-```
-
-首次访问 `http://localhost:9300` 注册管理员账户，然后导入你的 `frpc.toml` 即可开始使用。
+**忘记它。**
 
 ---
 
-## 🗂️ 项目结构
-```txt
-frpc-console/
-├── main.go                   # 入口
-├── api.go                    # HTTP 路由 & Handler
-├── db.go                     # SQLite 数据库操作
-├── auth.go                   # JWT 认证 & 密码管理
-├── frp.go                    # frpc 管理核心逻辑
-├── toml_parser.go            # TOML 解析器
-├── static/                   # 前端静态资源
-│   ├── index.html
-│   ├── app.js
-│   ├── style-1.css           # 全局基础样式
-│   ├── style-2.css           # 登录页样式
-│   ├── style-3.css           # 主界面样式
-    └── style-4.css
-├── bin/                      # 内嵌 frpc 二进制 (多平台)
-│   ├── frpc_windows_amd64.exe
-│   ├── frpc_linux_amd64
-│   ├── frpc_linux_arm64
-│   └── frpc_linux_arm_hf
-├── frpc.tmpl            # frpc 配置模板
-├── Dockerfile
-└── go.mod
-```
+[**MIT License © 2026 lxh2875931338（XHLiang0）**](./License.md) · [GitHub](https://github.com/XHLiang0) · [致谢](./Docs/acknowledgment.md)
 
-## ⚙️ 配置说明
-
-### 环境变量
-
-| 变量 | 说明 | 默认值 |
-|---|---|---|
-| PORT | 监听端口 | 9300 |
-
-
-### 数据存储
-
-· 数据库文件：./frpc-console.db</br>
-· frpc 配置文件：./frpc.toml</br>
-· frpc 日志文件：./frpc.log</br>
-
----
-
-## 🛠️ 开发指南
-
-```bash
-# 克隆项目
-git clone https://github.com/lxh2875931338/frpc-console.git
-cd frpc-console
-
-# 安装依赖
-go mod tidy
-
-# 开发模式运行
-go run .
-
-# 编译生产版本
-go build -ldflags="-s -w" -o frpc-console .
-```
-
-## 前端开发
-
-前端使用 Vue 3 CDN + Naive UI，无需额外构建工具。修改 static/ 目录下的文件后，刷新浏览器即可预览效果。
-
-
----
-
-## 🔧 常见问题
-
-#### Q: 如何修改管理员密码？
-
-登录后，在「全局配置」页面顶部找到「账户管理」区域，输入当前密码和新密码即可。
-
-#### Q: 如何导入现有的 frpc.toml？
-
-在「隧道列表」页面点击「导入 TOML」，选择你的 frpc.toml 文件即可。
-
-#### Q: frpc 启动失败怎么办？
-
-如果是首次启动，console 会自动生成一份符合官方规范的 `frps.toml` 配置文件，通常不需要额外操作。
-
-如果在使用过程中遇到启动失败，可以按以下步骤排查：
-
-1. **检查配置是否正确** —— 在「全局配置」页面重新配置一次服务端参数，或导入已有的 `frpc.toml` 配置文件，console 会自动应用并尝试重启
-2. **查看日志定位问题** —— 若上述操作后仍然失败，请查看 `./frpc.log` 日志文件，定位具体报错原因
-
-> 日志文件的位置：与 `frpc-console` 二进制同级目录下的 `frpc.log`。Docker 部署时，可通过 `docker logs frpc-console` 查看容器输出。
-
-#### Q: 支持哪些 frp 版本？
-
-目前支持情况如下：
-
-| 系统 | 架构版本 | 版本号 |
-|---|---|---|
-| Linux | AMD64/x86-64 | 0.70.0 |
-| Linux | ARM64/Aarch64 | 0.70.0 |
-| Linux | ARM_hf/ARMv7l | 0.70.0 |
-| Windows | AMD64/x86-64 | 0.70.0 |
-
-> 行了行了，Windows 版和 Linux 版版本号已同步。不用再等了。
-
-#### Q: 为什么不用 / 不推荐 Podux？
-
-Podux 是个好项目，理念上和我们是一致的：用 Web 界面管理 frpc</br>
-但它的设计取向和我们完全不同：
-
-| 对比项 | frpc-console | Podux |
-|---|---|---|
-| 数据库 | SQLite（单文件，几 MB） | PocketBase（带 Admin UI、用户系统、全套 API） |
-| 前端 | Vue CDN | React + Webpack |
-| 实机内存占用 | **~50 MB** | **没启动成功，1GB RAM 独立分配仍 OOM（原因不明）** |
-| 镜像大小 | 封装多平台二进制frpc后 120.28 MB | 76.1 MB |
-| 部署方式 | 单二进制 / Docker | 单二进制 / Docker |
-| 多平台支持 | ✅ 原生交叉编译 | ✅ 原生交叉编译 |
-
-> Podux 与其说是一个 frp 控制面板，不如说是一个“一站式 frp 管理器 + 可视化数据流面板 + 通道保活监测工具”。这种一站式本身没毛病，甚至功能实现非常到位。</br>但 podux的框架选型有点重，而且很明显细节稍显仓促。PocketBase 自带 WebUI 的情况下，Podux 还要再包一层 WebUI——相当于给数据库的 UI 又套了个 UI。更费解的是，这层 WebUI 只支持导入，不支持导出。这设计确实让人有点摸不着头脑啦……</br>所以干脆换了一套轻量化工具自己上咯~
-
-
-### Q: 为什么不直接用 frp 官方提供的 web 界面？
-
-frp 官方确实提供了 `dashboard` 和 `frpc-admin` 功能，但它们更多是“监控”视角，而非“管理”视角。你需要手动编辑配置文件，重启 frpc，或者依赖命令行操作。
-
-frpc-console 的目标是：
-- **点一点就能新增隧道**
-- **开关一拨就能启用/禁用**
-- **导入导出无缝迁移**
-- **热加载无需重启**
-
-### Q: 如果 frpc-console 进程挂了，frpc 本身会受影响吗？
-
-**不会。**
-
-这是 frp-console 系列工具与同类项目最核心的区别之一。我们称之为 **“阴阳模式”**。</br>
-接下来，我们将结合中式哲学思想，阐述这个名称的由来：
-
-#### 什么是“阴阳模式”？
-
-以人的观察为出发点：
-
-- **阴**：看不见的业务流（frpc 进程、toml 配置文件、隧道连接）
-- **阳**：看得见的管理面板（Web 界面、API 服务）
-
-大多数管理工具走的是 **“阳阴模式”**：面板是“大脑”，业务是“肢体”。大脑一旦停止工作，肢体也就瘫痪了。</br>
-在这种模式下，管理面板与业务进程深度绑定，面板退出时业务进程也会随之终止。
-
-**frpc-console 走的是“阴阳模式”：业务是根基，面板是工具。**
-
-- **阴主导阳**：业务不依赖面板存活，面板只是用来观察和调整业务状态的手段
-- **阳依附于阴**：面板的存在是为了服务业务，而不是反过来
-
-
-#### 不同部署方式下的行为
-
-**二进制部署：**
-
-frpc-console 启动时，会以子进程的方式拉起 frpc，并为它创建一个独立的进程会话（`Setsid`）。这意味着 frpc 完全脱离父进程的生命周期控制。即使 SSH 断开导致 frpc-console 进程退出，frpc 也会被系统的 init 进程（PID 1）接管，继续在后台稳定运行。配置文件（`frpc.toml`）是持久化文件，不依赖 console 进程存活。面板可以随时挂、随时重启、随时升级，但隧道业务不受任何干扰。
-
-**Docker 部署：**
-
-容器使用 `--restart=always` 策略，frpc-console 进程意外退出时，Docker 守护进程会自动重启整个容器。重启后，console 重新读取持久化的 `frpc.toml`，重新拉起 frpc 子进程。数据目录（`/opt/frpc-console/data`）通过卷挂载持久化，容器重启不会丢失任何配置。Docker 模式的本质依然是“阳辅助阴”——`restart:always` 的目的是确保阴（业务）持续运行，而不是为了保住阳（面板）本身。
-
-
-#### 为什么同类项目里很少见到这种设计？
-
-因为大多数管理工具把“面板”和“业务”耦合在一起，认为面板是前提条件，业务是附属品。当然了，这确实是正向的、符合直觉的设计方向。但是有一个被很多人忽略的事实：**真正需要长期稳定运行的是隧道本身，而不是管理界面的进程。**
-
-界面是用来观察和调整的，不是用来维持业务存活的。这是运维集群常用的“管理面与控制面分离”——只不过通常只在几千台服务器的集群管理里才会出现，很少有人会把它用在一个人用的 frp 管理工具上。
-
-
-#### 核心原则
-
-console 只做“配置的保管者”和“进程的启动者”，而不是“配置的持有者”或“进程的绑定者”。即使 console 完全离线，已经生成的 `frpc.toml` 依然存在，frpc 进程依然可以独立运行。这是 frp 本身的容灾能力在管理工具层面的自然延伸——**可视化框架只是工具，业务本身才是核心。**
-
-> **管理面板可以丢，业务功能打死不能停。**
-
-### Q: 支持 frp 的所有功能吗？
-
-frpc-console 覆盖了 frp 最核心的 **TCP 隧道管理** 功能，包括 `tcpMux`、负载均衡、心跳配置等。如果你有更复杂的需求（比如 STCP、XTCP、P2P），欢迎提 issue，我们会评估是否加入。
-
----
-
-## 🧠 设计哲学
-
-frpc-console 遵循 **“够用就好”** 的原则：
-
-1. **frp 是轻量工具，管理工具也应该是轻量的。**
-2. **能用 SQLite 就不用 PostgreSQL，能用 Vue CDN 就不用 React 全家桶。**
-3. **前端能做的事，后端不加额外复杂度。**
-4. **删掉一个容器等于删掉所有垃圾，所以用 Docker 隔离是对的。**
-5. **面板的存在应该是为了服务业务的，而不该是反过来主导业务的。**
-
----
-
-## 📝 更新日志
-
-#### 相关更新日志请查看[update-logs.md](./update-logs.md)
-
----
-
-## 📄 许可证
-
-MIT License © 2026 lxh2875931338（XHLiang0）
-
----
-
-## 🙏 相关项目援引
-
-### FRP 生态互补工具
-
-· [MoonProxy](https://github.com/MoonProxyHQ/moonproxy-desktop) —— 基于 Tauri v2 + Vue 3 + Rust 构建的跨平台 FRP 桌面客户端（frpc GUI），面向 macOS 与 Windows，让内网穿透开箱即用，MIT协议开源。
-
-### FRP 生态同类工具（暂无互引）
-</br>
-
----
-
-## 🙏 致谢
-
-· fatedier/frp —— 强大的内网穿透工具</br>
-· gin-gonic/gin —— 高性能 Go Web 框架</br>
-· vuejs/vue —— 渐进式 JavaScript 框架

static/index.html

@@ -100,7 +100,8 @@
                                 <!-- Ping 延迟显示 -->
                                 <span class="ping-display" :class="pingStatusClass">
                                     <span class="ping-icon" v-html="pingIcon"></span>
-                                    <span class="ping-value">{{ pingLatency !== null ? pingLatency + 'ms' : '--ms' }}</span>
+                                    <span class="ping-value">{{ pingLatency !== null ? pingLatency + 'ms' : '--ms'
+                                        }}</span>
                                 </span>
                             </span>
                         </div>
@@ -343,6 +344,14 @@
                 </div> <!-- /content-area -->
 
                 <!-- ====== 弹窗 ====== -->
+
+
+            </div> <!-- /main-panel -->
+        </div> <!-- /app-container -->
+
+        <!-- 隐藏文件选择器 -->
+        <input type="file" id="tomlFileInput" accept=".toml" style="display:none" @change="handleImport" />
+
         <Transition name="dialog">
             <div v-if="dialogVisible" class="dialog-overlay" @click.self="dialogVisible = false">
                 <div class="dialog-card">
@@ -371,13 +380,6 @@
                 </div>
             </div>
         </Transition>
-
-            </div> <!-- /main-panel -->
-        </div> <!-- /app-container -->
-
-        <!-- 隐藏文件选择器 -->
-        <input type="file" id="tomlFileInput" accept=".toml" style="display:none" @change="handleImport" />
-
     </div> <!-- /#app -->
 
     <script src="/static/app.js"></script>

static/style-1.css

@@ -1,30 +1,28 @@
 /* ===== style-1.css - 全局基础 ===== */
 
 /* ---------- 字体定义 ---------- */
+/* 自托管 HarmonyOS Sans SC Regular */
+
+/* 中英文：HarmonyOS Sans SC Regular */
 @font-face {
     font-family: 'HarmonyOS Sans SC';
-    src: local('HarmonyOS Sans SC'),
-         local('PingFang SC'),
-         local('Microsoft YaHei'),
-         local('Helvetica Neue');
+    src: url('./fonts/HarmonyOS_Sans_SC_Regular.ttf') format('truetype');
     font-weight: 400;
+    font-style: normal;
     font-display: swap;
 }
+
+/* 数字专用：复用 HarmonyOS Sans SC Regular（因 Light 版本缺失） */
 @font-face {
-    font-family: 'HarmonyOS Sans SC';
-    src: local('HarmonyOS Sans SC Medium'),
-         local('PingFang SC Medium');
-    font-weight: 500;
-    font-display: swap;
-}
-@font-face {
-    font-family: 'HarmonyOS Sans SC';
-    src: local('HarmonyOS Sans SC Bold'),
-         local('PingFang SC Semibold');
-    font-weight: 700;
+    font-family: 'HarmonyOS Sans';
+    src: url('./fonts/HarmonyOS_Sans_SC_Regular.ttf') format('truetype');
+    font-weight: 300;
+    font-style: normal;
     font-display: swap;
 }
 
+/* 后备：如果自托管字体加载失败，使用系统字体 */
+
 /* ---------- 重置 ---------- */
 * {
     margin: 0;
@@ -33,14 +31,14 @@
 }
 
 body {
-    font-family: 'Segoe UI', 'PingFang SC', 'Microsoft YaHei', sans-serif;
+    font-family: 'HarmonyOS Sans SC', 'PingFang SC', 'Microsoft YaHei', 'Helvetica Neue', sans-serif;
     background: #0a0a0f;
     height: 100vh;
     overflow: hidden;
     color: #e0e0e0;
 }
 
-/* ---------- 数字专用字体（加粗） ---------- */
+/* ---------- 数字专用字体（使用 HarmonyOS Sans） ---------- */
 .digit,
 .big-number,
 .remote-port,
@@ -51,22 +49,23 @@ body {
 .login-btn,
 .save-btn,
 .btn-confirm {
-    font-weight: 600 !important;
+    font-weight: 300 !important;
     letter-spacing: 0.02em;
+    font-family: 'HarmonyOS Sans', 'JetBrains Mono', monospace;
 }
 
 /* 数字特别加粗（适用于大数字展示） */
 .big-number {
-    font-weight: 700 !important;
+    font-weight: 600 !important;
     letter-spacing: -0.01em;
 }
 
-/* 代码/端口类数字使用等宽字体，但保持加粗 */
+/* 代码/端口类数字使用等宽字体，但保持 HarmonyOS Sans 风格 */
 .digit,
 .remote-port,
 .proxy-addr {
-    font-family: 'HarmonyOS Sans SC', 'JetBrains Mono', monospace;
-    font-weight: 600 !important;
+    font-family: 'HarmonyOS Sans', 'JetBrains Mono', monospace;
+    font-weight: 300 !important;
 }
 
 /* ---------- 全局颜色变量 ---------- */
@@ -175,7 +174,7 @@ body {
     height: 100%;
     display: flex;
     flex-direction: column;
-    padding: 20px 28px;          /* ← 补上内边距 */
+    padding: 20px 28px;
     opacity: 0;
     transition: opacity 0.3s ease;
 }

static/style-3.css

@@ -17,8 +17,8 @@
 }
 
 .top-left .nav-logo {
-    width: 48px;
-    height: 48px;
+    width: 52px;   /* 原 48px */
+    height: 52px;  /* 原 48px */
     flex-shrink: 0;
     display: block;
     object-fit: contain;
@@ -32,7 +32,7 @@
 }
 
 .brand-info .logo-text {
-    font-size: 22px;
+    font-size: 20px;
     font-weight: 600;
     color: var(--text-primary);
     line-height: 1.2;
@@ -59,8 +59,9 @@
     box-shadow: 0 0 12px rgba(99, 226, 183, 0.4);
 }
 
+/* 状态文字 12px（原 13px） */
 .status-wrapper .status-text {
-    font-size: 13px;
+    font-size: 12px;
     color: var(--text-muted);
 }
 
@@ -71,7 +72,7 @@
 }
 
 .user-name {
-    font-size: 13px;
+    font-size: 12px;  /* 原 13px，与状态文字对齐 */
     color: var(--text-secondary);
 }
 
@@ -375,7 +376,7 @@
 .proxy-addr {
     font-size: 13px;
     color: var(--text-dim);
-    font-family: 'JetBrains Mono', monospace;
+    font-family: 'HarmonyOS Sans','JetBrains Mono', monospace;
 }
 
 .proxy-tag {
@@ -395,7 +396,7 @@
 }
 
 .remote-port {
-    font-family: 'JetBrains Mono', monospace;
+    font-family: 'HarmonyOS Sans','JetBrains Mono', monospace;
     font-size: 14px;
     color: var(--text-secondary);
 }
@@ -801,3 +802,40 @@ select:disabled {
         height: 14px;
     }
 }
+
+/* ---------- Tab 栏 ---------- */
+.tab-bar {
+    display: flex;
+    gap: 32px;
+    padding: 14px 0 12px;
+    flex-shrink: 0;
+    border-bottom: 1px solid var(--border-subtle);
+}
+
+/* 将最后一个 Tab（用户配置）推到最右侧 */
+.tab-item:last-child {
+    margin-left: auto;
+    /* 防止用户名过长导致溢出 */
+    max-width: 220px;
+    overflow: hidden;
+    text-overflow: ellipsis;
+    white-space: nowrap;
+}
+
+.tab-item {
+    font-size: 14px;
+    color: var(--text-muted);
+    cursor: pointer;
+    padding: 4px 0;
+    transition: color 0.3s, border-color 0.3s;
+    border-bottom: 2px solid transparent;
+}
+
+.tab-item:hover {
+    color: var(--text-secondary);
+}
+
+.tab-item.active {
+    color: var(--primary-blue);
+    border-bottom-color: var(--primary-blue);
+}

update-logs.md

@@ -5,6 +5,30 @@
 | LTS 正式版 | `-lts` | 生产环境，长期维护 |
 | 技术预览版 | `-preview` | 功能前瞻，建议测试环境验证 |
 
+---
+
+## 2.5-lts (2026-08-03)
+
+> **稳定加固版 —— 架构升级与部署流程闭环**
+
+### 核心变更
+
+- 数据目录规范化 —— 所有运行时文件统一迁移至 `/app/data`，挂载点从 `/app` 收窄至 `/app/data`，彻底解决挂载覆盖二进制文件的问题
+- 版本管理解耦 —— 二进制不再注入版本信息，由 `deploy.sh` 在部署时写入 `version.ini`
+- 入口脚本分离 —— 引入 `run-deploy.sh` 独立入口，用户只需记住一个命令
+- 僵尸进程回收 —— 子进程退出时自动回收资源，防止僵尸进程积累
+
+### UI 优化
+
+- 字体全系 HarmonyOS Sans SC，视觉风格统一
+- 「用户配置」Tab 移至导航栏最右侧
+- 弹窗居中修复，顶部导航字号优化
+
+### 🐛 修复
+
+- 修复挂载覆盖导致二进制不可用的问题
+- 修复 `ps | grep` 进程检测在容器环境不可靠的问题
+- 修复旧版本升级时数据库路径不兼容的问题
 
 ## 🚀 2.4-lts (2026-07-30)
 

version.ini

@@ -3,4 +3,4 @@
 ; 示例:
 ;   2.4              # Preview 版本，无日期
 ;   2.5 20260729     # LTS 版本，带发布日期
-2.4
+2.5