标签 go 下的文章

转载：公众号[星纬智联技术],推荐中转站： https://nicecode.cc/
AI Agent Gateway 赛道的现状：
2026 年初，AI Agent 领域最火的项目非 OpenClaw 莫属。这个前身为 Clawdbot 🦞（后改名 Moltbot ，最终定名 OpenClaw ）的项目，在 GitHub 上已经积累了超过 17 万 Star 。它的核心理念很直接：给 LLM 一双"手"，让 AI 能操作你的本地系统——执行命令、读写文件、控制浏览器。OpenClaw 的架构确实强大：
• Gateway + Pi Agent：Gateway 是 Node.js WebSocket 服务（默认绑 ws://127.0.0.1:18789 ），内嵌 Pi （ Mario Zechner 写的开源 Coding Agent ）通过 JSON-RPC over stdio 做推理和工具调用
• 多模型支持：通过 Pi 的统一 LLM API 接 Anthropic 、OpenAI 、Google 、Ollama 等多家 Provider
• 支持 WhatsApp 、Telegram 、Discord 、iMessage 、Slack 、Signal 等消息通道• 沙箱模式、设备配对审批、加密凭据存储
但它也有明显的代价：43 万行 TypeScript 代码，Node.js 运行时，以及相当复杂的依赖链。
对于只想自托管一个 AI 助手的个人开发者来说，这个体量太重了。myclaw 想做的事情很简单——用 Go 写一个够用的轻量替代。
myclaw 是什么：
myclaw 是一个 Go 编写的自托管 AI Agent Gateway 。设计目标三条：
1. 轻量：核心代码约 2000 行，单二进制部署，无运行时依赖
2. 实用：覆盖日常场景——Telegram 和飞书双通道、定时任务、记忆持久化
3. 可扩展：模块化架构，Channel 接口抽象清晰，加新通道写一个 struct 就行
架构上借鉴了 OpenClaw 的 Gateway 模式，但实现上砍掉了所有我用不到的东西。
架构设计：
myclaw 的整体架构可以用一句话概括：消息总线驱动的服务编排。
┌─────────────┐     ┌──────────┐     ┌──────────────┐
│  Telegram    │────▶│          │────▶│   Claude /   │
│  Channel     │     │ Message  │     │   OpenAI     │
└─────────────┘     │   Bus    │     │   Agent      │
                    │          │     └──────┬───────┘
┌─────────────┐     │          │            │
│  Feishu      │────▶│          │◀───────────┘
│  Channel     │     └──────────┘
└─────────────┘          │
                         ▼
┌─────────────┐     ┌──────────┐
│  Cron        │     │  Memory  │
│  Service     │     │  System  │
└─────────────┘     └──────────┘
       │
┌─────────────┐
│  Heartbeat   │
│  Service     │
└─────────────┘
核心组件包括：
1. Message Bus （消息总线）
消息总线是 myclaw 的中枢。两种消息类型：
• InboundMessage：从通道流入，携带 Channel 、SenderID 、ChatID 、Content 、Timestamp 等字段
• OutboundMessage：从 Agent 流出，携带 Channel 、ChatID 、Content 、ReplyTo 等字段
通过 Pub/Sub 模式（ SubscribeOutbound / DispatchOutbound ），各服务之间实现松耦合的事件路由。缓冲区默认 100 条消息，Goroutine 安全。
2. Gateway （网关编排器）
Gateway 是顶层编排器，负责：
• 组装系统 Prompt （从 AGENTS.md + SOUL.md + 记忆上下文拼接）
• 处理入站消息，调用 Agent 运行时（支持 Anthropic 和 OpenAI 两种 Provider ）
• 将 Agent 输出路由到对应的消息通道
• 处理 SIGINT / SIGTERM 优雅关闭
Provider 切换的逻辑很直接——配置里 provider.type 写 openai 就走 OpenAI ，其他情况默认 Anthropic 。不搞什么抽象工厂，一个 switch 解决。
3. Channel （消息通道）
Channel 接口定义了四个方法：Name()、Start()、Stop()、Send()。目前实现了两个通道：
Telegram 通道：
• 基于 telegram-bot-api/v5 长轮询
• Markdown → Telegram HTML 格式转换
• 消息分片（ 4096 字符限制）
• 发送者白名单过滤
• 代理配置支持（方便国内网络环境）
飞书通道：
• Webhook 模式，启动一个 HTTP Server 监听 /feishu/webhook （默认端口 9876 ）
• Tenant Access Token 管理，带缓存和双重检查锁
• URL Verification Challenge 自动应答
• 事件驱动的消息接收（ im.message.receive_v1 ）
• 发送者白名单过滤（基于 open_id ）
• Verification Token 校验
飞书通道需要一个公网可达的 Webhook URL 。本地开发可以用 Cloudflared 临时隧道，生产环境建议配 DNS 。
4. Memory （记忆系统）
记忆系统分为两层：
• 长期记忆（ MEMORY.md ）：持久化的知识库
• 每日日记（ YYYY-MM-DD.md ）：按日期归档的交互记录
提供 ReadLongTerm()、WriteLongTerm()、ReadToday()、AppendToday() 和 GetRecentMemories(days) 方法。默认取最近 7 天的日记，和长期记忆一起组装进 LLM 的系统 Prompt 。
文件就是 Markdown ，想手动改也行。
5. Cron （定时任务）
支持三种调度模式：
• cron：标准 Cron 表达式（基于 robfig/cron/v3 ）
• every：固定间隔（毫秒级）
• at：一次性定时执行
任务持久化为 JSON （存在 ~/.myclaw/data/cron/jobs.json ），支持状态追踪（ LastRunAtMs 、LastStatus 、LastError ）和执行后自动删除。任务的执行结果可以通过 deliver 字段指定是否推送到某个消息通道。
6. Heartbeat （心跳服务）
定期读取 HEARTBEAT.md 文件内容，触发 Agent 处理。Agent 返回 HEARTBEAT_OK 表示无需进一步操作。默认间隔 30 分钟，适合做周期性自检或主动提醒。
为什么用 Go:
选 Go 不是为了赶时髦，是几个实际的考量：
1. 单二进制部署：go build 产出一个可执行文件，不需要 Node.js 运行时或 Python 虚拟环境。scp 到服务器直接跑
2. 并发原语：Goroutine + Channel 天然适合消息总线架构。每个通道、每个定时任务、Webhook Server 都是独立的 Goroutine ，代码写起来比 async/await 回调链清爽
3. 内存占用：Go 运行时的内存开销远低于 Node.js / Python ，一个长期驻留的 Gateway 进程，这点差别会累积
4. 交叉编译：GOOS=linux GOARCH=arm64 go build 一行命令编译到任意平台
快速开始:
安装
go install github.com/stellarlinkco/myclaw/cmd/myclaw@latest
初始化
myclaw onboard
这会在 ~/.myclaw/ 下创建配置文件和工作空间：
~/.myclaw/
├── config.json          # 主配置
├── workspace/
│   ├── AGENTS.md        # Agent 角色定义
│   ├── SOUL.md          # 人格特质
│   ├── HEARTBEAT.md     # 心跳任务提示词
│   └── memory/
│       └── MEMORY.md    # 长期记忆
└── data/
    └── cron/
        └── jobs.json    # 定时任务持久化
配置
编辑 ~/.myclaw/config.json：
{
  "agent": {
    "model": "claude-sonnet-4-5-20250929",
    "maxTokens": 8192,
    "temperature": 0.7,
    "maxToolIterations": 20
  },
  "provider": {
    "type": "anthropic",
    "apiKey": "sk-ant-..."
  },
  "channels": {
    "telegram": {
      "enabled": true,
      "token": "your-bot-token",
      "allowFrom": ["123456789"],
      "proxy": ""
    },
    "feishu": {
      "enabled": true,
      "appId": "cli_xxx",
      "appSecret": "xxx",
      "verificationToken": "xxx",
      "port": 9876,
      "allowFrom": ["ou_xxx"]
    }
  },
  "gateway": {
    "host": "0.0.0.0",
    "port": 18790
  }
}
想用 OpenAI 兼容的 API ？把 provider.type 改成 "openai"，填上对应的 Key 和 Base URL 就行。
也支持环境变量覆盖：
环境变量 用途
MYCLAW_API_KEY / ANTHROPIC_API_KEY Anthropic API Key
OPENAI_API_KEY OpenAI API Key （自动切换 Provider ）
MYCLAW_BASE_URL / ANTHROPIC_BASE_URL API 地址（可接自定义 Endpoint ）
MYCLAW_TELEGRAM_TOKEN Telegram Bot Token
MYCLAW_FEISHU_APP_ID 飞书 App ID
MYCLAW_FEISHU_APP_SECRET 飞书 App Secret
一个细节：如果只设了 OPENAI_API_KEY 而没有配 provider.type ，myclaw 会自动把 Provider 切到 OpenAI 。少一步配置。
运行
# REPL 模式（命令行交互）
myclaw agent

