1. 为什么是 QUIC？从 TCP 的瓶颈说起 手机在 Wi-Fi 和 4G/5G 之间切换（即“切网”）导致 TCP 连接断开，是移动互联网开发中的经典痛点。 TCP 连接是基于源 IP、源端口、目的 IP、目的端口这“四元组”来标识的。当你从 Wi-Fi 切换到 5G 时，手机的 IP 地址发生了变化，旧的四元组立即失效，TCP 必须重新进行三次握手建立新连接，正在传输的数据（如视频缓冲、下载）就会中断。 QUIC 引入了 Connection ID 的概念。它不依赖于底层 IP 地址。只要 CID 不变，即便你的 IP 从 A 变成了 B，服务端依然能通过 CID 认出：“噢，你还是刚才那个客户端！”。这样对于业务层完全无感知，数据传输无缝继续。这就是所谓的 “连接迁移 (Connection Migration)”。 除了切网，QUIC 在弱网（丢包率高、延迟高）下更强的原因在于： 改进的拥塞控制： QUIC 在应用层实现，可以更激进地进行丢包恢复。 无队头阻塞： 在 TCP 中，丢一个包全家等死；在 QUIC 中，你刷朋友圈的图丢了一个包，不会影响你接收聊天消息的流。 2. go 库quic-go 简介 这是Go的库，在 Go 语言世界里，quic-go 是事实上的标准实现。它不仅完整实现了 IETF QUIC 协议，还提供了类标准库 net 的简洁接口。 Connection (连接)： 代表两个端点之间的 UDP 隧道。 Stream (流)： 连接内部的逻辑通道，双向且独立。 3. 证书准备：使用 OpenSSL 生成 Ed25519 证书 为了极致的性能与安全，弃用了传统的 RSA，选择 Ed25519 算法。它的签名速度更快，密钥更短。 ...

我日常涉及 Hugo 博客发布、客户端打包、Nginx 运维等多种重复性脚本。每次都要 SSH 连服务器并执行命令，操作链过长，也不方便，特别是在身边没有电脑的情况。所以我就想构建一个通用的执行引擎，通过小程序远程触发，且具备零前端修改的扩展能力。 系统架构设计 为了实现“明天增加脚本，小程序不发版”的目标，采用了“配置驱动” 模式。即“配置在云端，指令在指尖”。通过将业务逻辑（脚本路径与名称）完全从前端小程序中解耦，实现一套代码支持无限扩展的运维能力。 核心流程 后端 (Go)：维护一个脚本配置列表（数据库或配置文件）。 前端 (小程序)：启动时请求后端接口，拉取可用脚本列表。 触发：使用时选择脚本名称，点击执行。 鉴权：后端校验小程序 OpenID，仅允许本人指令生效。 技术实现 系统分为三层，确保安全性与扩展性的统一： 配置层 (Go Config)：在服务器端定义脚本的 ID、名称和实际路径。 鉴权层 (WeChat Auth)：利用微信小程序 OpenID 建立强一致性的身份白名单。 展示层 (Mini Program UI)：动态拉取后端配置，仅负责“展示列表”与“触发指令”。 技术实现方案 A. 后端：动态脚本引擎 (Go) 后端不再硬编码脚本路径，而是定义一个结构体： // 脚本任务定义 type ScriptTask struct { ID string `json:"id"` // 前端传递的任务标识 Name string `json:"name"` // 小程序界面显示的文字 Command string `json:"-"` // 实际执行的脚本路径 (对前端保密) } // 示例配置（可存放在 JSON 文件或数据库中） var tasks = []ScriptTask{ {ID: "hugo-post", Name: "发布 Hugo 文章", Command: "/scripts/deploy_hugo.sh"}, {ID: "build-client", Name: "构建客户端", Command: "/scripts/build_mole_go.sh"}, {ID: "nginx-restart", Name: "重启 Nginx 服务", Command: "systemctl restart nginx"}, } 对外接口定义： ...

