readme更新

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 管理器 + 可视化数据流面板 + 通道保活监测工具”。这种一站式本身没毛病，甚至功能实现非常到位。</br>但 podux的框架选型有点重，而且很明显细节稍显仓促。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 的内存占用，这笔账怎么算都不亏，对吧？
+
 
 ### Q: 为什么不直接用 frp 官方提供的 web 界面？