# 单条消息模式
myclaw agent -m "今天的任务清单"

# 完整 Gateway 模式（启动所有服务）
myclaw gateway

# 查看状态
myclaw status
部署
Docker
myclaw 提供了多阶段 Dockerfile （ golang:1.24-alpine 构建，alpine:3.21 运行），编译产物约 10MB
# 构建并启动
docker compose up -d --build

# 如果需要飞书 Webhook 的公网隧道
docker compose --profile tunnel up -d --build
Docker Compose 里包含一个可选的 Cloudflared 隧道服务，通过 --profile tunnel 激活。它会自动把飞书 Webhook 端口暴露到公网，省去自己配 Nginx 反向代理的麻烦。
本地开发也可以直接用 Make:
make tunnel  # 启动 cloudflared 临时隧道
拿到 *.trycloudflare.com 的 URL 后填到飞书开放平台的事件订阅里就行。
裸机部署
# 交叉编译
GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o myclaw ./cmd/myclaw

# 丢到服务器上
scp myclaw user@server:/usr/local/bin/
ssh user@server "myclaw onboard && myclaw gateway"
myclaw 证明了一件事：构建一个实用的 AI Agent Gateway 不需要 43 万行代码。2000 行 Go ，两个消息通道，一套记忆系统，一个 Cron 调度器——日常够用了。当然它也有明显的不足。没有 Web UI ，没有多用户会话隔离，飞书通道目前只支持纯文本消息。如果你的场景需要这些，OpenClaw 或者自己加功能。Go 的单二进制部署和低内存占用让它特别适合丢在一台小 VPS 上长期跑着。如果你认同"能用 2000 行解决的问题不要用 43 万行"这个理念，可以试试。
转载：公众号[星纬智联技术],推荐中转站： https://nicecode.cc/

0.0.0.0 和 127.0.0.1 的区别：为什么改个 IP 就能通了？

刚开始部署服务到服务器（或者在 Docker 容器里跑应用）的时候，很多同学都遇到过这样一个“灵异事件”：

你在服务器上启动了一个 Web 服务，默认配置监听 127.0.0.1:8080。你满怀信心地在服务器本地用 curl 测试，一切正常。但是当你回到自己的电脑，试图通过服务器的公网 IP 访问时，浏览器却转圈转到超时，死活连不上。

经过一番搜索，老鸟告诉你：“把监听地址改成 0.0.0.0 试试。”
你半信半疑地改了，重启服务——通了！

这时候你可能会纳闷：都是代表“本机”，为什么 127.0.0.1 对外不通，0.0.0.0 就可以？它们到底有什么本质区别？

🎯 核心差异：你是在“自言自语”还是“广而告之”？

如果不理解网络接口（Network Interface）的概念，这两个地址看起来确实很像。但实际上，它们的监听范围完全不同。

我们可以用一个简单的比喻：

  • 127.0.0.1（回环地址）：就像你在写日记。

    • 只有你自己能看（本机访问）。
    • 无论你怎么喊，房间外面的人（外部网络）都听不到。

  • 192.168.x.x（局域网 IP）：就像你在会议室里发言。

    • 会议室里的人（同网段机器）能听到。
    • 会议室外面的人听不到。

  • 0.0.0.0（通配符地址）：就像你在全频道广播。

    • 你同时在写日记、在会议室发言、拿着大喇叭对着窗外喊。
    • 所有能连接到你的渠道，都能听到你的声音。
🧠 底层原理：Socket 绑定的艺术

在操作系统层面，服务器程序启动时需要创建一个 Socket 并绑定（Bind）到一个 IP 和端口上。这个“绑定”动作决定了操作系统会将哪些数据包交给这个进程处理。

1. 绑定 127.0.0.1

// 伪代码 (Go 语言)
net.Listen("tcp", "127.0.0.1:8080")

当你绑定 127.0.0.1 时，你告诉操作系统：“只接收目标地址是 127.0.0.1 的数据包。”
因为 127.0.0.1 是一个虚拟的回环接口（Loopback Interface），物理网卡（网线插口/Wi-Fi）根本不认识它。外部请求的数据包目标 IP 是你的局域网 IP（如 192.168.1.5）或公网 IP，操作系统一看：“这包是给 192.168.1.5 的，但那个进程只接 127.0.0.1 的客”，于是直接丢弃或拒绝。

2. 绑定 0.0.0.0 (INADDR_ANY)

// 伪代码 (Go 语言)
net.Listen("tcp", "0.0.0.0:8080")

0.0.0.0 在服务端编程中是一个特殊的通配符，代表“本机的所有 IP 地址”。
当你绑定它时，你告诉操作系统：“只要是发给这台机器的，不管目标 IP 是回环地址、局域网 IP 还是公网 IP，统统交给我处理。”

🔍 图解：数据包是如何“迷路”的

当你监听 0.0.0.0 时：

graph TD
    User[外部用户] -->|访问 192.168.1.5| NIC[物理网卡 eth0<br>192.168.1.5]
    Local[本机客户端] -->|访问 127.0.0.1| LO[回环接口 lo<br>127.0.0.1]
    
    NIC --> App[你的应用<br>监听 0.0.0.0:8080]
    LO --> App
    
    style App fill:#d4edda,stroke:#28a745,stroke-width:2px

当你监听 127.0.0.1 时：

graph TD
    User[外部用户] -->|访问 192.168.1.5| NIC[物理网卡 eth0<br>192.168.1.5]
    Local[本机客户端] -->|访问 127.0.0.1| LO[回环接口 lo<br>127.0.0.1]
    
    NIC -.->|❌ 被操作系统拦截| App[你的应用<br>监听 127.0.0.1:8080]
    LO --> App
    
    style App fill:#f8d7da,stroke:#dc3545,stroke-width:2px
💻 最常见的“坑”：Docker 容器

这是新人最容易踩坑的场景。

错误配置：
你在 Docker 容器里的代码写死监听 127.0.0.1。

// main.go
http.ListenAndServe("127.0.0.1:5000", nil)

后果：
容器启动了，端口映射也做了（-p 5000:5000），但外部就是访问不了。

为什么？
因为 Docker 容器本身就是一个独立的网络环境（Network Namespace）。

  • 容器里的 127.0.0.1 是容器自己的回环接口。
  • Docker 转发流量时，是从宿主机转发到容器的虚拟网卡（eth0）上。
  • 你的应用只监听了容器的“日记本”（lo），却无视了容器的“大门”（eth0）。

正确姿势：
在容器内，必须监听 0.0.0.0。

// main.go
http.ListenAndServe("0.0.0.0:5000", nil)
🛡️ 安全思考：为什么不永远用 0.0.0.0？

既然 0.0.0.0 这么方便，为什么默认配置里（比如 Redis、MongoDB）经常还是 127.0.0.1？

为了安全（Security by Default）。

想象一下，你在公司服务器上装了个 Redis 做缓存，没设密码。

  • 如果你监听 0.0.0.0：所有知道你服务器 IP 的人（包括公网上的黑客扫描器）都能直连你的 Redis，轻松拿走数据或植入挖矿脚本。
  • 如果你监听 127.0.0.1：只有这台服务器上的其他应用（比如你的后端代码）能访问 Redis。外部黑客扫描到了端口也连不上。

最佳实践案例：

  • Nginx/对外 API：监听 0.0.0.0（需要对外服务）。
  • 数据库/Redis/内部 Admin：监听 127.0.0.1（仅限本机微服务调用）。
📝 总结：一张表看懂怎么选
监听地址含义谁能访问？适用场景
127.0.0.1绑定回环接口只有本机的进程数据库、缓存、内部消息队列、本地调试
192.168.x.x绑定特定网卡同一局域网内的机器内网服务、公司内部工具
0.0.0.0绑定所有接口任何人（取决于防火墙）对外 Web 服务器、Docker 容器内部应用
💡 面试官的加分项

下次面试官问这个问题，你可以这样“降维打击”：

“这本质上是 Socket 绑定时 INADDR_LOOPBACK 和 INADDR_ANY 的区别。
127.0.0.1 只能处理回环流量，数据包不走物理网卡；
而 0.0.0.0 是一个通配符，它让操作系统把所有网卡收到的、目标端口匹配的数据包都交给进程。
在云原生环境下，这个区别尤为重要，因为 Pod 或容器默认必须监听 0.0.0.0 才能接收来自 Service 或 Ingress 的流量，否则探针（Probe）会直接失败。”

懂了吗？想让世界听到你的声音，记得拿起广播（0.0.0.0），而不是躲在被窝里写日记（127.0.0.1）！

掘金、思否

⚡️ 别把时间浪费在低效复习上

很多人复习抓不住重点。作为过来人，我分析了100+份大厂面试记录，将 Go/Java/AI 的核心考察点、高频题、易错点 浓缩进了一份 PDF。