我使用go写了一个http转WebSocket服务，这是一个命令行程序，双击可以直接运行，今天，有个新的需求，需要将这个命令行程序转为dll，然后供第三方使用。 1，改造程序 这个命令行程序很小，核心逻辑就是启动了一个HTTP服务，然后接收连接，然后通过WebSocket将内容转发出去。所以，在调整为dll时，仅仅需要导出两个函数即可。 1，StartServer，启动http服务，监听端口地址。因为不能阻塞，所以需要在监听服务时使用go方法启动一个携程。 2，StopServer，关闭http服务，需要提供给第三方，当它关闭时，需要调用它，释放监听地址等资源。 下面开始改造代码： package main import "C" // 必须导入 C 包 import ( // ... 原有导入 ... ) // 保持原有的全局变量和函数逻辑 (例如transDataGet, connWs 等) // 需要注意下面的//export这中间不能有空格，否则无法导出头文件 //export StartServer func StartServer() { // 将原本 main 函数里的逻辑放在这里 gin.SetMode(gin.ReleaseMode) r := gin.New() // ... 注册路由 ... r.Run("127.0.0.1:9988") } // 必须保留一个空的 main 函数 func main() {} // 其它参考StartServer，如果需要导出，一定要添加//export 2，编译命令 我是在windows环境，需要安装cgo环境，我安装了Mingw-w64支持C编译环境，执行以下命令： go build -buildmode=c-shared -o trans.dll main.go 执行后会生成trans.h和trans.dll两个文件。 3，验证dll 除了一些可以查看dll的工具外，还可以使用第三方语言进行测试。例如我这里使用Python。 import ctypes import time lib = ctypes.CDLL("./trans.dll") lib.StartServer() print("服务已在后台启动...") time.sleep(10) # 模拟第三方程序运行 lib.StopServer() print("服务已关闭") 4，再次优化代码 当实际测试的时候，我发现它会阻塞调用者，为了解决这个问题，我们需要再次改造程序。将启动服务改为非阻塞模式。将Gin的启动逻辑放入协程，并利用http.Server提供的Shutdown方法来实现优雅退出。 ...

域名过期导致业务中断、流量缺失、品牌受损的案例比比皆是。手动记录域名的到期时间？是否会忘记，漏看？ 我以前曾介绍过，我在微信小程序实现了域名证书监控功能。但是担心隐私，功能限制。这次我带来了豆子域名管家，本地化运行。 经过数月的规划和开发测试，豆子域名管家终于可以使用了。这是一款完全本地运行、支持批量导入管理以及可以企微和钉钉通知的域名证书检测工具。旨在解决域名过期监控难题。 特性 传统方式 豆子域名管家 运行方式 依赖云端服务 纯本地运行，数据不出本地 批量处理 手动逐个查询 一键导入，批量删除 通知渠道 单一（邮件/短信） 钉钉+企微双通道，支持Markdown格式 自定义提醒 固定时间提醒 可配置通知时间，提前预警天数 系统集成 无 系统托盘常驻，后台静默运行 隐私安全 数据上传第三方 域名数据和配置数据存本地 技术架构亮点： 工具基于Wails3框架构建，采用Vue3+NaiveUI前端技术栈，确保界面简洁美观，交互流畅，支持暗黑/浅色两种主题。 本地证书检测引擎，直接调用系统网络库进行TLS检测，无需依赖外部API。 多线程并发处理，使用go的特性批量进行域名检测。 跨平台兼容：支持Windows、macOS、Linux系统。 配置持久化，所有配置本地存储，重启后自动恢复。 支持域名证书检测，域名到期时间检测。 软件运行界面预览： 控制面板 配置页面 基本操作指南： 1，导入域名我们需要把要监控的域名按行录入到txt文档中，可以在软件配置界面下载示例模板，当准备完成后，选择刚才的文件，然后验证。没有问题后，点击确认导入即可。 2，配置机器人目前工具支持钉钉机器人和企业微信机器人，支持Markdown格式消息，可以查点击推送预览效果按钮查看推送效果。当输入机器人配置后，可以验证测试，当收到消息后说明配置成功，点击保存即可。可以同时配置企微和钉钉。这样会同时推送两份通知。 3，配置推送通知策略目前工具扫描调度间隔固定24小时，可以配置通知时间，和告警天数间隔。在通知时间，系统会将当天扫描的结果报表推送到机器人。如果用户更新某些域名证书后，可以在监控面板进行手动刷新。想查看效果，可以把通知时间设置为当前时间加几分钟，当到达时间后，将推送报表。确认无误后，可以调整为真正的推送时间。 4，系统托盘运行当完成域名导入和机器人以及通知策略配置后，可以关闭窗口，工具将自动缩放到系统托盘。如果需要退出，需要右键系统托盘退出。注意，如果退出工具，将不能监控域名，因为这是一个本地工具。所以需要工具长期运行。 5，监控面板监控面板的仪表板显示你的域名配置项统计信息，表格显示监视的域名列表。域名可以搜索，刷新以及删除。域名按照过期、告警、正常顺序排序。请查看最前面域名并及时处理。 工具按照自己的真实需求开发，如果你需要尝试，可以通过下方下载链接。目前仅提供了Windows版本。 https://91demo.top/b011 如果您有任何问题和建议，欢迎反馈和交流。

