From 7636af4385790e42c59f2ecb0e8a291527a316d4 Mon Sep 17 00:00:00 2001 From: lxh2875931338 Date: Mon, 3 Aug 2026 22:44:34 +0800 Subject: [PATCH] =?UTF-8?q?readme=E6=9B=B4=E6=96=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- readme.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/readme.md b/readme.md index 354dc91..a010273 100644 --- a/readme.md +++ b/readme.md @@ -73,12 +73,14 @@ frpc-console/ ├── frp.go # frpc 管理核心逻辑 ├── toml_parser.go # TOML 解析器 ├── static/ # 前端静态资源 +│ ├── fonts +│ │ └── HarmonyOS_Sans_SC_Regular.ttf │ ├── index.html │ ├── app.js │ ├── style-1.css # 全局基础样式 │ ├── style-2.css # 登录页样式 │ ├── style-3.css # 主界面样式 - └── style-4.css +│ └── style-4.css ├── bin/ # 内嵌 frpc 二进制 (多平台) │ ├── frpc_windows_amd64.exe │ ├── frpc_linux_amd64 @@ -174,12 +176,15 @@ Podux 是个好项目，理念上和我们是一致的：用 Web 界面管理 fr | 数据库 | SQLite（单文件，几 MB） | PocketBase（带 Admin UI、用户系统、全套 API） | | 前端 | Vue CDN | React + Webpack | | 实机内存占用 | **~50 MB** | **没启动成功，1GB RAM 独立分配仍 OOM（原因不明）** | -| 镜像大小 | 封装多平台二进制frpc后 120.28 MB | 76.1 MB | +| 镜像大小 | 封装二进制frpc后均值 173.86 MB | 76.1 MB | +| 二进制大小 | 4平台均值93M | 12.4 MB | | 部署方式 | 单二进制 / Docker | 单二进制 / Docker | | 多平台支持 | ✅ 原生交叉编译 | ✅ 原生交叉编译 | > Podux 与其说是一个 frp 控制面板，不如说是一个“一站式 frp 管理器 + 可视化数据流面板 + 通道保活监测工具”。这种一站式本身没毛病，甚至功能实现非常到位。
但 podux的框架选型有点重，而且很明显细节稍显仓促。PocketBase 自带 WebUI 的情况下，Podux 还要再包一层 WebUI——相当于给数据库的 UI 又套了个 UI。更费解的是，这层 WebUI 只支持导入，不支持导出。这设计确实让人有点摸不着头脑啦……
所以干脆换了一套轻量化工具自己上咯~ +> 不过现在的 frpc-console，更倾向于拿存储换内存呢……
毕竟内存卡也好，硬盘也罢，即使是嵌入式平台，价格都不算很离谱，也就是一张大点的64G或者128G内存卡的事情
但是内存可就不一样了哦，这玩意在嵌入式平台是真的寸土寸金呢……
咱就举个例子吧，RK3506，128和256M版本共存；全志H3，256 和 512M 内存并存
虽然这俩都不算太极端，尤其是全志 H3，挤一挤甚至 docker 版也能装得上，但是也能说明，在一些廉价的低功耗开发板上，内存容量其实真的很稀缺……
所以牺牲一点存储空间（镜像大了几十 MB），换来 50MB 的内存占用，这笔账怎么算都不亏，对吧？ + ### Q: 为什么不直接用 frp 官方提供的 web 界面？