不搞虚的，全是干货。

加我微信：wangzhongyang1993，备注 【面经】 免费发你，立即纠正你的复习方向，把时间用在刀刃上。

我发现很多做 2B 私有化交付都用容器镜像的方式来交付制品，因为可打包依赖，避免不同客户的操作系统依赖差异导致的问题。加之目前微服务被滥用（我是觉得滥用了），所以一个产品会有多个容器服务需要安装，这个后端研发团队可能会考虑 k8s 或者 k3s （私有化用这个更加轻量级） .


这就需要做一个 k3s 的离线安装包，目前还没有找到很好用离线安装的开源项目，我用 AI 开发了这个离线安装包 https://github.com/ai-help-me/k3air ， 直接下载解压就能安装，不需要自己到网上找 k3s 的镜像和二进制文件。


用 Go 主要是解决依赖和跨平台的问题，ssh 交互过程也是纯 Go 实现，不依赖服务器上的第三方包。

使用示例：

简单的说，就是可以 ① 推送通知、② 获取在通知页面输入的信息，③ 然后返回给推送发起方 的工具。

特色是极简，这三步只需要一个 http 请求。

  • 通知渠道对接了 Apprise 可以支持上百种；
  • 网络抖动问题通过 request id 查询和 SSE 输出来优化。
  • Go 编写、NPM 安装、MIT 协议开源

最近想搞一搞 agent cli 开发。UI 层面，node 有比较成熟的 ink 方案。

但是看了下 go TUI 相关的解决方案，描述 UI 的方式有点别扭。当然可能是我没找到更好的实现思路。

所以实现了 rego ，取 react + go 的意思。

话不多说，先上代码。

package main

import (
    "fmt"
    "github.com/erweixin/rego"
)

func App(c rego.C) rego.Node {
    count := rego.Use(c, "count", 0)
    
    rego.UseKey(c, func(key rego.Key, r rune) {
        switch r {
        case '+': count.Set(count.Val + 1)
        case '-': count.Set(count.Val - 1)
        case 'q': c.Quit()
        }
    })
    
    return rego.VStack(
        rego.Text("Rego Counter").Bold(),
        rego.Text(fmt.Sprintf("Count: %d", count.Val)),
        rego.Spacer(),
        rego.Text("[+] 增加  [-] 减少  [q] 退出").Dim(),
    )
}

func main() {
    rego.Run(App)
}

运行效果：

Rego Counter
Count: 0

[+] 增加  [-] 减少  [q] 退出

仓库： https://github.com/erweixin/rego

对于多组件的使用可以参考： https://github.com/erweixin/rego/tree/main/examples/gallery

再贴一个 stream 组件的 demo 吧。

https://github.com/erweixin/rego/blob/main/examples/stream/stream_demo.gif

欢迎各位大佬试用、提 Issue 或 PR 。如果你也喜欢这种“在终端写 React”的思路，欢迎给个 Star 支持一下！👏

💥 事故现场
LZ 所在的量化小厂，早期基础设施全是 Python (Asyncio) 一把梭。 跑美股（ US ）的时候相安无事，毕竟 Tick 流是均匀的。 上周策略组说要加 A 股 (CN) 和 外汇 (FX) 做宏观对冲，我就按老套路接了数据源。

结果上线第一天 9:30 就炸了。 监控报警 CPU 100%，接着就是 TCP Recv-Q 堆积，最后直接断连。 策略端收到行情的时候，黄花菜都凉了（延迟 > 500ms ）。

🔍 排查过程 (Post-Mortem)
被 Leader 骂完后，挂了 py-spy 看火焰图，发现两个大坑：

Snapshot 脉冲：A 股跟美股不一样，它是 3 秒一次的全市场快照。几千只股票的数据在同一毫秒涌进来，瞬间流量是平时的几十倍。

GIL + GC 混合双打：

json.loads 是 CPU 密集型，把 GIL 锁死了，网络线程根本抢不到 CPU 读数据。

短时间生成大量 dict 对象，触发 Python 频繁 GC ，Stop-the-world 。

🛠️ 架构重构 (Python -> Go)
为了保住饭碗，连夜决定把 Feed Handler 层剥离出来用 Go 重写。 目标很明确：扛住 A 股脉冲，把数据洗干净，再喂给 Python 策略。

架构逻辑：WebSocket (Unified API) -> Go Channel (Buffer) -> Worker Pool (Sonic Decode) -> Shm/ZMQ

为什么用 Go ？

Goroutine：几 KB 开销，随开随用。

Channel：天然的队列，做 Buffer 抗脉冲神器。

Sonic：字节开源的 JSON 库，带 SIMD 加速，比标准库快 2-3 倍（这个是关键）。

💻 Show me the code
为了解决 协议异构（ A 股 CTP 、美股 FIX 、外汇 MT4 ），我接了个聚合源（ TickDB ），把全市场数据洗成了统一的 JSON 。这样 Go 这边只用维护一个 Struct 。

以下是脱敏后的核心代码，复制可跑（需 go get 依赖）。
package main

import (
"fmt"
"log"
"runtime"
"time"

"github.com/bytedance/sonic" // 字节的库，解析速度吊打 encoding/json
"github.com/gorilla/websocket"
)

// 防爬虫/防风控，URL 拆一下
const (
Host = "api.tickdb.ai"
Path = "/v1/realtime"
// Key 是薅的试用版，大家拿去压测没问题
Key = "?api_key=YOUR_V2EX_KEY"
)

// 内存对齐优化：把同类型字段放一起
type MarketTick struct {
Cmd string `json:"cmd"`
Data struct {
Symbol string `json:"symbol"`
LastPrice string `json:"last_price"` // 价格统一 string ，下游处理精度
Volume string `json:"volume_24h"`
Timestamp int64 `json:"timestamp"` // 8 byte
Market string `json:"market"` // CN/US/HK/FX
} `json:"data"`
}

func main() {
// 1. 跑满多核，别浪费 AWS 的 CPU
runtime.GOMAXPROCS(runtime.NumCPU())

url := "wss://" + Host + Path + Key
conn, _, err := websocket.DefaultDialer.Dial(url, nil)
if err != nil {
log.Fatal("Dial err:", err)
}
defer conn.Close()

// 2. 订阅指令
// 重点测试：A 股(脉冲) + 贵金属(高频) + 美股/港股
subMsg := `{
"cmd": "subscribe",
"data": {
"channel": "ticker",
"symbols": [
"600519.SH", "000001.SZ", // A 股：茅台、平安 (9:30 压力源)
"XAUUSD", "USDJPY", // 外汇：黄金、日元 (高频源)
"NVDA.US", "AAPL.US", // 美股：英伟达
"00700.HK", "09988.HK", // 港股：腾讯
"BTCUSDT" // Crypto：拿来跑 7x24h 稳定性的
]
}
}`
if err := conn.WriteMessage(websocket.TextMessage, []byte(subMsg)); err != nil {
log.Fatal("Sub err:", err)
}
fmt.Println(">>> Go Engine Started...")

// 3. Ring Buffer
// 关键点：8192 的缓冲，专门为了吃下 A 股的瞬间脉冲
dataChan := make(chan []byte, 8192)

// 4. Worker Pool
// 经验值：CPU 核数 * 2
workerNum := runtime.NumCPU() * 2
for i := 0; i < workerNum; i++ {
go worker(i, dataChan)
}

// 5. Producer Loop (IO Bound)
// 只管读，读到就扔 Channel ，绝对不阻塞
for {
_, msg, err := conn.ReadMessage()
if err != nil {
log.Println("Read err:", err)
break
}
dataChan <- msg
}
}

// Consumer (CPU Bound)
func worker(id int, ch <-chan []byte) {
var tick MarketTick
for msg := range ch {
// 用 Sonic 解析，性能起飞
if err := sonic.Unmarshal(msg, &tick); err != nil {
continue
}

if tick.Cmd == "ticker" {
// 简单的监控：全链路延迟
latency := time.Now().UnixMilli() - tick.Data.Timestamp

// 抽样打印
if id == 0 {
fmt.Printf("[%s] %-8s | Price: %s | Lat: %d ms\n",
tick.Data.Market, tick.Data.Symbol, tick.Data.LastPrice, latency)
}
}
}
}

📊 Benchmark (实测数据)
环境：AWS c5.xlarge (4C 8G)，订阅 500 个活跃 Symbol 。 复现了 9:30 A 股开盘 + 非农数据公布 的混合场景。
指标,Python (Asyncio),Go (Sonic + Channel),评价
P99 Latency,480ms+,< 4ms,简直是降维打击
Max Jitter,1.2s (GC Stop),15ms,终于不丢包了
CPU Usage,98% (单核打满),18% (多核均衡),机器都不怎么转
Mem,800MB,60MB,省下来的内存可以多跑个回测

