Wails 3 初体验及在FRP管理客户端中的应用

为什么选择了Wails 3 ? Wails 3 最大的改变在于它不再强绑定于某个特定的前端框架,且引入了多窗口支持和更轻量级的 Runtime。它允许你在不启动主窗口的情况下运行后端服务,这正是我们实现“系统托盘”和“后台演示服务”的基础。 在 v2 中,我们习惯于自动生成的 wailsjs 文件夹。但在 v3 中,这一逻辑被进一步标准化。 当你运行开发指令时,Wails 会扫描你的 Go 结构体方法,并将其映射为前端可以调用的 JavaScript 函数。这个过程在 v3 中被称为 Generate 过程。 Wails 3 通信灵魂 我们在前端调用在后端定义的 HandleConnect 返回自定义结构体,这在 Wails 3 中是前后端通信的灵魂。 在 Wails 3 开发中,最核心的动作就是:后端做功,前端表现。 当你调用 MoleService.HandleConnect() 时,Go 后端会产生一个结果。在本项目中,我们需要同时返回一个 Code(状态码)和一个 Content(数据内容)。 为了实现这一点,我们定义了一个结构体: type Response struct { Code int; Content string } 虽然 Go 内部使用的是结构体,但前端 JavaScript 只能读懂 JSON 对象。Wails 3 内部会自动帮你完成这个“翻译”过程。 但是,如果你想让前端看到的字段名是小写的(例如 res.code 而不是 res.Code),你必须在 Go 结构体定义时加上“注解”。 type Response struct { Code int `json:"code"` Content string `json:"content"` } 记住,所有通过 bindings 调用的 Go 方法,在前端返回的都是一个 Promise 对象。这意味着你必须使用 await 或者 .then() 来接收数据,否则你拿到的将是一个永不开启的“盲盒”。 ...

2025-11-01 · 3 min · Eagle

系列开篇:告别命令行的束缚,我为何选择 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 阶段,但它宣传的特性完美契合我的所有需求: ...

2025-12-01 · 1 min · Eagle

Frp 管理客户端:基于 Wails 3 的 frp 智能管理实战

Mole 是一款基于 Wails 3 开发的跨平台 frp 管理客户端。它不仅解决了 frp 配置繁琐的痛点,更探索出了一种“桌面工具 + 小程序生态”的全新闭环模式。 🌟 核心业务流程 Mole 的核心逻辑在于其自动化配置流与激励机制的融合: 1. 智能激励连接 (One-Click Connect) 当用户点击“一键连接”时,客户端会启动一套自动验证逻辑: 广告触发:系统检查用户当前状态。若未满足条件,则弹出动态窗口显示专属小程序码。 多端协同:用户扫码后进入微信小程序观看激励视频。 自动握手:用户观看完毕后,小程序通过后端指令反馈给 Mole 客户端。 静默取消:客户端接收指令后自动关闭弹窗,进入连接阶段。 2. 云端配置自动下发 Mole 不再需要用户手动编辑复杂的 TOML 文件: 动态获取:从服务器端安全获取分配的随机子域名和 frp 配置 Token。 本地注入:Go 后端自动将配置写入内置的 frpc.toml。 二进制调用:自动调用内嵌的 frpc 核心组件启动服务。 3. 全链路事件反馈 利用 Wails 3 的高效事件机制,实现深度的 UI 反馈: 实时日志:Go 后端捕获 frpc 的标准输出,通过事件流(Events)实时推送到前端页面,用户可以清晰看到连接建立过程。 状态监控:实时反馈隧道运行状态,确保连接稳定性。 🛠️ 板块功能详情 连接控制台:一键启停,集成小程序激励流程。 端口配置页:灵活配置本地服务端口(如 8080, 3000 等),满足开发者调试需求。 实时日志页:直观展示 frp 运行日志,方便故障排查。 帮助中心:详尽的操作指南,降低内网穿透的使用门槛。 技术结缘 (About & Support): 集成优质云服务器推广(为用户提供可靠的 frp 服务端选择)。 扫码直达开发笔记,分享 Wails 3 与 Go 的底层实战。 👀 软件界面概览 1. 软件主界面 ...

2025-12-02 · 1 min · Eagle

技术深挖(一):Wails 3 驱动 frp 客户端的核心实现与避坑指南

