系列开篇：告别命令行的束缚，我为何选择 Wails v3 打造 frp 管理客户端？
一、困境与契机：低配服务器、高性能需求与共享经济的思考 我的云服务器配置很“复古”：1 核 CPU、1G 内存、1M 带宽。它完美地满足了我个人博客的需求，直到我需要演示一套视频会议系统。该系统最低要求 2 核 4G。 我的服务器是包年做活动时购买，升级配置成本高昂，而我的本地电脑性能过剩，为了一次演示，我升级我的云服务器，我感觉不值。为了解决这个问题，frp（Fast Reverse Proxy） 成为了我的救星，它允许我将本地高性能服务安全地映射到公网。 新的痛点出现：命令行的局限性 在成功通过命令行 frpc 实现了内网穿透演示后，我发现了一系列生产力问题： 进程管理难题： 命令行窗口一旦关闭，frpc 进程随之终止，服务中断。这在日常使用中非常不便，因为会经常手误关闭窗口。 潜在的商业价值： 我有闲置资源服务器，公网 IP 以及域名。对于那些临时需要公网映射的用户来说，这是一个刚需。 流量变现与服务化： 我有一个小程序并集成了广告。如果能让用户通过看广告来获取临时的 frps 使用权（子域名分配），可以减少我的服务器支出，这将是一个双赢的模式。 为了解决这些问题并实现我的想法，我意识到可以做一个稳定、可后台运行、拥有友好 UI 的客户端，来替代原始的命令行操作。 二、技术选型坎坷路：Fyne、Tauri 的尝试与碰壁 我的技术栈主要集中在 Go、Rust 和 JavaScript，其中 Go 最擅长。我希望使用这些技术栈实现一个跨平台的客户端。 第一次尝试：Go & Fyne Fyne 是一款使用 Go 语言编写的跨平台 GUI 库。我首先尝试了它。 优点： 纯 Go 编写，上手快。 痛点： 在处理 frpc 实时打印的日志时，Fyne 对中文字符的支持不理想；复杂的列表和表格布局实现起来很痛苦。最终放弃。 第二次尝试：Rust & Tauri Tauri 是当时（也是现在）非常热门的跨平台框架，结合 Rust 的后端性能和 Web 前端技术。 优点： 性能强劲，打包体积小，前端界面开发体验好。 痛点： 我完成了界面设计，但在核心的 frp 控制模块上遇到了巨大的技术难题。Rust 的所有权（Ownership） 和生命周期管理让我头疼不已，始终无法优雅地实现 frp 进程的启动、停止和状态共享。项目卡壳。 三、柳暗花明：Wails v3 成为“天选之子” 在技术选型陷入僵局时，有读者告诉我可以尝试下 wails 3，我关注了 Wails 项目的 v3 版本。虽然现在它还处于 Alpha 阶段，但它宣传的特性完美契合我的所有需求： ...