一、困境与契机：低配服务器、高性能需求与共享经济的思考

我的云服务器配置很“复古”：1 核 CPU、1G 内存、1M 带宽。它完美地满足了我个人博客的需求，直到我需要演示一套视频会议系统。该系统最低要求 2 核 4G。

我的服务器是包年做活动时购买，升级配置成本高昂，而我的本地电脑性能过剩，为了一次演示，我升级我的云服务器，我感觉不值。为了解决这个问题，frp（Fast Reverse Proxy） 成为了我的救星，它允许我将本地高性能服务安全地映射到公网。

新的痛点出现：命令行的局限性

在成功通过命令行 frpc 实现了内网穿透演示后，我发现了一系列生产力问题：

  1. 进程管理难题： 命令行窗口一旦关闭，frpc 进程随之终止，服务中断。这在日常使用中非常不便，因为会经常手误关闭窗口。
  2. 潜在的商业价值： 我有闲置资源服务器，公网 IP 以及域名。对于那些临时需要公网映射的用户来说，这是一个刚需。
  3. 流量变现与服务化： 我有一个小程序并集成了广告。如果能让用户通过看广告来获取临时的 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 阶段，但它宣传的特性完美契合我的所有需求：

  • 极致轻量与原生性能： 生成的可执行文件体积小，内存占用低。
  • 跨平台能力： 一套代码，多端运行，完美契合我的需求。
  • 系统托盘支持： 这是我最核心的需求之一，允许应用在关闭主窗口后，静默在后台运行。
  • Go 生态集成： Wails v3 基于 Go 后端，我可以使用我熟练的 Go 无缝地将 frp 管理，彻底解决 Tauri 中遇到的所有权问题。

说干就干：基于 Wails v3 Alpha 的原型诞生

熟读 Wails v3 Alpha 文档后，我兴奋异常。我将之前在 Fyne 和 Tauri 中已经梳理完善的业务逻辑和流程，迅速迁移到了 Wails v3 框架下。

利用 Go 的便利性，我成功实现了：

  • 系统托盘的后台运行能力。
  • 可视化配置管理（HTTP 映射），动态获取子域名和 frp 多用户 token。
  • 一键启停 frp 客户端进程。

至此，一个功能完善的原型客户端基本完成。它优雅地解决了命令行和之前技术选型带来的所有痛点。

四、展望未来：系列文章预告

在接下来的系列文章中，我将详细拆解这个项目的实现过程：

  1. 详细介绍篇 (一)： 介绍这个开发完成的原型，它目前已经实现的功能，它的界面以及如何使用。
  2. 技术实现篇（二）： 如何在 Wails v3 的 Go 后端启动、管理 frp 进程，并实现日志实时捕获。
  3. 前端交互篇（三）： 使用 JS + Vite 构建美观的前端界面，并实现 Go 与 JS 的双向绑定通信。
  4. 商业模式探索篇（四）： 结合小程序和后端服务，实现“看广告免费使用公网映射”的完整流程。

敬请期待！