📝 几点心得
术业有专攻：Python 做策略逻辑开发是无敌的，但这种 I/O + CPU 混合密集型的接入层，还是交给 Go/Rust 吧，别头铁。

别造轮子：之前想自己写 CTP 和 FIX 的解析器，写了一周只想跑路。后来切到 TickDB 这种 Unified API ，把脏活外包出去，瞬间清爽了。

Sonic 是神器：如果你的 Go 程序瓶颈在 JSON ，无脑换 bytedance/sonic ，立竿见影。

代码大家随便拿去改，希望能帮到同样被 Python 延迟折磨的兄弟。 (Key 是试用版的，别拿去跑大资金实盘哈，被限流了别找我)

作者：杨易（青风）

在云原生可观测性领域，OpenTelemetry 已经成为事实上的标准。相比于 Java 拥有成熟的字节码增强技术，Go 语言作为静态编译型语言，长期以来缺乏一种成熟、低侵入的自动插桩方案。目前的现有方案主要有：

  1. eBPF：功能强大但主要偏向系统调用层面，对应用层上下文（如 HTTP Header 传播）的处理较为复杂。
  2. 手动埋点：代码改动大，维护成本高，不仅要改业务代码，还得改依赖库的调用方式，显式地在各个关键节点添加 Trace 和 Metrics 逻辑。

为此，阿里云可观测团队和程序语言团队探索了 Go 编译时插桩解决方案，并将其核心能力捐赠给 OpenTelemetry 社区，形成了 opentelemetry-go-compile-instrumentation [ 1] 项目。在和 Datadog、Quesma 等公司的共同努力下，我们发布了首个预览版本 v0.1.0 [ 2] 。

工作原理

自动插桩工具的核心在于利用 Go 编译器的 -toolexec 参数。-toolexec 会拦截 Go 编译命令，替换成我们的插桩工具。这样，在代码被编译之前，我们就有机会对它进行分析和修改。整个过程可以概括为两个阶段：

1. 依赖分析

在编译开始前，工具会分析应用的构建流程（go build -n），识别出项目中使用的第三方库如 net/http, grpc, redis 等。然后，它会自动生成一个文件otel.runtime.go，将对应的 Hook 代码（监测逻辑，后面用 Hook 代码表示）引入到构建依赖中。

2. 代码注入

当编译器处理目标函数时，工具利用 -toolexec 拦截编译，然后修改该目标函数的代码，在函数入口插入一段蹦床代码（Trampoline Code），蹦床代码会跳转到预先写好的 Hook 函数中。

  • 进入函数前（Before）：Hook 记录开始时间，提取上下文信息（如 HTTP Headers），启动 Span。
  • 函数执行：执行原有的业务逻辑。
  • 退出函数后（After）：Hook 捕获返回值或 Panic，结束 Span，记录耗时。

这种方式的优点是零运行时开销（除了必要的监测逻辑执行时间），因为插桩是直接编译进二进制文件的，不需要像 eBPF 那样在内核态和用户态之间切换，也不需要像 Java Agent 那样在启动时加载。

HTTP 插桩示例

让我们通过一个简单的 HTTP 例子来看看它是如何使用的。

package main
import ...
func main() {
    http.HandleFunc("/greet", func(w http.ResponseWriter, r *http.Request) {
        w.Write([ ]byte("Hello, OpenTelemetry!"))
    })
    log.Fatal(http.ListenAndServe(":8080", nil))
}

手动插桩

需要手动引入 OpenTelemetry SDK，手动创建 Tracer，在 Handler 里手动 Start 和 End Span。

package main
import ...
func initTracer() func(context.Context) error { 
  /* ...几十行初始化代码... */
}
func main() {
    // 1. 初始化 Tracer
    shutdown := initTracer()
    defer shutdown(context.Background())
    // 2. 包装 Handler
    handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // 3. 手动提取 Context，开始 Span
        tracer := otel.Tracer("demo-server")
        ctx, span := tracer.Start(r.Context(), "GET /greet")
        // 4. 确保结束 Span
        defer span.End() 
        // 5. 可能还需要手动记录属性
        span.SetAttributes(attribute.String("http.method", "GET"))
        w.Write([]byte("Hello, OpenTelemetry!"))
    })
    // 6. ListenAndServe 也可能需要包装...
    log.Fatal(http.ListenAndServe(":8080", handler))
}

对于成百上千个接口的微服务，这种改造成本是灾难性的。

自动插桩

  1. 下载工具：到 Release 页面 [ 2] 下载
  2. 编译应用：./otel-linux-amd64 go build -o myapp
  3. 配置运行：export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317" export OTEL_SERVICE_NAME="my-app" ./myapp

编译器会默默地将 HTTP 请求的监测逻辑“织入”到应用二进制文件中。配置好 OpenTelemetry 的导出端点（如 Jaeger 或控制台），运行生成的 server。访问 /greet 接口时， Tracing 数据已经自动生成并上报了，包含了请求路径、耗时、状态码等信息。

从商业化到开源

我们在深度实践 eBPF 技术的过程中，虽然认可其强大，但也发现它难以完美处理应用层上下文。更重要的是，我们不断听到用户反馈，大家对繁琐的手动埋点和高昂的维护成本感到困扰。

为了解决这个痛点，我们开始探索 Go 编译时自动插桩方案，将其上线至阿里云可观测 ARMS 产品 [ 3] ，在这片最严苛的“试验田”里不断迭代，逐步演化成一套成熟的解决方案，不仅能实现零代码修改的链路追踪，还扩展支持了丰富的指标统计、Runtime 监控乃至持续剖析等高级功能，甚至还可以通过自定义扩展的功能完成对企业内部 sdk 的埋点 [ 4] 。

image

调用链分析

image

持续剖析

这套方案在电商、短剧、AI 视频、汽车等众多领域客户处得到了成功验证。在看到它为用户带来巨大价值、并验证了其稳定性和可行性后，我们决定将其核心能力贡献给 OpenTelemetry 社区，希望它能成为一个普惠的技术。同时，我们与可观测领域的顶尖厂商 Datadog 协作，共同推进，最终促成了这个官方项目 [ 1] 的诞生。

目前项目处于活跃开发阶段，欢迎大家试用、反馈并参与贡献，共同构建更美好的云原生可观测生态。

相关链接：

[1] OpenTelemetry Go 编译插桩项目

https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation

[2] Release 链接

https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation/releases/tag/v0.1.0

[3] 阿里云 ARMS Go Agent 商业版

https://help.aliyun.com/zh/arms/application-monitoring/user-g...

[4] 自定义扩展

https://help.aliyun.com/zh/arms/application-monitoring/use-ca...

最近因为要在 Mac 和 Android 手机之间传文件，发现目前可以用的工具要么是开源且丑的 whoozle/android-file-transfer-linux ，要么是好久没更新的 Google 开发的 Android File Transfer 。

为什么写这个？

  • Android File Transfer 不支持最新的 ARM 版本，且仍然使用 Intel 转译，体验很差
  • whoozle/android-file-transfer-linux 虽然开源，但界面简陋，而且需要自行编译 ARM 版本，对普通用户很不友好

于是决定自己撸一个开源工具——SwiftMTP 。折腾不到一个月终于能用了 🎉

关于我（先坦白）

我完全不会 Swift 和 GO 的开发，所以目前代码都是 AI 辅助生成的。正因为如此，可能存在 UI 样式异常或其他 bug 。如果你在使用过程中遇到任何问题，请务必及时反馈，我会尽力修复！

主要功能

  • 自动检测连接的 Android 设备（ MTP 模式）
  • 文件浏览，支持文件夹导航
  • 文件下载/上传，支持拖放
  • 支持大文件传输（>4GB ）
  • 批量选择和下载
  • 多语言支持（简中、英语、日语、韩语、俄语、法语、德语）
  • 显示设备存储空间

技术栈

  • 前端：SwiftUI （ MVVM 架构）
  • 后端：Go 1.22 + go-mtpx + libusb-1.0
  • 桥接：CGO （ Swift ↔ C ↔ Go ）

目前已知限制

  • 仅支持 ARM 版本（ Apple 芯片）
  • 要求系统版本在 macOS 26 或更高
  • 仅支持单个设备
  • 暂不支持文件夹上传（单文件上传）
  • 传输速度受 MTP 协议限制
  • UI 可能存在样式异常（因为我不会 Swift 😅）

下载方式

GitHub： https://github.com/wang93wei/SwiftMTP

可以从源码构建，或者直接下载安装包。

注意： 因为没有苹果开发者签名，所以可能需要其他方式方可使用：

如果看到 "SwiftMTP can't be opened because it is from an unidentified developer"，尝试以下方法：

  1. 右键点击应用 → 选择「打开」
  2. 系统设置 → 隐私与安全性 → 允许 SwiftMTP
  3. 或在终端运行：xattr -cr /Applications/SwiftMTP.app