最近开发完 Mole-go，想给它做个网站用来展示和下载。但我这个后端糙汉子，样式真搞不定，求助 AI 调了半天还是差点意思。最头疼的是，手机端调试得一遍遍输 IP，给朋友演示也得发一串 IP 端口，太不专业了！于是我一顿折腾，搞出了这套方案…… 为了解决这些痛点，我摸索出了一套“黄金组合”：Dufs + Mole-go + FRP + Caddy。这套方案打通了从本地到公网域名的全链路，实现了自动 HTTPS、域名访问以及极致的访问体验。 第一步：构建本地内容基石（Dufs） 一切的起点是本地文件服务。我选择使用 Dufs 作为静态服务器。它极其轻量，支持上传、搜索、打包下载甚至 WebDAV，是我演示 Web 应用或分发安装包的首选。 通过简单的命令，我在本地 5000 端口启动了服务。虽然此时它还被“困”在局域网内，但它为后续的展示提供了稳固的基础。 第二步：突破局域网束缚（FRP 与 Mole-go） 为了让公网流量能精准触达内网，我采用了经典的 FRP 方案，但在客户端层面，我使用了自己开发的 Mole-go。 服务端 (FRP Server)：部署在具备公网 IP 的云服务器上，充当流量中转站。这个服务器配置可以很低，网站服务都在本地电脑，如果本地有数据库，也非常方便调试。 客户端 (Mole-go)：这是我为 FRP 打造的桌面管理客户端。它封装了 frpc 核心，不仅提供了直观的 UI，还通过系统托盘设计彻底解决了“关闭窗口即断连”的痛点。 使用 Mole-go，我可以将本地 5000 端口通过加密隧道安全地映射到云端。它出色的资源管理和连接稳定性，确保了演示过程中即便网络波动，链接依然稳固如初。 第三步：优雅的网关入口（Caddy） 即便流量已到达公网，我也不希望朋友们通过 http://IP:端口 这种生硬的方式访问。我追求的是“域名+HTTPS”的专业感，这不仅是为了美观，更是为了开发环境需求，下次开发公众号等必须 HTTPS 环境时可以拿来就直接使用。 我选择了 Caddy 担任“守门人”。Caddy 的魅力在于其近乎零配置的 自动 HTTPS 功能。看中了它的简单方便，非常符合我的场景。在 Caddyfile 中，我只需写下： example.com { reverse_proxy localhost:7000 # 指向 FRP 映射出的本地端口 } 仅需这一行配置，Caddy 就会自动搞定 SSL 证书的申请与续签。当访问者输入域名时，映入眼帘的是受信任的绿色小锁头，所有的复杂端口逻辑都被完美隐藏。 ...

在实现了使用VOIP客户端拨打8000号码后，播报语音验证码的功能后，我发现了一个最大的缺点，就是这需要用户主动去操作。这对于想使用API集成无法实现。 在思考之后，我决定使用一个可以调用API就呼叫VOIP客户端，当用户接通后，播报语音验证码的功能。当实现这个功能后，它的好处是显而易见的。比如，可以集成到嵌入式，集成到第三方网站。 那么该如何实现它呢？ 一、 系统原理 传统的拨号方案（Dialplan）是静态的，而 ARI 允许我们动态控制。整个“API 触发呼叫并播报”的流程如下： 触发阶段：第三方系统通过 API 向 Go 服务发送呼叫请求（包含目标 ID 和验证码）。 呼叫发起（Originate）：Go 服务调用 Asterisk ARI 的 /channels 接口。此时 Asterisk 会尝试向 PJSIP 终端（或通过中继向手机）发起呼叫。 接通监听（Stasis Start）：一旦用户接起电话，该通道会被移交给一个名为 Stasis 的应用。此时 Go 服务会收到一个“通道已接通”的 WebSocket 事件。 语音合成与播放：Go 服务识别到接通后，调用播报指令（可以播放预录音文件，或对接 TTS 引擎生成的语音流）。 挂断处理：播报完毕后，服务发送挂断指令，释放资源。 二、系统架构 [第三方API] --> [Go 后端服务] --(REST API)--> [Asterisk ARI] | | (WebSocket) (PJSIP/IMS) | | [接通状态回调] <--- [用户终端接听] 三、 核心代码实现 (Golang) 假设你使用了 GitHub 上的 go-ari 库。 1. 初始化 ARI 客户端 import ( "github.com/v5" "github.com/v5/client/native" ) // 连接到 Asterisk ARI cl, err := native.Connect(&native.Options{ Application: "voice-verify", // 必须与 asterisk.conf 配置一致 Username: "admin", Password: "password", URL: "http://localhost:8088/ari", }) 2. 实现呼叫并播报逻辑 这是核心逻辑：接收参数 -> 发起呼叫 -> 监听接通 -> 播放语音。 ...