在上一篇文章中,我介绍了 Mole 客户端的业务闭环。今天,我们切入代码层面,聊聊基于 Wails 3 的 Go 后端是如何驱动 frp 核心并保证体验平滑的。 一、 Wails 3 项目启动架构 Wails 3 的启动逻辑高度模块化。在 main.go 中,一切从 application.New 开始。 1. 资产集成与服务绑定 首先,我们需要通过 embed.FS 将前端生成物(Vite 构建后的 dist 目录)打包进二进制文件: //go:embed all:frontend/dist var assets embed.FS func main() { app := application.New(application.Options{ Name: "Mole", Description: "Fast Reverse Proxy Manager", Services: []application.Service{ application.NewService(&FrpService{}), // 绑定核心服务 }, Assets: application.AssetOptions{ Handler: application.AssetFileServerFS(assets), }, }) // 创建窗口逻辑... } 关键点: Services 是 Wails 3 的精髓。它是一个切片,支持绑定多个服务实例。每个服务中定义的公开方法,前端都可以通过自动生成的 JS 绑定直接调用。 二、 核心经验总结:从“能跑”到“好用” 在开发 Mole 的原型过程中,我踩了不少坑,总结出以下 5 个核心经验: ...

2025-12-03 · 2 min · Eagle

技术深挖(二):Wails 3 跨端通信——前端如何优雅地“等待”扫码成功?

在完成了 Go 后端的硬核逻辑后,压力来到了前端。Mole 的前端并没有复杂的全家桶,而是回归本质,将精力集中在与 Wails 3 的运行时(Runtime)交互上。 本文将重点拆解:前端如何调用后端服务,以及如何处理“激励视频”这种跨端异步逻辑。 一、 桥梁:引入运行时与绑定 在 Wails 3 中,前端不再需要通过 HTTP 接口访问后端,而是通过自动生成的 Bindings。在 main.js 中,这几行代码是整个应用的灵魂: import { Events, Browser } from "@wailsio/runtime"; // 由 Wails 3 自动生成的绑定代码 import { HandleStopFrp, HandleStartFrp, GetDomainURL, } from "../bindings/mole/MoleService"; Events: 核心组件,用于监听后端的主动推送到前端的消息(如日志、状态变更)。 HandleStartFrp 等: 它们看起来是 JS 函数,但执行时会直接触发 Go 后端对应 Service 的方法。 二、 核心实战:扫码激励的异步闭环 Mole 的核心业务是“看广告换带宽”。这就带来一个挑战:用户点击“连接”后,由于没看广告,流程会中断并弹出小程序码。前端如何知道用户什么时候看完了广告? 拦截与判断 我们不能在前端写 if(adWatched),因为前端代码是透明的。逻辑必须在 Go 后端:如果后端判断该用户需要看广告,HandleStartFrp 会返回特定的状态码(如 2)。 状态机:从“连接中”到“等待验证” 看看这段核心的 connect 逻辑: async function connect() { const hint = document.getElementById("hint"); try { const res = await HandleStartFrp(); // 发起 Go 调用 if (res.code === 1) { // 情况 A: 验证通过,直接分配域名并连接 document.getElementById("subdomain-url").innerText = res.content; setUIConnected(true); addLog("成功连接到服务器", "system"); } else if (res.code === 2) { // 情况 B: 触发激励逻辑,弹出小程序码 showAdModal(res.content); // res.content 包含小程序码 Base64 或 URL addLog("请扫码完成验证后继续", "info"); // 【关键】注册一次性监听事件,等待后端“发令枪” const unsubscribe = Events.On("ad-status", (data) => { closeAdModal(); // 关闭弹窗 unsubscribe(); // 销毁监听,防止重复触发 if (data.status === "done") { addLog("验证成功,正在连接...", "system"); connect(); // 再次发起连接请求,此时后端将通过验证 } else { // 处理异常(如超时、未看完) hint.innerText = data.message; hint.classList.add("error-shake"); addLog(`验证未完成: ${data.message}`, "error"); setUIConnected(false); } }); } } catch (err) { setUIConnected(false); } } 三、 为什么这样设计?(经验总结) 安全性(Security First): 连接逻辑的“入场券”完全由 Go 后端控制。前端只是一个 UI 展示层,即便用户强行修改 JS 调用 connect(),如果后端没有收到广告系统的回调信号,依然不会分配 frp 配置。 订阅-发布模式(Events): 使用 Events.On 而不是轮询(Polling)。当用户在手机上看完广告,后端 API 收到微信的回调后,会通过 app.Emit(“ad-status”, …) 通知前端。这种实时性让用户体验非常丝滑——手机看完,电脑屏幕上的弹窗瞬间自动消失并连接。 UI 细节:单页面布局(Zero-Config UI): 由于 Mole 的界面追求极致精简,所有的 CSS 样式、HTML 布局和 JS 逻辑都高度集成在 index.html 和 main.js 中。对于这类工具软件,减少资源加载链比追求组件化更重要。 四、 结语 前端在 Wails 3 项目中扮演的是 “状态反馈器” 的角色。通过 Bindings 调用 Go 方法,通过 Events 监听实时动态。 ...

