阐述一个新的设计理念“阴阳模式”

readme.md

@@ -169,7 +169,7 @@ Podux 是个好项目，理念上和我们是一致的：用 Web 界面管理 fr
 | 部署方式 | 单二进制 / Docker | 单二进制 / Docker |
 | 多平台支持 | ✅ 原生交叉编译 | ✅ 原生交叉编译 |
 
-> Podux 与其说是一个 frp 控制面板，不如说是一个“一站式 frp 管理器 + 可视化数据流面板 + 通道保活监测工具”。这种一站式本身没毛病，甚至功能实现非常到位。</br>但 podux的框架选型有点重，而且很明显细节稍显仓促。PocketBase 自带 WebUI 的情况下，Podux 还要再包一层 WebUI——相当于给数据库的 UI 又套了个 UI。更费解的是，这层 WebUI 只支持导入，不支持导出。这设计确实让人有点摸不着头脑。</br>这也正是我们选择 SQLite + Vue CDN 的原因。
+> Podux 与其说是一个 frp 控制面板，不如说是一个“一站式 frp 管理器 + 可视化数据流面板 + 通道保活监测工具”。这种一站式本身没毛病，甚至功能实现非常到位。</br>但 podux的框架选型有点重，而且很明显细节稍显仓促。PocketBase 自带 WebUI 的情况下，Podux 还要再包一层 WebUI——相当于给数据库的 UI 又套了个 UI。更费解的是，这层 WebUI 只支持导入，不支持导出。这设计确实让人有点摸不着头脑啦……</br>所以干脆换了一套轻量化工具自己上咯~
 
 
 ### Q: 为什么不直接用 frp 官方提供的 web 界面？
@@ -182,6 +182,53 @@ frpc-console 的目标是：
 - **导入导出无缝迁移**
 - **热加载无需重启**
 
+### 如果 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，我们会评估是否加入。
@@ -196,6 +243,7 @@ frpc-console 遵循 **“够用就好”** 的原则：
 2. **能用 SQLite 就不用 PostgreSQL，能用 Vue CDN 就不用 React 全家桶。**
 3. **前端能做的事，后端不加额外复杂度。**
 4. **删掉一个容器等于删掉所有垃圾，所以用 Docker 隔离是对的。**
+5. **面板的存在应该是为了服务业务的，而不该是反过来主导业务的。**
 
 ---
 

static/index.html

@@ -170,7 +170,7 @@
 
                         <!-- 首次使用提示 -->
                         <div v-if="showDefaultTip" class="config-tip">
-                            首次使用请修改「服务器地址」和「认证令牌」为您的真实 frps 配置
+                            首次使用请修改「服务器地址」和「认证令牌」为您的真实 frpc 配置
                         </div>
 
                         <!-- ===== 账户管理 ===== -->
@@ -272,7 +272,7 @@
                                         </label>
                                     </div>
                                     <span class="hint-text v2-hint">
-                                        此功能为 frp 0.70.0 以上版本才能开启，若要打开必须搭配同版本 frps 使用，否则此功能不生效
+                                        此功能为 frp 0.70.0 以上版本才能开启，若要打开必须搭配同版本 frpc 使用，否则此功能不生效
                                     </span>
                                 </div>
                             </div>