求反馈

  • 你的设备能否正常检测？
  • 传输速度如何？
  • UI 有没有样式问题？
  • 有没有遇到什么 bug ？
  • 有什么功能建议？

项目刚起步，代码写得可能不够优雅，欢迎提 issue 或 PR ！

效果图

💥 事故现场
LZ 所在的量化小厂，早期基础设施全是 Python (Asyncio) 一把梭。 跑美股（ US ）的时候相安无事，毕竟 Tick 流是均匀的。 上周策略组说要加 A 股 (CN) 和 外汇 (FX) 做宏观对冲，我就按老套路接了数据源。

结果上线第一天 9:30 就炸了。 监控报警 CPU 100%，接着就是 TCP Recv-Q 堆积，最后直接断连。 策略端收到行情的时候，黄花菜都凉了（延迟 > 500ms ）。

🔍 排查过程 (Post-Mortem)
被 Leader 骂完后，挂了 py-spy 看火焰图，发现两个大坑：

Snapshot 脉冲：A 股跟美股不一样，它是 3 秒一次的全市场快照。几千只股票的数据在同一毫秒涌进来，瞬间流量是平时的几十倍。

GIL + GC 混合双打：

json.loads 是 CPU 密集型，把 GIL 锁死了，网络线程根本抢不到 CPU 读数据。

短时间生成大量 dict 对象，触发 Python 频繁 GC ，Stop-the-world 。

🛠️ 架构重构 (Python -> Go)
为了保住饭碗，连夜决定把 Feed Handler 层剥离出来用 Go 重写。 目标很明确：扛住 A 股脉冲，把数据洗干净，再喂给 Python 策略。

架构逻辑：WebSocket (Unified API) -> Go Channel (Buffer) -> Worker Pool (Sonic Decode) -> Shm/ZMQ

为什么用 Go ？

Goroutine：几 KB 开销，随开随用。

Channel：天然的队列，做 Buffer 抗脉冲神器。

Sonic：字节开源的 JSON 库，带 SIMD 加速，比标准库快 2-3 倍（这个是关键）。

💻 Show me the code
为了解决 协议异构（ A 股 CTP 、美股 FIX 、外汇 MT4 ），我接了个聚合源（ TickDB ），把全市场数据洗成了统一的 JSON 。这样 Go 这边只用维护一个 Struct 。

以下是脱敏后的核心代码，复制可跑（需 go get 依赖）。
package main

import (
"fmt"
"log"
"runtime"
"time"

"github.com/bytedance/sonic" // 字节的库，解析速度吊打 encoding/json
"github.com/gorilla/websocket"
)

// 防爬虫/防风控，URL 拆一下
const (
Host = "api.tickdb.ai"
Path = "/v1/realtime"
// Key 是薅的试用版，大家拿去压测没问题
Key = "?api_key=YOUR_V2EX_KEY"
)

// 内存对齐优化：把同类型字段放一起
type MarketTick struct {
Cmd string `json:"cmd"`
Data struct {
Symbol string `json:"symbol"`
LastPrice string `json:"last_price"` // 价格统一 string ，下游处理精度
Volume string `json:"volume_24h"`
Timestamp int64 `json:"timestamp"` // 8 byte
Market string `json:"market"` // CN/US/HK/FX
} `json:"data"`
}

func main() {
// 1. 跑满多核，别浪费 AWS 的 CPU
runtime.GOMAXPROCS(runtime.NumCPU())

url := "wss://" + Host + Path + Key
conn, _, err := websocket.DefaultDialer.Dial(url, nil)
if err != nil {
log.Fatal("Dial err:", err)
}
defer conn.Close()

// 2. 订阅指令
// 重点测试：A 股(脉冲) + 贵金属(高频) + 美股/港股
subMsg := `{
"cmd": "subscribe",
"data": {
"channel": "ticker",
"symbols": [
"600519.SH", "000001.SZ", // A 股：茅台、平安 (9:30 压力源)
"XAUUSD", "USDJPY", // 外汇：黄金、日元 (高频源)
"NVDA.US", "AAPL.US", // 美股：英伟达
"00700.HK", "09988.HK", // 港股：腾讯
"BTCUSDT" // Crypto：拿来跑 7x24h 稳定性的
]
}
}`
if err := conn.WriteMessage(websocket.TextMessage, []byte(subMsg)); err != nil {
log.Fatal("Sub err:", err)
}
fmt.Println(">>> Go Engine Started...")

// 3. Ring Buffer
// 关键点：8192 的缓冲，专门为了吃下 A 股的瞬间脉冲
dataChan := make(chan []byte, 8192)

// 4. Worker Pool
// 经验值：CPU 核数 * 2
workerNum := runtime.NumCPU() * 2
for i := 0; i < workerNum; i++ {
go worker(i, dataChan)
}

// 5. Producer Loop (IO Bound)
// 只管读，读到就扔 Channel ，绝对不阻塞
for {
_, msg, err := conn.ReadMessage()
if err != nil {
log.Println("Read err:", err)
break
}
dataChan <- msg
}
}

// Consumer (CPU Bound)
func worker(id int, ch <-chan []byte) {
var tick MarketTick
for msg := range ch {
// 用 Sonic 解析，性能起飞
if err := sonic.Unmarshal(msg, &tick); err != nil {
continue
}

if tick.Cmd == "ticker" {
// 简单的监控：全链路延迟
latency := time.Now().UnixMilli() - tick.Data.Timestamp

// 抽样打印
if id == 0 {
fmt.Printf("[%s] %-8s | Price: %s | Lat: %d ms\n",
tick.Data.Market, tick.Data.Symbol, tick.Data.LastPrice, latency)
}
}
}
}

📊 Benchmark (实测数据)
环境：AWS c5.xlarge (4C 8G)，订阅 500 个活跃 Symbol 。 复现了 9:30 A 股开盘 + 非农数据公布 的混合场景。
指标,Python (Asyncio),Go (Sonic + Channel),评价
P99 Latency,480ms+,< 4ms,简直是降维打击
Max Jitter,1.2s (GC Stop),15ms,终于不丢包了
CPU Usage,98% (单核打满),18% (多核均衡),机器都不怎么转
Mem,800MB,60MB,省下来的内存可以多跑个回测

📝 几点心得
术业有专攻：Python 做策略逻辑开发是无敌的，但这种 I/O + CPU 混合密集型的接入层，还是交给 Go/Rust 吧，别头铁。

别造轮子：之前想自己写 CTP 和 FIX 的解析器，写了一周只想跑路。后来切到 TickDB 这种 Unified API ，把脏活外包出去，瞬间清爽了。

Sonic 是神器：如果你的 Go 程序瓶颈在 JSON ，无脑换 bytedance/sonic ，立竿见影。

代码大家随便拿去改，希望能帮到同样被 Python 延迟折磨的兄弟。 (Key 是试用版的，别拿去跑大资金实盘哈，被限流了别找我)

在 Go 业务开发中，我们经常遇到这样的场景：

  • 环境切换：本地开发用 NATS 或 RabbitMQ 贪图轻快，线上却要接入 Kafka 或 AWS SQS 。
  • 代码耦合：业务逻辑被底层 MQ 的 SDK 对象（如 *rocketmq.Producer）绑定，一旦想换驱动，几乎要重写整个消息发送逻辑。
  • 配置坑多：每个 MQ 的参数设置五花八门，一不小心传错了参数，程序却静默运行，等到上线出事才发现配置没生效。

为了解决这些痛点，我发起了 Unified MQ Broker for Go 项目。它就像是 MQ 领域的 "DBAL"（类似于 SQL 领域的 GORM 或数据库驱动层），让你通过一套 API 就能无缝切换多种消息中间件。

🚀 v0.2.0 重磅更新

经过一段时间的打磨，我们刚刚发布了 v0.2.0 版本。这次更新不只是增加了驱动，更是在“健壮性”和“性能”上做了深度优化：

1. 🛡️ 独创“选项追踪” (Option Tracking)

  • 痛点：如果你给 Kafka 传了一个 SQS 的 DeduplicationID，大部分 SDK 会选择静默忽略。
  • 方案：v0.2.0 引入了审计机制。如果底层适配器没有读取你传入的某个配置项，系统会在连接或发布时发出显式警告。彻底告别因拼写错误或参数误用导致的配置无效。

2. ⚡ 高性能“智能序列化” (Smart Serialization)

  • 优化：针对原始 []byte 和 string 数据实现了零拷贝路径，跳过冗余的 json.Marshal。
  • 战果：压测显示，在高吞吐场景下，序列化性能提升了 5 倍以上（单次操作仅需 ~16ns ）。

3. 🏗️ 延迟绑定 (Late Binding)

  • NewBroker 现在仅做静态配置。
  • 真正的网络 IO 、TCP 建连和 SDK 初始化全部推迟到 Connect() 时执行，方便与依赖注入框架（如 Wire ）集成。