2025-12-04 · 2 min · Eagle

商业模式探索与反思:从“广告换带宽”到“技术留下印记”

开发 Mole 客户端的初衷之一,是希望探索一条个人开发者工具变现的路径。在技术实现之外,商业模式的探索同样占据了我大量精力。 一、 “广告换带宽”:一个看似完美的闭环 我最初的想法是利用自己的 3M 带宽服务器,结合微信小程序的广告生态,实现一个“共享经济”的模式: 用户痛点: 临时需要公网 IP 、域名和稳定带宽进行本地调试。 我的资源: 闲置的服务器和域名资源。 解决方案: 用户在 Mole 客户端点击“连接”时,触发小程序激励广告。看完广告后,后端 API 自动为用户分配一个临时的、随机的子域名,并下发 frp 配置 Token。 这种 “桌面工具 + 小程序广告” 的模式,避开了复杂的桌面端支付系统,利用了微信成熟的广告体系。 二、 巨大的合规风险:理想照进现实的冷水 当我准备将这个服务正式上线时,我意识到一个致命的风险:内容合规性。 frp 是一个中立的工具,但它提供的“内网穿透”能力具有双面性。如果用户利用我的服务器进行不法活动(如诈骗、传播违规内容),作为服务器的所有者,域名备案的所有者,我将承担直接的法律责任。服务器和域名随时可能被封,甚至可能面临法律风险。 对于个人开发者而言,这种风险是不可承受的。 第一次变通:服务降级 为了规避风险,我做出了一个艰难的决定:放弃动态配置。 我将客户端锁定为只能穿透由我指定的、本地启动的特定服务(例如一个我开发的本地 Web 服务器)。这样我能控制内容源,降低风险。 但这导致了项目核心吸引力的丧失。用户使用 frp 是为了灵活性,锁定端口后,这个工具对懂技术的开发者来说毫无吸引力。项目陷入僵局。 三、 模式转型:从“服务型”到“纯工具型”的转变 既然提供“带宽服务”行不通,我决定回归“纯工具”本质。但我依然希望能产生收益。赞赏功能(Donation)是一个选项,但在竞争激烈的 frp GUI 市场,我的优势不大。 第二次变通:价值输出与技术写作 我找到了一个新的平衡点:将开发过程本身作为内容输出。 我决定将项目坚持写完,并将整个开发过程、技术难点、踩坑经验整理成系列文章,发布到我的个人网站上。 为什么选择网站(Web)而不是小程序? 内容呈现: Markdown 在 Web 上的渲染效果和代码块展示能力远超小程序。 流量与受众: frp 是一个全球流行的项目。网站面向全球用户(不仅限于微信生态),潜在受众更广。 变现方式: 通过网站流量联盟(如 Google AdSense)可以实现广告收益,风险远低于“流量中转服务”。 四、 结语:留下我的印记 Mole 项目的商业化之路虽然坎坷,但其衍生的价值却超出了我的预期。我不仅熟练掌握了 Wails 3、Go 进程管理、跨端通信等技术栈,还找到了一个可持续发展的方向。 ...

2025-12-05 · 1 min · Eagle

Frp 管理幕后功臣:frps 服务端的多用户鉴权与泛域名自动化