一、 缘起：为什么需要 mole-go？ 在开发微信公众号、调试支付接口、以及演示本地开发网站时，或由于服务器资源限制需要在本地部署服务时，frp 是不可或缺的内网穿透神器。然而，原生的 frpc 存在几个显著的痛点： 运行隐形性差：必须开启命令行窗口，一旦误关服务即中断。 配置门槛高：新手难以记忆复杂的 .toml 参数。 为了解决这些问题，我开发了 mole-go。它是一个轻量级、跨平台的桌面客户端，旨在实现 frp 的配置、启动与监控一体化。我选择 Wails v3 则是看中了其原生渲染、系统托盘支持、Go 强力后端以及极小的打包体积。 二、 核心架构：Go + Wails v3 的化学反应 mole-go 采用了经典的“UI-Backend-Service”三层架构： Wails UI：负责前端展示，通过事件驱动（Event-Driven）与后端交互。 Go Backend：核心大脑，负责业务逻辑、进程管理与系统级 API 调用。 frpc 二进制：底层服务，通过 Go 的 embed 特性内嵌到二进制文件中。 三、 关键实现细节：从命令行到图形化的进化 前端：从“面条代码”到模块化数据驱动 早期版本中，我直接采用 window.startFrp，window.stopFrp这样的写法，导致代码碎片化严重，以及管理app运行状态不方便。在 mole-go 的正式版中，我将其重构为数据驱动模式，类似Vue，由数据驱动界面： 模块化封装：定义全局 window.App 对象，将数据状态与行为（Methods）统一封装，使代码结构清晰。 动态 UI 组件：针对 HTTP、TCP、UDP 等不同代理模型，不再机械地堆砌 HTML 片段，而是通过逻辑判断实现“按需渲染”，大大精简了 DOM 结构。 后端：全局实例与事件机制 为了保证服务层（Service）能随时与 UI 通信，我设计了一个全局 App 实例，这样可以方便得调用和管理。 状态约定：前后端约定一套状态码，通过 Wails v3 的 Events 机制，后端可以主动向前端推送 frpc 的运行状态、日志等信息。 独立服务层：将 frp 相关逻辑抽离到专门的文件中，通过 Wails 的 Binding 暴露给前端，保持代码的解耦。 系统深度集成 系统托盘（System Tray）：利用 Wails v3 原生的托盘支持，实现了“关闭即隐藏”逻辑。 外部链接调用：使用 wails3自带的 Browser.OpenURL 方法，确保点击文档链接时能正确唤起系统浏览器。 可参考项目源码。 ...

本文将带你从零开始，快速完成基于 Mole 的内网穿透服务部署，包含服务端 (frps) 与桌面客户端 (Mole/frpc) 的配置与排查要点。 📖 核心概念 什么是 FRP？ FRP (Fast Reverse Proxy) 是一款高性能的反向代理/内网穿透工具，它通过在公网服务器和内网客户端之间建立隧道，使外网可以访问内网服务（如 NAS、树莓派、开发环境等）。 什么是 Mole？ Mole 是一款基于 wails3 开发的 FRP 桌面客户端，提供图形化管理界面，简化 frpc 的配置与使用： 告别繁琐命令行 支持系统托盘常驻，防止误关窗口导致中断 支持 HTTP/HTTPS、TCP、UDP 等多种协议 🛠️ 部署前准备 一台拥有公网 IP 的低配云服务器（例如1核1G内存的阿里云、腾讯云等） FRP 服务端（frps）与客户端（frpc）二进制文件，建议使用 FRP Releases 的 v0.65.0 或更高版本 Mole 桌面客户端安装包（对应你操作系统的版本） 基本网络与防火墙管理权限 1. 服务端配置（frps） 在拥有公网IP的云服务器上部署frps服务端： 下载并解压 FRP 服务端（以 Linux 为例） 访问 FRP 的 Releases 页面下载对应版本并解压（示例为 v0.65.0 或更高）。 编写 frps.toml 配置文件（示例） 将以下内容写入 frps.toml，并根据实际需求调整端口与 token： bindPort = 7000 # 客户端连接端口（frpc 连接到此端口） vhostHTTPPort = 8080 # HTTP 映射的公网访问端口（可选） # 建议设置 auth.token 为复杂字符串，防止未授权连接 auth.token = "你的复杂密匙" 启动 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 之后。 ...

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