优化部分readme措辞

readme.md

@@ -181,7 +181,7 @@ Podux 是个好项目，理念上和我们是一致的：用 Web 界面管理 fr
 | 部署方式 | 单二进制 / Docker | 单二进制 / Docker |
 | 多平台支持 | ✅ 原生交叉编译 | ✅ 原生交叉编译 |
 
-> Podux 与其说是一个 frp 控制面板，不如说是一个“一站式 frp 管理器 + 可视化数据流面板 + 通道保活监测工具”。这种一站式本身没毛病，甚至功能实现非常到位。</br>但 podux的框架选型有点重，而且很明显细节稍显仓促。PocketBase 自带 WebUI 的情况下，Podux 还要再包一层 WebUI——相当于给数据库的 UI 又套了个 UI。更费解的是，这层 WebUI 只支持导入，不支持导出。这设计确实让人有点摸不着头脑啦……</br>所以干脆换了一套轻量化工具自己上咯~
+> Podux 与其说是一个 frp 控制面板，不如说是一个“一站式 frp 管理器 + 可视化数据流面板 + 通道保活监测工具”。这种一站式本身没毛病，甚至功能实现非常到位。</br>但 podux 的框架选型有点重，细节也稍显仓促，最终结果就是内存占用相当夸张——1GB 都未必够它霍霍的，而且你根本不知道这些内存都花在了哪里。PocketBase 自带 WebUI 的情况下，Podux 还要再包一层 WebUI——相当于给数据库的 UI 又套了个 UI。更费解的是，这层 WebUI 只支持导入，不支持导出。这设计确实让人有点摸不着头脑啦……</br>所以干脆换了一套轻量化工具自己上咯~
 
 > 不过现在的 frpc-console，更倾向于拿存储换内存呢……</br>毕竟内存卡也好，硬盘也罢，即使是嵌入式平台，价格都不算很离谱，也就是一张大点的64G或者128G内存卡的事情</br>但是内存可就不一样了哦，这玩意在嵌入式平台是真的寸土寸金呢……</br>咱就举个例子吧，RK3506，128和256M版本共存；全志H3，256 和 512M 内存并存</br>虽然这俩都不算太极端，尤其是全志 H3，挤一挤甚至 docker 版也能装得上，但是也能说明，在一些廉价的低功耗开发板上，内存容量其实真的很稀缺……</br>所以牺牲一点存储空间（镜像大了几十 MB），换来 50MB 的内存占用，这笔账怎么算都不亏，对吧？
 
@@ -196,50 +196,32 @@ frpc-console 的目标是：
 - **导入导出无缝迁移**
 - **热加载无需重启**
 
-### Q: 如果 frpc-console 进程挂了，frpc 本身会受影响吗？
+#### Q: 如果 frpc-console 进程挂了，frpc 本身会受影响吗？
 
 **不会。**
 
-这是 frp-console 系列工具与同类项目最核心的区别之一。我们称之为 **“阴阳模式”**。</br>
-接下来，我们将结合中式哲学思想，阐述这个名称的由来：
+这是 frp-console 系列工具与同类项目最核心的区别之一。我们称之为 **“阴阳模式”**。
 
-#### 什么是“阴阳模式”？
+**什么是“阴阳模式”？**
 
-以人的观察为出发点：
-
-- **阴**：看不见的业务流（frpc 进程、toml 配置文件、隧道连接）
+- **阴**：看不见的业务流（frpc 进程、toml 配置文件）
 - **阳**：看得见的管理面板（Web 界面、API 服务）
 
-大多数管理工具走的是 **“阳阴模式”**：面板是“大脑”，业务是“肢体”。大脑一旦停止工作，肢体也就瘫痪了。</br>
-在这种模式下，管理面板与业务进程深度绑定，面板退出时业务进程也会随之终止。
+大多数管理工具走的是 **“阳阴模式”**：面板是大脑，业务是肢体。大脑一旦停止工作，肢体也就瘫痪了。
 
 **frpc-console 走的是“阴阳模式”：业务是根基，面板是工具。**
 
-- **阴主导阳**：业务不依赖面板存活，面板只是用来观察和调整业务状态的手段
-- **阳依附于阴**：面板的存在是为了服务业务，而不是反过来
-
-
-#### 不同部署方式下的行为
-
 **二进制部署：**
-
-frpc-console 启动时，会以子进程的方式拉起 frpc，并为它创建一个独立的进程会话（`Setsid`）。这意味着 frpc 完全脱离父进程的生命周期控制。即使 SSH 断开导致 frpc-console 进程退出，frpc 也会被系统的 init 进程（PID 1）接管，继续在后台稳定运行。配置文件（`frpc.toml`）是持久化文件，不依赖 console 进程存活。面板可以随时挂、随时重启、随时升级，但隧道业务不受任何干扰。
+frpc-console 启动时，通过 `Setsid` 为 frpc 创建独立会话，使其完全脱离父进程的生命周期控制。即使 SSH 断开导致 console 退出，frps 也会被 init 进程（PID 1）接管，继续稳定运行。
 
 **Docker 部署：**
+容器使用 `--restart=always`，console 退出时 Docker 自动重启并重新拉起 frpc。数据目录通过卷挂载持久化，配置不丢失。
 
-容器使用 `--restart=always` 策略，frpc-console 进程意外退出时，Docker 守护进程会自动重启整个容器。重启后，console 重新读取持久化的 `frpc.toml`，重新拉起 frpc 子进程。数据目录（`/opt/frpc-console/data`）通过卷挂载持久化，容器重启不会丢失任何配置。Docker 模式的本质依然是“阳辅助阴”——`restart:always` 的目的是确保阴（业务）持续运行，而不是为了保住阳（面板）本身。
+两种部署方式的本质一致：**面板是“阳”，服务于“阴”；“阴”不依赖“阳”而存在。**
 
+**为什么同类项目很少这样做？**
 
-#### 为什么同类项目里很少见到这种设计？
-
-因为大多数管理工具把“面板”和“业务”耦合在一起，认为面板是前提条件，业务是附属品。当然了，这确实是正向的、符合直觉的设计方向。但是有一个被很多人忽略的事实：**真正需要长期稳定运行的是隧道本身，而不是管理界面的进程。**
-
-界面是用来观察和调整的，不是用来维持业务存活的。这是运维集群常用的“管理面与控制面分离”——只不过通常只在几千台服务器的集群管理里才会出现，很少有人会把它用在一个人用的 frp 管理工具上。
-
-
-#### 核心原则
-
-console 只做“配置的保管者”和“进程的启动者”，而不是“配置的持有者”或“进程的绑定者”。即使 console 完全离线，已经生成的 `frpc.toml` 依然存在，frpc 进程依然可以独立运行。这是 frp 本身的容灾能力在管理工具层面的自然延伸——**可视化框架只是工具，业务本身才是核心。**
+因为大多数管理工具默认“面板是前提条件”，而忽略了：**真正需要长期稳定运行的是隧道本身，而不是管理界面的进程。**
 
 > **管理面板可以丢，业务功能打死不能停。**