4. 🌐 全平台支持

目前已完美支持：RocketMQ, Kafka, RabbitMQ, NATS, AWS SQS, GCP Pub/Sub。

💻 核心代码预览

无论底层是哪种 MQ ，你的业务代码只需要关心这一套统一逻辑：

import "github.com/qvcloud/broker"

// 切换驱动只需要换一行初始化，业务代码 0 改动
b := rabbitmq.NewBroker(broker.Addrs("amqp://..."))
b.Connect()

// 注入统一的中间件（如 OpenTelemetry 链路追踪）
b.Init(broker.Middleware(otel.Middleware))

// 统一的订阅 API
b.Subscribe("orders.created", func(ctx context.Context, event broker.Event) error {
    fmt.Println("收到订单:", string(event.Message().Body))
    return nil // 返回 nil 自动 Ack ，返回 error 自动 Nack/Retry
})

// 统一的发布 API
b.Publish(context.Background(), "orders.created", &broker.Message{
    Body: []byte(`{"id": 1001}`),
})

传送门

GitHub: https://github.com/qvcloud/broker

  • 核心理念: 接口驱动、高性能、原生支持 OpenTelemetry 。

如果你也深受 MQ 适配之苦，或者想为你的分布式系统寻找一个更规范的通信抽象，欢迎来试用、吐槽或贡献代码！如果你觉得不错，给个 Star 就是最大的支持。 🌟

PHP 用了十年了，也停滞在某个版本很多年了。

最近项目重构，用新的库，一开始用 laravel ，九牛二虎搞起来，感觉好复杂，还慢，就搞了 flightphp ，快十倍，也简单。但是，现在又发现 go ，flightphp 是猎豹，go 就是火箭啊。作为 web api ，也就基本 crud 工作，go 应该能很好的完成。数据库，ai 时代，完全可以用原生 SQL 了。

这次如果重构完成，那就要和 PHP 拜拜了，因为 WEBAPI 如果用 GO ，就没有地方用他了，测试用 PYTHON 大数据用 PYTHON EXCEL 用 PYTHON ，前端用 SVELTEKIT ，其他用 GO

这样子看，PHP 是不是快死了？微服务＋ AI 时代，他没有擅长的技能，各个模块都被其他语言代替？

PHP 用了十年了，也停滞在某个版本很多年了。

最近项目重构，用新的库，一开始用 laravel ，九牛二虎搞起来，感觉好复杂，还慢，就搞了 flightphp ，快十倍，也简单。但是，现在又发现 go ，flightphp 是猎豹，go 就是火箭啊。作为 web api ，也就基本 crud 工作，go 应该能很好的完成。数据库，ai 时代，完全可以用原生 SQL 了。

这次如果重构完成，那就要和 PHP 拜拜了，因为 WEBAPI 如果用 GO ，就没有地方用他了，测试用 PYTHON 大数据用 PYTHON EXCEL 用 PYTHON ，前端用 SVELTEKIT ，其他用 GO

这样子看，PHP 是不是快死了？微服务＋ AI 时代，他没有擅长的技能，各个模块都被其他语言代替？

各位 L 站的佬友们好！

我是本坛萌新，潜水有一段时间了，一直在这个技术氛围浓厚的社区里学习。今天终于鼓起勇气发个贴，分享一个自己最近开发的练手工具，希望各位佬轻喷，也欢迎大家多提宝贵意见！

开发初衷

平时用夸克网盘比较多，但官方客户端的广告和臃肿大家都懂。加上我有自动化整理资源的需求，官方缺少 API 支持。
作为一名开发者，手痒之下就用 Go (Wails) + Vue3 + Element Plus 撸了这个第三方客户端。

目前项目已经打包了 Windows 版本（单文件绿色版），主打一个干净、无广、可编程，发出来分享给有需要的坛友们体验。