演示版中还有一个极其重要的环节没有交代:服务端(frps)的架构设计。 如果说 Mole 客户端是用户看到的“门脸”,那么服务端就是支撑多用户安全、有序运行的“大脑”。即便在未来的纯工具版中不再强制使用我的服务器,但这套多用户鉴权与动态域名的方案,依然值得每一位开发者备忘。 一、 fp-multiuser:实现多用户隔离的关键 在服务型工具中,不可能让所有用户共享一个 Token,否则无法追踪流量,也无法实现精准的权限控制。我选择了 frp 官方推荐的插件方案:fp-multiuser。 1. 核心逻辑:基于 OpLogin 事件的鉴权 fp-multiuser 实际上是一个基于 HTTP 协议的外部插件。它的精妙之处在于:当 frpc 尝试连接 frps 时,插件会拦截相关事件。 在我的实现中,我重点使用了 OpLogin 事件: 分配 Token:当用户通过 Mole 客户端(或小程序激励后)请求连接时,后端 API 会动态生成一个唯一的 Token 并下发给客户端。 校验映射:当 frpc 发起登录,fp-multiuser 插件会接收到这个 Token。插件通过查表或调用我的管理接口,确认该 Token 是否合法、对应哪个子域名。 唯一映射:这样就确保了 A 用户只能使用 A 子域名,彻底解决了多用户环境下域名冲突和越权访问的问题。 二、 泛域名证书:让每个子域名都拥有 HTTPS 演示版支持用户通过 HTTPS 访问本地服务。面对随时可能生成的成百上千个二级域名(如 user1.example.com, user2.example.com),手动配置证书显然是不现实的。 1. 泛域名证书(Wildcard Certificate) 我使用了 Let’s Encrypt 的泛域名证书。 申请方式:通过 DNS-01 验证方式(利用 Certbot 或 acme.sh)申请 *.example.com 的证书。 优势:一个 .pem 文件即可覆盖所有二级域名,无需为每个新用户重新申请。 2. Nginx 反向代理配置 在服务端,我并没有让 frps 直接监听 443 端口,而是将其置于 Nginx 之后。 ...

2025-12-06 · 1 min · Eagle

回归初心:从演示版到公版,打造最纯粹的 frp 桌面管理工具

随着“小程序激励演示版”的完成,我不仅验证了 Wails 3 的可靠性,也理清了内网穿透在实际应用中的边界。 今天,我决定开启 Mole 客户端的新阶段:开发一个完全去商业化的“公版”frp 管理工具。 这一次,不再有广告,不再有限制,只有极致的配置体验和对 frp 协议的深度支持。 一、 减法:去掉枷锁,回归纯粹 在之前的演示版中,为了跑通“看广告换带宽”的逻辑,我给工具加了很多业务代码。在新的公版计划中,我做的第一件事就是**“大扫除”**: 移除激励系统:彻底删掉小程序码弹窗、后端握手逻辑和广告状态监听。 轻量化内核: UI 界面将变得更加清爽,让用户专注于配置本身。 零服务依赖:不再强制连接我的私有服务器,用户可以自由添加任何公网 frps 节点。 二、 加法:全协议支持与配置进化 frp 的强大之处在于其灵活的协议转发。之前的版本为了简化演示只支持 HTTP,但在公版中,我将补齐这些核心拼图: 1. 从 HTTP 到 TCP/UDP 开发者不仅需要穿透网页,更多时候需要穿透 SSH (22)、数据库 (3306) 甚至 游戏服务器 (UDP)。 新特性:配置页面将新增协议切换选项,动态支持 TCP 和 UDP 端口映射。 交互优化:针对不同协议,UI 会自动切换配置项(如 HTTP 需要填写域名,而 TCP 只需填端口)。 2. HTTPS 的优雅实现 虽然 frpc 本身可以处理 SSL,但主流做法依然是在服务器端使用 Nginx/Caddy 进行反向代理。 方案升级:Mole 将内置一套“最佳实践文档”。在用户配置 HTTPS 映射时,客户端会引导用户如何在服务端配置 Nginx,并给出生成的示例配置代码。 3. 配置文件的“可视化”与“透明化” 公版将允许用户直接查看生成的 frpc.toml。 你可以在 UI 界面通过表单操作,也可以一键切换到代码模式手动微调。这种“双模运行”能同时满足新手和老鸟的需求。 三、 稳定性:我自己的“日用级”保障 在开发演示版的这段时间里,Mole 实际上已经成为了我工作流程的一部分。 ...

2026-01-01 · 1 min · Eagle