[软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端1 [软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端2 [软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端3 [软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端4

界面预览

[软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端5


[软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端6


[软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端7


[软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端8


[软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端9

核心亮点

除了基础的文件管理（上传 / 下载 / 重命名 / 移动等），针对像我这样的 “折腾党”，做了以下增强：

  • 多账户无缝切换：支持同时登录多个账号，一键切换，适合多号党。
  • 内置 API 服务：自带 Swagger 文档的 HTTP API（默认 8080 端口），支持外部程序调用，方便自己写脚本对接网盘。
  • Cookie 过期提醒：支持配置 SMTP 邮件通知，Cookie 快过期时自动发邮件提醒，避免自动任务挂掉。
  • 强大的分享与转存：支持批量转存带密码的链接，自动解析，支持设置分享有效期。

技术栈分享

虽然目前代码还在整理中暂未开源，但还是想和大家交流一下技术选型。
Wails 的方案在 Windows 下表现真的非常不错，利用系统自带的 WebView2，体积比 Electron 小很多，内存占用也低，Go 写后端逻辑也很舒服。

  • Backend: Go (Wails 框架)
  • Frontend: Vue 3 + Element Plus
  • API: 内置 HTTP Server + Swagger

进阶玩法：API 调用

这是我个人最喜欢的功能，开启 API 服务后，你可以直接用 curl 或者 python 操作网盘，做一些自动化的事情：

# 1. 获取文件列表
curl "http://localhost:8080/api/files?folder_id=0" # 2. 一键转存分享链接
curl -X POST http://localhost:8080/api/save \
  -H "Content-Type: application/json" \
  -d '{"share_url": "[https://pan.quark.cn/s/xxx](https://pan.quark.cn/s/xxx)"}'

访问 http://localhost:8080/swagger/ 还能看到完整的接口文档。

📥 下载与安装
目前 Release 页面已上传编译好的 quarkpan.exe，下载解压即可直接运行。

GitHub 发布页: https://github.com/dpyyds/QuarkManager/releases

⚠️ 免责声明
本软件为第三方个人开发工具，仅供学习交流，严禁用于商业用途。

使用第三方客户端可能存在风险，请大家自行评估，后果自负。

如涉及侵权请联系删除。

初来乍到，希望能融入 L 站这个大家庭。如果觉得这个小工具好用，求各位佬去 GitHub 点个 Star 🌟 支持一下，也欢迎在评论区交流 bug 和建议！

📌 转载信息
转载时间：
2026/1/16 12:59:10

RemoteKnown (远程知道了)

本地终端远程行为感知与审计系统

让用户 "清楚知道自己是否、何时、正在被远程控制"，保护隐私安全。

简体中文 | English

【开源】RemoteKnown (远程知道了) 远程控制感知与审计工具1【开源】RemoteKnown (远程知道了) 远程控制感知与审计工具2 【开源】RemoteKnown (远程知道了) 远程控制感知与审计工具3 【开源】RemoteKnown (远程知道了) 远程控制感知与审计工具4

项目简介

远程知道了 是一款能够实时监测本地系统的远程控制状态，识别多种主流远程工具（如 ToDesk, 向日葵，网易 UU 远程，AskLink 远程，远程看看等），并提供桌面通知、飞书 / 钉钉告警以及详细的会话审计记录。

界面预览

主界面状态

安全状态正在被远程
【开源】RemoteKnown (远程知道了) 远程控制感知与审计工具5
【开源】RemoteKnown (远程知道了) 远程控制感知与审计工具6

桌面通知

远程开始告警远程结束通知
【开源】RemoteKnown (远程知道了) 远程控制感知与审计工具7
【开源】RemoteKnown (远程知道了) 远程控制感知与审计工具8

系统托盘

红色告警状态

通知设置

飞书设置钉钉设置
【开源】RemoteKnown (远程知道了) 远程控制感知与审计工具9
【开源】RemoteKnown (远程知道了) 远程控制感知与审计工具10

核心功能

  • 实时感知：多维度信号（进程、窗口、网络端口、Session）综合判定。
  • 多工具支持：
    • ToDesk
    • 向日葵 (Sunlogin)
    • Windows 远程桌面 (RDP)
    • 网易 UU 远程
    • AskLink 远程
    • 远程看看
  • 会话审计：自动记录每次远程控制的开始时间、结束时间、持续时长及判定来源。
  • 多渠道告警：
    • 桌面右下角弹窗通知
    • 系统托盘状态变色（绿色安全，红色警告）
    • 即时通讯软件推送（支持飞书 Webhook、钉钉 Webhook）
  • 隐私优先：所有数据均存储在本地 SQLite 数据库中，不上传任何敏感信息。

快速开始

下载安装

请从以下任一平台下载最新的安装包 (RemoteKnown-Setup-x.x.x.exe) 并安装：

运行

安装完成后，双击桌面图标启动。

  • 程序启动后会自动最小化到系统托盘。
  • 当检测到远程控制时，托盘图标会变红，并弹出提示。
  • 点击托盘图标可打开主界面查看详细状态和历史记录。

编译构建

如果您是开发者，想要自行构建项目，请遵循以下步骤：

环境要求

  • Windows 10/11 (核心检测逻辑依赖 Windows API)
  • Go: 1.21 或更高版本
  • Node.js: 18 或更高版本 (推荐使用 LTS)

构建步骤

我们提供了一键构建脚本，自动处理 Go 后端编译和 Electron 前端打包。

必须以管理员身份运行 CMD 或 PowerShell（解决软链接权限问题）：

# 1. 克隆项目
git clone https://github.com/samwafgo/RemoteKnown.git
cd RemoteKnown

# 2. 运行构建脚本 (会自动安装依赖并打包)
.\build.bat

构建完成后，安装包将生成在 web/dist 目录下。

项目结构

RemoteKnown/
├── build.bat             # 一键构建脚本 (Windows)
├── cmd/                  # Go 程序主入口
├── internal/             # Go 核心业务逻辑
│   ├── detector/         # 远程特征检测引擎
│   ├── server/           # 本地 HTTP API 服务
│   └── storage/          # SQLite 数据库操作
├── web/                  # Electron 前端源码
│   ├── assets/           # 静态资源 (Logo等)
│   ├── index.html        # 主页面
│   └── main.js           # Electron 主进程 (含单实例锁、后端守护)
└── README.md             # 项目文档

参与贡献

欢迎提交 Issue 和 Pull Request！

代码仓库

开源协议

本项目采用 MIT License 开源。

📌 转载信息
原作者：
1g2g
转载时间：
2026/1/16 12:22:02

各位 L 站的佬友们好！

我是本坛萌新，潜水有一段时间了，一直在这个技术氛围浓厚的社区里学习。今天终于鼓起勇气发个贴，分享一个自己最近开发的练手工具，希望各位佬轻喷，也欢迎大家多提宝贵意见！

开发初衷

平时用夸克网盘比较多，但官方客户端的广告和臃肿大家都懂。加上我有自动化整理资源的需求，官方缺少 API 支持。
作为一名开发者，手痒之下就用 Go (Wails) + Vue3 + Element Plus 撸了这个第三方客户端。

目前项目已经打包了 Windows 版本（单文件绿色版），主打一个干净、无广、可编程，发出来分享给有需要的坛友们体验。

[软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端1 [软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端2 [软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端3 [软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端4

界面预览

[软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端5


[软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端6


[软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端7


[软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端8


[软件分享] QuarkManager - 萌新首作，基于 Wails + Vue3 打造的夸克网盘桌面端9

核心亮点

除了基础的文件管理（上传 / 下载 / 重命名 / 移动等），针对像我这样的 “折腾党”，做了以下增强：

  • 多账户无缝切换：支持同时登录多个账号，一键切换，适合多号党。
  • 内置 API 服务：自带 Swagger 文档的 HTTP API（默认 8080 端口），支持外部程序调用，方便自己写脚本对接网盘。
  • Cookie 过期提醒：支持配置 SMTP 邮件通知，Cookie 快过期时自动发邮件提醒，避免自动任务挂掉。
  • 强大的分享与转存：支持批量转存带密码的链接，自动解析，支持设置分享有效期。

技术栈分享

虽然目前代码还在整理中暂未开源，但还是想和大家交流一下技术选型。
Wails 的方案在 Windows 下表现真的非常不错，利用系统自带的 WebView2，体积比 Electron 小很多，内存占用也低，Go 写后端逻辑也很舒服。

  • Backend: Go (Wails 框架)
  • Frontend: Vue 3 + Element Plus
  • API: 内置 HTTP Server + Swagger

进阶玩法：API 调用

这是我个人最喜欢的功能，开启 API 服务后，你可以直接用 curl 或者 python 操作网盘，做一些自动化的事情：

# 1. 获取文件列表
curl "http://localhost:8080/api/files?folder_id=0" # 2. 一键转存分享链接
curl -X POST http://localhost:8080/api/save \
  -H "Content-Type: application/json" \
  -d '{"share_url": "[https://pan.quark.cn/s/xxx](https://pan.quark.cn/s/xxx)"}'

访问 http://localhost:8080/swagger/ 还能看到完整的接口文档。

📥 下载与安装
目前 Release 页面已上传编译好的 quarkpan.exe，下载解压即可直接运行。

GitHub 发布页: https://github.com/dpyyds/QuarkManager/releases

⚠️ 免责声明
本软件为第三方个人开发工具，仅供学习交流，严禁用于商业用途。

使用第三方客户端可能存在风险，请大家自行评估，后果自负。

如涉及侵权请联系删除。

初来乍到，希望能融入 L 站这个大家庭。如果觉得这个小工具好用，求各位佬去 GitHub 点个 Star 🌟 支持一下，也欢迎在评论区交流 bug 和建议！

📌 转载信息
转载时间：
2026/1/15 18:15:48

PHP 用了十年了，也停滞在某个版本很多年了。

最近项目重构，用新的库，一开始用 laravel ，九牛二虎搞起来，感觉好复杂，还慢，就搞了 flightphp ，快十倍，也简单。但是，现在又发现 go ，flightphp 是猎豹，go 就是火箭啊。作为 web api ，也就基本 crud 工作，go 应该能很好的完成。数据库，ai 时代，完全可以用原生 SQL 了。

这次如果重构完成，那就要和 PHP 拜拜了，因为 WEBAPI 如果用 GO ，就没有地方用他了，测试用 PYTHON 大数据用 PYTHON EXCEL 用 PYTHON ，前端用 SVELTEKIT ，其他用 GO

这样子看，PHP 是不是快死了？微服务＋ AI 时代，他没有擅长的技能，各个模块都被其他语言代替？

最近写一个关于 Proxmox VE 多集群开源项目，第一次整这玩意，各位观众老爷们给评一评，国内会有人用？不知道有木有要入坑欢迎大家一起交流交流

项目简介

一个开源的 Proxmox VE 多集群 Web 管理平台，解决多集群运维的痛点。

解决什么问题

如果你运维多个 PVE 集群，应该深有体会：

  • 在多个 Web 界面之间频繁切换
  • 手动同步虚拟机模板费时费力
  • 缺少跨集群的资源全局视图

PveSphere 提供统一的控制面板，让你从单一界面管理所有集群。

核心功能

  • 多集群统一管理
  • 虚拟机生命周期管理（创建、迁移、备份等）
  • 自动化模板同步
  • 实时资源监控
  • VNC 控制台访问

快速体验

git clone https://github.com/pvesphere/pvesphere.git
cd pvesphere
make docker-compose-build

默认账号：[email protected] / Ab123456

访问： http://localhost:8080

技术栈

  • 后端：Go + Nunu 框架
  • 前端：Vue + vue-pure-admin
  • 部署：Docker Compose

适用场景

✅ 管理多个 PVE 集群
✅ 需要自动化模板分发
✅ 需要集中监控和管理

❌ 单集群用户（原生界面可能更合适）

项目地址

联系方式

博客原文

https://www.ljohn.cn/posts/91d244ba/

欢迎试用和反馈 🙌

用过 TeslaMate 的车友应该都知道，它功能很强大，但有个问题：后端是 Elixir 写的，代码看不懂。我想做的事情很简单：换掉 Grafana 面板，做一个更现代化的前端。结果打开 TeslaMate 源码一看 —— 完全不知道从哪下手。所以我用 Go 重写了整个后端。

tesgazer 是什么

一个可读、可改、可扩展的 Tesla 数据记录器后端。

核心能力

  • 行程记录（轨迹、距离、能耗）

  • 充电记录（功率曲线、费用计算）

  • 智能休眠（不吸血，车辆该睡就睡）

  • Streaming API（亚秒级唤醒检测）

  • 代码你看得懂

为什么开源后端，前端还没开源？

因为前端代码能力为 0，试图用 cc/gemini3pro 写，但是效果都不太理想，所以我希望社区一起参与，后端 API 文档已经写好了，欢迎来造轮子。

链接

📌 转载信息
转载时间：
2026/1/7 19:02:53

简介

AutoCFT（Automate Cloudflare Tunnel）是一个简化 Cloudflare Tunnels 配置和运维的开源工具，适合 Self-hosted 的 Docker 环境，主要提供配置自动化更新，避免频繁登录 Zero Trust Dashboard 进行更新；通过 Docker 或 Docker compose 部署，便于管理；采用 Go 实现，轻量化结构；中英文文档完整。

项目地址：GitHub - cloudfogtech/autocft: A tool for Docker Compose to automatically update access endpoints to Cloudflare Tunnel.

官方文档：https://autocft.cloudfogtech.ltd/

部署与使用

要使用 AutoCFT，基本上默认已经有 Docker 环境了，下面的教程将直接基于 Docker 环境开始。

AutoCFT 部署

services: autocft:  cloudfogtech/autocft:latest container_name: autocft restart: always environment: - AUTOCFT_CF_API_TOKEN=<AUTOCFT_CF_API_TOKEN> - AUTOCFT_CF_ACCOUNT_ID=<AUTOCFT_CF_ACCOUNT_ID> - AUTOCFT_CF_TUNNEL_ID=<AUTOCFT_CF_TUNNEL_ID> volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - /root/data/autocft:/app/data networks: - test_net networks: test_net: external: true

必填参数获取指南：https://autocft.cloudfogtech.ltd/zh/cloudflare.html

Cloudflared 部署

宿主机部署

如果 Cloudflared 在宿主机部署，则需要为每个应用增加端口映射。auto.service 设置为从宿主机访问的地址。

容器部署

services: cloudflared:  cloudflare/cloudflared:2025.11.1 container_name: cloudflared restart: always command: tunnel run environment: - TUNNEL_TOKEN=<TUNNEL_TOKEN> networks: - test_net networks: test_net: external: true

容器部署的情况下，所有容器应该处于同一网络，因此不需要端口映射到宿主机，直接通过 Docker 网络访问。

示例应用

下面将部署示例应用展示应用如何和 AutoCFT 结合使用

普通应用

services: nginx:  nginx container_name: nginx restart: always # 宿主机部署Cloudflared需要开启端口映射 # ports: #   - "80:80" volumes: - /etc/ssl/certs:/etc/ssl/certs:ro labels: - autocft.enabled=true - autocft.hostname=nginx.example.com - autocft.service=http://nginx:80 # 宿主机访问地址为本地方位映射的端口 # - autocft.service=http://localhost:80 networks: - test_net networks: test_net: external: true

HTTPS 应用

services: nginx:  nginx container_name: nginx restart: always # 宿主机部署Cloudflared需要开启端口映射 # ports: #   - "443:443" volumes: - /etc/ssl/certs:/etc/ssl/certs:ro labels: - autocft.enabled=true - autocft.hostname=nginx.example.com - autocft.service=https://nginx:443 # 宿主机访问地址为本地方位映射的端口 # - autocft.service=https://localhost:443 - autocft.origin.origin-server-name=nginx.example.com # 如需忽略TLS证书验证，请设置下面的值 - autocft.origin.no-tls-verify=true networks: - test_net networks: test_net: external: true

应用部署后，默认配置的情况下大约 10s 后，配置将同步到 Tunnel，就可以访问了。

问题与反馈

两种方式供君挑选

  • 跟帖反馈
  • 通过 Github Issue 反馈

这算是我首次成体系的一个开源项目，在 2025 年末给大家一个更便于使用的工具，也给我自己做一个 2025 年的总结。

感谢始皇和 linux.do 平台的各位佬提供的各种教程、公益资源和这个交流的平台，缘分让我们聚在一起。

真诚 、友善 、团结 、专业 ，共建你我引以为荣之社区。

预祝 2026 的各位佬事业步步高升，生活顺心如意～linux.do 做大做强，再创辉煌～

新年快乐

📌 转载信息
原作者：
catfishlty
转载时间：
2025/12/31 17:14:05

在内网或离线 Linux 环境下，有时客户有需求或者业务上需要用到 FTP，装 vsftpd 时没网络各种依赖循环太麻烦。

用 AI 搓了一个 Go 写的 FTP 服务端：

  • 免编译： 提供编译好的二进制文件，下载即用。
  • 环境友好： 针对 Ubuntu 24.04 LTS 测试，兼容主流 Linux 发行版。
  • 配置简单： 配合 systemd 快速管理服务，适合长期挂载。

项目地址： GitHub - yizhitangtongxue/simple-ftp-server: a simple ftp server build with go

欢迎各位佬提意见。

📌 转载信息
转载时间：
2025/12/30 15:51:19

  工欲善其事必先利其器，这是一个关于十大黑客最佳操作平台的综合文章。

  在本文中，包括公德黑客运用的10个绝佳操作平台。每一个都是免费的，基于于Linux位，并且与许多黑客工具一起打包。

  10.

  |IMG

  是一个渗透检测的发行版的Linux从全球受到了最流行的免费的操作平台无法为黑客，的2017黑客入侵工具包，和周遭的工作GNOME经典图形桌面状态。

  该为大概3GB的镜象DVDISO画质，是基于的发行及自起动运行光碟，其传统在于一套用于网路渗透检测的实用软件虽然它与非常相像，但并不完全相似。采用了GNOME桌面。

  致力于必须执行渗透检测操作的安全学者视频培训脚本，的工作框架大部份包括了五分类软件，这些工具早已在菜单包括五个类别归纳整理。

  下载

  9.

  2017黑客入侵工具包

  |IMG

  是一个基于的开放源码渗透检测Linux发行版，它借助存档进行升级。它包含300多个渗透检测软件，另外还包含进行广泛操作所需的基本管理硬件。

  下载

  8.HAWKLINUX

  截图|IMG：

  HawkLinux被视为常识解决方案有限公司（PvtLtd.）生产的最非凡黑客技术，最有效和全面的基于的渗入测试Linux分散技术。专用于700多种适于渗透检测仪的软件，以及300多种适于多功用安全的器材和蓄意软件调查。

  HawkLinux是为白围巾黑客和渗入测试者设计的基于（Linux）的Linux发行版操作平台。Hawk可以适于网络安全和会计或者数字取证。它还包括多种软件，适合于联通安全和无线网路安全检测。

  下载HAWKLINUX

  7.ARCHLINUX

  ArchLinuxIMG：

  ArchLinux绝对是免费和开放源代码软件，并支持社区参加。

  ArchLinux是通用x86/64GNU/Linux发行版。Arch采用滚动更新机制，尽大力提供最新的稳固版硬件。初始安装的Arch只是一个基本平台，随后客户可以按照自己的偏好安装必须的硬件并配置成合乎自己梦想的平台.

  下载ArchLinux

  6.(NST)

  NST|iMG

  网络安全软件包（NST）是一个可鼓励的即用（live）CD，基于Core。这个软件包设计用来方便访问最棒的开源网路安全应用，主要运行在x86系统上。开发这个网路安全软件包的主要目的是为网路安全管控人员提供一套完备的开源网路安全软件。

  NST最奇特的地方是可以将大多数x86机器（奔腾2及以上）转化成一台可以适于网络流量预测、入侵测试、网络数据包生成、无线网路监视的虚拟服务器，当然它也可以当作一套复杂的网路/主机扫描器来使用。

  下载

  5.WEB

  武士网络测试|IMG：博客

  Web测试框架从根本上集中在检测Web应用程序的安全性，并牵涉Web评估和误用设备的负载。建立“武士网络测试框架”的功绩来自于Kevin，和Frank。“武士框架”为公德黑客和面试者提供了一个即时Linux条件，该条件预先配置为再次运行成为虚拟机执行Web渗透检测。

  武士Web测试框架结合了众所周知的检测器材，如和ance，和适于映射，w3af和Burp的启迪，以及BeEF和的研发。结构依赖于9.04，是完全开源的，并斩获关于工程的正常升级。

  下载WEB

  4.

  IMG

  是一个基于Unix的工作框架，根据由RedHat公司支持的由支持的组创立的Linux和GNU程序（Linux发行版）。

  包括的程序分散在不同的免费和开放源代码许可证下，并计划变成这种科技的主要优势。是RedHatLinux发行版的附属产品。

  下载

  3.

  IMG

  OS是面向安全的操作平台，它被设计为适于渗透检测、计算机取证、反向工程、攻击、云计算渗透检测、隐私/匿名、密码等场合。该发行基于，其传统在于MATE桌面环境，并由研发。

  操作平台运用Kali存档进行各类捆绑更新并协调新的软件。为PC框架审查员提供一个简略易用的GUI和重量级条件，发挥广泛的法律科学，弱点评估和加密。这个操作平台是十分适于定制化。

  下载操作平台

  2.

  LinuxIMG

  是一个基于的Linux发行版，用于在安全检测中帮助道德黑客和渗入测试员工。操作平台的目标是更迅速，更有效地运行并具备可忽视桌面的状况。的主要优势在于，它自己的特定软件内存在正常的时间间隔内进行升级2017黑客入侵工具包，以维持颜色的稳固和流行。

  分散包括从Web测试和平台调查到拉伸测试，嗅探，安全检测，犯罪现场调查和研发的70多种软件。

  下载

  1.KALILINUX

  KaliLinux|

  最先进的渗入测试平台。KaliLinux也是一个旨在于小软件（称为KaliLinux）应用。

  由Ltd维护和支助。最先由的Mati和Devon通过重写来完成，是她们之前写的适于取证的Linux发行版。

  最流行的kaliLinux软件

  Nmap，-ng，，，框架，Burp套件，John培训脚本，社会项目软件包，，，OWASPZAP

  下载KALILINUX