benn博客

为什么你的 OpenClaw 上网总是遇到验证码

Wed, 18 Mar 2026 00:00:00 +0000

我日常使用 OpenClaw，前段时间遇到一个问题：深度研究任务的结果总是很差。

排查之后发现，原因是浏览器被各大网站的反机器人系统拦截了。Agent 访问不了正常的信息源，只好退而求其次，去找一些质量差的替代来源，甚至直接编造内容。而这一切是静默发生的，表面上看不出任何异常。

本文记录一下这个问题的原因和解决方案。

一、被拦截

OpenClaw 内置的浏览器基于 Chromium 和 Playwright。我的环境是一台 MacBook Pro，家庭网络，浏览器里登录了各种账号，看上去和正常用户没有区别。

但实际情况是，几乎所有有反机器人检测的网站都会拦截它。Google 和 Bing 弹出验证码，X（原 Twitter）弹出登录墙，Medium 被 Cloudflare 直接拦截，页面无法加载。

我尝试过更换各种浏览器相关的 MCP、调整各种配置，都没有效果。

二、为什么会暴露

问题不在于某个工具或某项配置，而在于自动化浏览器从原理上就会暴露身份。这里有三个层面。

第一层：协议层面的暴露。 Puppeteer 和 Playwright 等工具通过 Chrome DevTools Protocol（CDP）控制浏览器。连接时会触发 Runtime.Enable 命令，反机器人脚本只需要几行 JavaScript 就能检测到。Cloudflare、DataDome 等服务都在检查这个信号。IP 地址和 Cookie 都不重要，控制协议本身就暴露了自动化的存在。

第二层：注入代码的暴露。 自动化工具需要向页面注入 JavaScript 才能工作，例如 window.__playwright__binding__ 等全局变量。反机器人脚本会检查属性描述符和函数签名。如果某个浏览器原生函数的 toString() 返回值不再是 "[native code]"，就说明代码被篡改过，足以触发拦截。

第三层：硬件指纹的暴露。 浏览器会暴露大量关于运行设备的信息。WebGL 暴露 GPU 型号和渲染行为，Canvas API 的输出因显卡而异，还有屏幕分辨率、字体指标、音频处理特征等等。每台真实设备都有一组独特且内在一致的数值。

自动化浏览器在这方面容易出问题。比如 Canvas 输出在成千上万个会话里完全相同，或者 User-Agent 声称是 Windows 系统，但 GPU 参数却指向 Apple 硬件。反机器人系统大规模收集这些指纹，只要发现不一致，就会触发拦截。

总结一下：自动化工具在协议、注入代码和硬件指纹三个层面都可以被检测到，仅靠修改配置无法解决。

三、在引擎层面解决

大部分反检测工具在 JavaScript 层面做文章，覆盖 navigator.webdriver 或伪造 Canvas 输出。但如前所述，反机器人脚本可以识别这种 JavaScript 层面的伪装。要真正解决问题，需要在浏览器引擎层面做修改。

Camoufox 是一个 Firefox 分支，采用的就是这个思路。它的做法有几个关键点：

在 C++ 层面修改指纹值，伪装的属性在任何检测手段下都表现为原生值。
不使用 CDP 协议，页面脚本无法感知自动化代码的存在。

四、让 OpenClaw 用起来

让 OpenClaw 使用 Camoufox 后，Google 搜索、Medium、X 等网站都恢复正常了。

但直接使用 Camoufox 有一个问题：它只提供 Python SDK。每次浏览器操作，Agent 都要生成一段 Python 脚本，处理异步上下文，解析返回结果。光是写这些胶水代码就消耗大量 token。Agent 的主要精力不在研究任务本身，反而在处理这些技术细节。

为了解决这个问题，我把 Camoufox 封装成了一个命令行工具（CLI）。Agent 通过 shell 命令完成页面打开、元素点击、表单填写等操作，不需要生成 Python 脚本。

另外，为了控制 token 消耗，我借鉴了 agent-browser 的做法：CLI 返回的不是原始 HTML，而是无障碍树（accessibility tree）的快照。每个元素带有一个短的 @ref 标签用于后续交互。还有一个只返回交互元素的模式，过滤掉非交互内容，只保留按钮、链接和输入框。一个典型页面，HTML 形式大约 15000 token，交互快照只需要大约 800 token。

这个工具已经稳定运行了几周，深度研究的质量明显提升了，因为 Agent 终于能正常访问那些高质量的信息源了。CLI、Skill 和代码都开源在 camoufox-cli，希望能帮到遇到同样问题的人。

Moltbot 初体验：真的太像 AI 实习生了

Wed, 28 Jan 2026 00:00:00 +0000

认真折腾了下 Moltbot（原名 ClawdBot）。

结论：很好玩。每个想法单独拿出来都不算新鲜，但组合在一起非常有趣。不过 bug 非常劝退，用好和折腾的门槛很高。说实话很久没被这么多 bug 折腾过了。但真的很好玩，很像远程上班的真人实习生。

本质上，Moltbot 可以理解成 Claude Code（为代表的本地 Agent）+ 一大堆优质内置 Skills/MCPs + 长期记忆 + CronJob + IM 机器人。

我专门给了一台闲置 Macbook 给它，现在它几乎啥都能干。因为内置了大量 Skills 与工具，Moltbot 非常擅长"抢夺"电脑，比如控制浏览器、启动窗口、运行命令行、在背后安装和运行各种程序……几乎在电脑里能干的都能干。所以为了安全和不被打扰，大家都会专门搞个独立虚拟机或电脑，通过 IM 沟通。

我用 Telegram 和家里闲置电脑里的 Moltbot 对话（它也支持 WhatsApp 等各种常见 IM）。有一种奇妙的感觉：在手机里点点手指，就能指挥家里的 AI 干活，而它在电脑上似乎啥都能做。这非常接近我最理想、最梦寐以求的体验，就像有个远程实习生。

为什么说像实习生

如果不考虑部署维护，Moltbot 使用起来极其简单，只需要在 IM 里发消息就行，不需要理解任何 AI 概念。这是它和其他 AI 工具最大的区别：你真的可以把它当成一个坐在电脑前的实习生。

列举一些我经历的 Aha Moment：

1. 像真人一样能处理各种电脑数据，主动解决问题

它经常突然成功做了一件其他 AI 没有电脑时做不到的事。

收到我的语音消息后，因为我没配语音识别 key，它自己下了个 Whisper（OpenAI 开源的语音识别模型）来识别，然后自己想办法用 macOS 自带 TTS（文字转语音）能力给我发语音回复。

收集冷门信息时发现了一个 B 站视频，为了能"看"这个视频，它用 yt-dlp（命令行视频下载工具）下载下来用 Whisper 转文本，再根据文本+时间戳的关键帧来理解内容。

2. 很强的"可培养"能力

我有些比较复杂的任务，交给其他 AI 工具都没办法很好完成。我让 Moltbot 尝试了下，刚开始什么都不太会，但稍微带一带就上手了。每次提醒后它都会把经验记下来（存为 skill 和记忆文档），下次直接复用。于是我越是不断培养它，它完成我的工作就越熟练。

另外在很多具体细节里，它还会悄悄记下我的喜好和风格。我也经常说"你可以记下来"、“下次要注意”，每次它都会表现得更好一点。

3. 做事很有主动性

比如我随口提了句"Hacker News 有哪些有趣项目"，它建议把这当成长期跟踪任务，然后自己制定了每日检查清单和跟踪文档，每天主动给我发报告。

所以可以把需要长时间跟进的任务交给它，它会定时去做。这很类似我之前 cron + Claude Code 的用法，但更灵活、更友好、更自然，不需要折腾什么 bash 脚本，只需要像给真人一样吩咐下就行了。

缺点

Bug 真的很多。举几个例子：任务执行到一半莫名中断、记忆偶尔丢失、有时候会陷入死循环重复同一个动作。部署过程也比较折腾，gateway 经常不太稳定，日志也没有具体的报错信息，而且涉及到让 AI 控制电脑，配置不当可能有安全隐患。

目前还是早期产品的状态，适合愿意折腾、有一定技术背景的人尝鲜。

使用技巧

给它一台专门的电脑或虚拟机，别用自己的主力机
忘记它是 AI，像带真人实习生一样沟通和培养
遇到它做得不好的地方，可以多提醒 “记下来下次注意”
鼓励它帮你主动做事，常常会收获很多惊喜哈哈

总结

如果只用一句话形容：我真的有点把它当成远程工作的实习生了。Moltbot 真的太像一个真人实习生了，其他 AI 工具只是工具。

用了一段时间后，我开始有点想买一排 Mac Mini 运行一群 Moltbot，这样没准我就有一个专属实习生团队了。后来发现这已经变成网上一个梗图了：

2026.01.29 更新：

我对 ClawdBot 的喜欢与日俱增，并且有了更多更重要的发现：

越是把它当真人对待，它给你的惊喜就越多。

这包括：

给它一台人类使用的专属的电脑（比如 macbook）
使用家庭网络，不要把它孤零零放在机房服务器里
帮它注册专属的互联网账户，比如 google、reddit 账户等，交给它自己玩
鼓励它更多地使用人类工具（比如浏览器），少用 API 请求
让它干活时耐心地教导它，并提醒它记下来
做得好的时候要及时反馈给它，鼓励它下次保持
沟通保持平等，主动为它提供帮助 ……

最后你会发现 clawdbot 会源源不断带来各种各样的惊喜

我可以解释下这些技巧的背后逻辑：越是把它当真人对待，它的表现就越像真人。它对自己的要求和态度会像真人那样有成长性。同时互联网各种人机校验会更容易把它当真人，这样就越不容易被拦下来。

Go 内存溢出的线上排查小记

Fri, 14 Jun 2024 14:52:21 +0800

背景

最近我们公司陆续推出了几款新游，在上线当天就异常火爆。因为我们服务支持了游戏中的某个不起眼的小功能，所以这次游戏发布也给我们的服务带来了不少的挑战。其中有个消费者服务在线上出现了严重的OOM（Out-of-Memory）问题，导致系统与游戏业务之间出现了数据同步的延迟。我帮忙排查了这个问题，并很快进行了妥善的处理和修复。

出现问题

在游戏发布的当晚，峰值时我们每小时有 723 万条 Kafka 事件被创建，消费者服务需要及时地处理这些数据，然后传递给游戏项目组。而此时我们却收到了消费者服务 pod 频繁重启的告警……

诊断问题

我第一时间查看了 k8s 的事件记录，原因是容器因超过内存限制而退出重启（证据一）。究竟是内存配置不够，还是服务存在内存泄露问题，作出判断前还需要看监控指标。

从资源监控上看：

在闲时，每个 pod 内存都在随着时间而增加，并且没有持平和减退的迹象。这正是内存溢出的常见迹象。（证据二）

当游戏发布后大量流量与事件涌入，指标也立即呈现出了剧烈的周期性波浪，表明此刻每个 pod 的内存快速飙升、又因为达到限制而被重启……这个过程反反复复，也印证了线上问题的实际表现。（证据三）

这时候已经可以确信线上问题是因为内存溢出导致的，那么应对方案也确定了。

紧急应对

应对这类线上问题，首先要立即有效地降低负面影响。这是我当时给出的临时方案：

将部署的内存限制提高四倍
将 pod 数量规模扩大四倍

这样即使线上内存溢出问题依然存在，也能尽可能地缩短服务 OOM 和 pod 重启导致的消费延迟。而且更重要的，这么做也可以为我们接下来的定位修复提供足够的时间和线上环境。

定位问题

从监控指标上看，很明显内存溢出问题很久之前就存在了，只是在这波流量中更加显著地暴露了出来。

接下来要定位内存泄露的原因，首先要获取服务内部的数据指标，尤其是最关键的 heap 打点。好在 Golang 本身的工具链非常成熟，我直接选择了官方的 pprof 工具。

1. 接入 pprof

接入 pprof 有两种方式，一是在服务中直接启动 pprof 的接口服务：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


import (
 _ "net/http/pprof"
 "net/http"
)

func main() {
 go func() {
 http.ListenAndServe("localhost:6060", nil)
 }()
 // ...其他业务代码
}

或者在原有服务中额外地添加 pprof 接口：

1
2
3
4
5
6


func AttachProfiler(router *mux.Router) {
 router.HandleFunc("/debug/pprof/", pprof.Index)
 router.HandleFunc("/debug/pprof/cmdline", pprof.Cmdline)
 router.HandleFunc("/debug/pprof/profile", pprof.Profile)
 router.HandleFunc("/debug/pprof/symbol", pprof.Symbol)
}

如果你第一次使用 pprof，请注意要确保相关的路径（ /debug/* ）不对外网暴露，否则可能会泄露技术数据。

2. 导出 heap 文件

在终端连上某个 pod，导出 heap 文件

1

curl -o heap.pprof http://localhost:6060/debug/pprof/heap

3. 本地分析 heap 文件

将 heap 文件下载到本地，进行可视化分析

1

go tool pprof -http=:8081 ./heap.pprof

在 MacOS 第一次做可视化分析时，可能会需要安装本地依赖：

1

brew install graphviz

问题分析

我每隔一段时间都在同一个 pod 中打点一个 heap 文件。通过对比，我发现 ccache(*Cache) restart 的内存消耗随着时间不断膨胀，显得非常可疑。

这个 ccache 实例是某个 service 实例中包含的，只是用来缓存哪些 ES index 是否存在。按道理这个实例不应该使用这么多的内存。

我还在 ccache 的 GitHub 仓库中到了一条 issue： https://github.com/karlseguin/ccache/issues/74 。虽然这不是我们问题的原因，但是作者在评论中提到了一个很重要的信息：ccache 初始化后会在后台运行一个 goroutine，实例不再需要时，需要手动地调用 stop() 方法进行清理。

我联想到这个仓库的代码风格，很快就猜到了原因：

消费者需要调用 Service 中的方法。在每次消费事件时，同事们为了方便都会直接初始化一个 Service 实例：

1
2
3
4


func HandleMessage(msg *Message) error {
 svc := InitService()
 // ...
}

每消费一个事件都初始化一个新的 Service 实例，而每个 Service 实例都包含一个新的 ccache.Cache 实例，而每个 ccache.Cache 都有一个后台运行的 goroutine……这真是一个经典的 goroutine 泄露导致内存泄露的问题！

问题修复

为这个 Service 加上了手动清理后，线上的内存溢出问题也就消失了。

同时，这个问题也隐含了另外一个遗漏，即这个项目的实例初始化和依赖管理机制还比较原始，依然采用人工初始化的方式。这么做虽然很简单，但是在系统比较复杂时，很难有效地正确管理每个实例的生命周期，这也就导致了本次某个 Service 频繁被初始化、却又忘记清理的问题。

我后来的建议是引入 wire + newc 的依赖注入方案，这样所有实例依赖都通过初始化时作为参数传入，而冗长的初始化代码完全交给自动生成，又能减少人工维护的易错性。

这个方案其实已经在我们团队的诸多项目里得到充分验证了，好像刚好就这个系统因为太老而没有改动，正好趁这次问题推进一下哈哈～

总结

其实我写这篇博客时觉得有些无聊，因为 Golang 线上内存泄露问题的排查是非常成熟和套路的，以至于让我怀疑有没有必要为此特意写一篇博客。但我觉得过程中的很多做事方式是值得分享的，而且这些只能在具体事例中才能更好地体现：

先判断线上发生了什么问题，寻找数据证据（比如到底是内存配置不够、还是内存溢出）
找到问题后，第一时间应该先寻求临时解决方案，降低线上负面影响
根据数据排查问题原因：大胆假设、小心取证
除了修复问题，还要反思在未来如何避免

Wire：Go最优雅的依赖注入工具

Wed, 24 Aug 2022 14:52:21 +0800

导语

“成熟的工具，要学会自己写代码”。本文介绍了 Go 依赖注入工具 Wire 及其使用方法，以及在实践中积累的各种运用技巧。当代码达到一定规模后，Wire 在组件解耦、开发效率、可维护性上都能发挥很大的作用，尤其在大型单体仓库中。

依赖注入

当项目变得越来越大，代码中的依赖也越来越多：各种数据库、中间件的客户端连接，分层设计中的各种数据访问层 repositories 实例、services 实例……

这时为了代码的可维护性，应该避免组件之间的耦合。具体的做法可以遵守一个重要的设计准则：所有依赖应该在组件实例初始化时传递给它，这就是依赖注入（Dependency injection）。

Dependency injection is a standard technique for producing flexible and loosely coupled code, by explicitly providing components with all of the dependencies they need to work.

– Go 官方博客

下面是个简单的例子，所有组件实例 Message、Greeter、Event 的依赖都在初始化的时候获得。

1
2
3
4
5
6
7


func main() {
 message := NewMessage()
 greeter := NewGreeter(message)
 event := NewEvent(greeter)

 event.Start()
}

Wire 介绍

当项目中的组件实例越来越多，如果还是手动编写初始化代码和维护组件之间依赖关系的话，会是一件非常繁琐的事情，而且在大型仓库中尤其明显。因此，社区里已经有了不少的依赖注入框架。

除了来自 Google 的 Wire 以外，还有 Dig（Uber）、Inject（Facebook）。其中 Dig 和 Inject 都是基于 Golang 的 Reflection 来实现的。这不仅对性能产生影响，而且依赖注入的机制对使用者不透明，非常"黑盒"。

Clear is better than clever ，Reflection is never clear.

— Rob Pike

相比之下，Wire 完全基于代码生成。在开发阶段，Wire 会自动生成组件实例的初始化代码，生成的代码人类可读，可以提交仓库，也可以正常编译。因此 Wire 的依赖注入非常透明，也不会带来运行阶段的任何性能损耗。

上手介绍

下面介绍 Wire 的使用方法

第一步：下载安装 Wire

下载安装 wire 命令行工具

1

go install github.com/google/wire/cmd/wire@latest

第二步：创建 wire.go 文件

在生成代码之前，我们先声明各个组件的依赖关系和初始化顺序。在应用入口创建一个 wire.go 文件。

cmd/web/wire.go

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


// +build wireinject

package main

import "..." // 简化示例

var ProviderSet = wire.NewSet(
 configs.Get,
 databases.New,
 repositories.NewUser,
 services.NewUser,
 NewApp,
)

func CreateApp() (*App, error) {
 wire.Build(ProviderSet)
 return nil, nil
}

这个文件不会参与编译，只是为了告诉 Wire 各个组件的依赖关系，以及期望的生成结果。在这个文件：我们期望 Wire 生成一个返回 App 实例或 error 的 CreateApp 函数，App 实例初始化所需要的全部依赖都由 ProviderSet 这个 provider 列表提供，而 ProviderSet 声明了所有可能需要的组件的获取/初始化方法，也隐式定义了组件之间的依赖顺序。

组件的获取/初始化方法，在 Wire 中叫做 “provider”

还有几点需要注意：

文件开头必须带上 // +build wireinject 和随后的空行，否则会影响编译
在这个文件中，编辑器和 IDE 可能无法提供代码提示，但没关系，稍后会介绍如何解决这个问题
其中 CreateApp 的返回（两个 nil）没有任何意义，只是为了兼容 Go 语法。

第三步：生成初始化代码

命令行执行 wire ./...，然后就能得到下面这个自动生成的代码文件。

cmd/web/wire_gen.go

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


// Code generated by Wire. DO NOT EDIT.

//go:generate go run github.com/google/wire/cmd/wire
//go:build !wireinject
// +build !wireinject

package main

import "..." // 简化示例

func CreateApp() (*App, error) {
 conf, err := configs.Get()
 if err != nil {
 return nil, err
 }
 db, err := databases.New(conf)
 if err != nil {
 return nil, err
 }
 userRepo, err := repositories.NewUser(db)
 if err != nil {
 return nil, err
 }
 userSvc, err := services.NewUser(userRepo)
 if err != nil {
 return nil, err
 }
 app, err := NewApp(userSvc)
 if err != nil {
 return nil, err
 }
 return app, nil
}

第四步：使用初始化代码

Wire 已经帮我们生成了真正的 CreateApp 初始化方法，现在可以直接使用它。

cmd/web/main.go

1
2
3
4
5


// main.go
func main() {
 app := CreateApp()
 app.Run()
}

使用技巧

组件按需加载

Wire 有个优雅的特点，不管在 wire.Build 中传入了多少个 provider，Wire 始终只会按照实际需要来初始化组件实例，所有不需要的组件都不会生成相应的初始化代码。

因此，我们在使用时可以尽可能地提供更多的 provider，把挑选组件的工作交给 Wire。这样我们在开发时不管引用新组件、还是弃用老组件，都不需要修改初始化步骤的代码 wire.go。

比如，可以把 services 层中所有的实例构造器都提供出去。

pkg/services/wire.go

1
2
3
4


package services

// 提供了所有 service 的实例构造器
var ProviderSet = wire.NewSet(NewUserService, NewFeedService, NewSearchService, NewBannerService)

在初始化中，尽可能地引用所有可能需要的 provider。

cmd/web/wire.go

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


var ProviderSet = wire.NewSet(
 configs.ProviderSet,
 databases.ProviderSet,
 repositories.ProviderSet,
 services.ProviderSet, // 引用了所有 service 的实例构造器
 NewApp,
)

func CreateApp() (*App, error) {
 wire.Build(ProviderSet) // Wire 会按照实际需要，选择性地进行初始化
 return nil, nil
}

在后续开发中，如果需要引用新的依赖组件，只需要加到参数里即可。Wire 会智能地按照实际需要，生成所需组件实例的初始化代码。

1
2


func NewApp(user *UserService, banner *BannerService) {
}

即使 Wire 找不到所需的 provider，也会提前在编译阶段报错，不会在线上运行阶段出现问题。

wire: cmd/api/wire.go:23:1: inject CreateApp: no provider found for *io.WriteCloser

编辑器与 IDE 的辅助配置

因为 wire.go 文件中加了这行注释，Go 在编译时会跳过这个文件，但也因此会影响编辑器和 IDE 的代码提示。当你在编辑 wire.go 文件时，常见的编辑器和 IDE 都无法正常地提供代码补全和错误提示功能。

1

// +build wireinject

但这个问题很容易解决。找到 IDE/编辑器的 Go 环境配置，在 Go Build Flags 中添加这个参数 -tags=wireinject 就可以了。

这个配置可以让编辑器和 IDE 正常地为 wire.go 文件提供代码补全和错误提示功能，开发体验显著提升。

多个同类型实例的冲突问题

这个问题比较少见，但项目大了总是容易遇到。

Wire 通过 provider 的参数与返回类型，来判断依赖关系。有时候，依赖网络中可能出现同类型的不同实例，这时 Wire 无法正确判断依赖关系，会直接报错。

provider has multiple parameters of type ...

比如下面这个 provider，依赖的 MySQL 和 PostgreSQL 客户端实例的类型是完全相同的（都是 *gorm.DB），这时 Wire 无法根据类型正确地判断依赖关系，生成代码时会直接报错。

1
2
3


// 这个 service 同时使用了 mysql 和 pg 中的数据，但是两个实例的类型是相同的
func NewService(mysql *gorm.DB, pg *gorm.DB) *Service {
}

解决的方法也比较简单，只需要做一层类型的包装。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


type Mysql gorm.DB
type Pg gorm.DB

// 在参数中用类型别名进行区分
func ProviderService(mysql *Mysql, pg *Pg) *Service {
 // 函数内再转回原来的类型
 r1 := (*gorm.DB)(mysql)
 r2 := (*gorm.DB)(pg)
 return NewService(r1, r2)
}

然后用 ProviderService 代替 NewService 即可。

1
2
3
4
5


wire.Build(
 ProviderMysql, // func() *Mysql
 ProviderPg, // func() *Pg
 ProviderService, // func(mysql *Mysql, pg *Pg) *Service
)

自动生成构造函数

当项目中作为抽象层的结构体越来越多，手动编写和维护结构体的构造函数，也是一件非常繁琐的事情。如果结构体中新增了一个指针类型的成员、却忘记更新构造函数，甚至还会引起线上 panic。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


type Service struct {
 repo *Repository
 logger *zap.Logger // 添加这个成员后，忘记更新构造函数了
}

func NewService(repo *Repository) *Service {
 // 缺失 logger，可能在线上出现空指针错误
 return &Service {
 repo: repo,
 }
}

像这种繁琐、重复、容易出错的工作，就应该交给自动工具来完成。这里推荐一个自动工具 newc（意为 “New Constructor”），它可以自动生成与更新结构体的构造函数代码。

使用方法非常简单，只需要给结构体添加这行注释。

//go:generate go run github.com/Bin-Huang/newc@v0.8.3

比如这样：

1
2
3
4
5
6
7


// My User Service
//go:generate go run github.com/Bin-Huang/newc@v0.8.3
type UserService struct {
 baseService
 userRepository *repositories.UserRepository
 proRepository *repositories.ProRepository
}

然后命令行执行 go generate ./... 即可获得构造函数代码：

constructor_gen.go

1
2
3
4
5
6
7
8


// NewUserService Create a new UserService
func NewUserService(baseService baseService, userRepository *repositories.UserRepository, proRepository *repositories.ProRepository) *UserService {
 return &UserService{
 baseService: baseService,
 userRepository: userRepository,
 proRepository: proRepository,
 }
}

这个工具和 Wire 搭配使用，开发体验非常好。要使用新的依赖组件时，直接在结构体中添加成员就好了，不需要手动更新构造函数，也不需要考虑初始化的问题，所有重复的工作都交给自动工具（Wire 和 Newc）来完成。在实际项目中使用效果很好。

当然这个工具也一定有考虑不周的情况，很期待大家的反馈和建议。

Don’t repeat yourself “DRY”

总结

Wire 可以完美地解决依赖注入的问题，但它不是一个框架，它没有”魔法“，也不是黑盒。它只是一个命令行工具，它根据实际需要，自动生成了各个组件实例的初始化代码。然后问题就解决了，没有额外的复杂性，没有运行的性能损耗。

Wire 和 Golang 的气质如出一辙，简单、直接、实用主义，不愧是 Go 最优雅的依赖注入工具！

Keep it simple stupid “K.I.S.S”

深入讨论几种 ES Mapping 修改方法和局限

Mon, 14 Feb 2022 12:23:53 +0800

前言

众所周知，ElasticSearch 中的 Mapping 决定了字段的索引方式。当一个字段的索引类型确定后就无法修改。然而在日常开发中，忘记更新 mapping 是偶尔会遇到的，但修改 mapping 却是一件不容易的事情。这篇文章不仅详细讨论了 reindex 这种常见解决方法，包括 reindex 的停机和数据丢失问题、以及在各种情况下规避上述问题的思路和方法，还介绍了另外两种更加低成本的解决方法。

一个常见的错误

“发布测试环境前我竟然忘记修改 mapping 了？”

{"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"Fielddata is disabled on text fields by default. Set fielddata=true on [player_type] in order to load fielddata in memory by uninverting the inverted index......

~~所以我要如何快速解决这个问题呢？~~ 所以我要如何快速修改 mapping 中一个字段的索引类型呢？

Reindex

“即使对 reindex 烂熟于心，也需要留意停机时间和数据丢失……”

Reindex 几乎是这类问题的标准答案，其中一个常见思路是：创建一个新的 index-tmp，然后把数据 reindex 到这个新 index-tmp，再把原来的 index 删除重建、设置正确的 mapping，最后把数据重新从 index-tmp 中 reindex 回来。很明显这个思路除了操作危险外，还会有较长的停机时间。

ElasticSearch 官方博客里曾介绍过另一种方法，只要后端业务以 alias 的方式访问 index，就可以做到完全无停机时间（Zero-Downtime）。具体思路是：首先创建一个 mapping 正确的新 index-v2，把数据 reindex 到这个新 index-v2，然后直接把 alias 重命名到这个index-v2。这样可以让后端业务直接访问到新的 index-v2，达到后端业务对 reindex 操作无感知的效果。

然而这种方法也有不足，官方博客里完全没有提及数据丢失的问题。如果线上写入操作频繁，在 reindex 和更新 alias 步骤中有一段时间窗口，新数据依然会写入到即将弃用的旧 index，造成新 index-v2 丢失该部分数据的问题。即使采用官博推荐的 bulk API，也无法在原理上根本地规避问题。

因此需要结合实际的业务情况，做一些因地制宜的权衡。

1. 那就丢亿点点数据

有时候，丢失一些临时数据也是可以接受的，比如测试环境的PV上报、用来时间窗口统计的热词记录……对于这些可丢失数据，当我们发出那句灵魂拷问，“数据重要还是~~我重要~~下班重要！”，相信产品经理也是会认真考虑的。

2. 找个夜黑风高的时候停机

防止新数据丢失最简单的办法就是停机了。只要没有写入，哪来数据丢失。在我常常遇到的 ES 使用场景里，新数据总是通过消费者从其他数据源里同步过来，只要先让消费者暂停就可以解决问题。后端业务还是可以正常读取 ES，只是停止了消费者的写入。当一切结束后，消费者可以直接从消息队列里获取堆积的写入任务，轻松地恢复工作。

3. 让新数据先走

能不能在不停机的情况下，也能做到不丢失数据？完全可以。创建新 index 后，立即重新设置 alias，让新 index 先开始接受新数据，然后再把老数据 reindex 过来。这样数据要么在新 index、要么在旧 index，但最终都会写入在新 index，解决了新文档丢失的问题。

但我也想到了这种方法的几个不足和局限：

中间会有很长一段时间（当新 index 开始接客、旧数据还没有全部 reindex 过来时），后端业务将无法访问到旧数据。这可能会对业务造成影响，比如用户突然无法搜索到以前的文章。
这个方法只能保证新文档插入不丢失，对旧文档的更新和删除操作依然可能丢失。当然，如果业务里 ES 的使用场景是“只写不改”，那也就不是问题了。不过说起来，把 ES 用来作为 CRUD 数据库确实是很奇怪的技术选型～

4. 两步 reindex

我还想到了一个方法，可以在不停机的情况下，既让后端业务尽可能正常地访问老数据，又不丢失新文档的创建。这个方法要求文档创建时附带一个 created_at 字段。

创建一个新的 index-v2，设置好需要的 mapping。

PUT /index-v2/_doc/_mapping
{
"properties": <all_you_need>
}

先“悄悄”准备老数据，比如先 reindex 某个时间点之前的老数据（比如一小时前）。

POST _reindex
{
"source": {
"index": "index-v1",
"query": {
"range": {
"created_at": {
"lt": <一个时间点>
}
}
}
},
"dest": {
"index": "index-v2"
}
}

当老数据准备好后，立即修改 alias，让新 index-v2 开始接受新数据。

POST /_aliases
{
"actions": [
{
"remove": {
"alias": "index",
"index": "index-v1"
}
},
{
"add": {
"alias": "index",
"index": "index-v2"
}
}
]
}

再将这个时间点之后的数据 reindex 到新 index-v2

POST _reindex
{
"source": {
"index": "index-v1",
"query": {
"range": {
"created_at": {
"gte": <一个时间点>
}
}
}
},
"dest": {
"index": "index-v2"
}
}

这样在迁移过程中，既不需要停机，也不会丢失新数据，也不会出现长时间无法访问历史数据的问题。后端业务几乎可以访问到所有的数据，只有在第二次 reindex 期间会有极小部分数据在短时间内无法访问（不可见数据范围大约是 created_at: [the_timestamp, now）），但也会很快地恢复。因为数据量非常少，第二次 reindex 速度很快，等到结束后，后端业务就可以完全正常地访问到所有的数据。

这个方法可以保证新文档插入不丢失、大部分旧文档更新删除不丢失，但在第二次 reindex 期间那些不可见文档的更新、删除操作依然有丢失的可能。这个方法在不停机的前提下大幅地缩小了负面影响的范围。

小结

以上只是尽可能地讨论了 reindex 在实际业务中可能遇到的问题，以及可行的方法与思路。虽然在实际应用中，大多数情况都可以用简单直接的方法解决，比如遗弃数据和停机，但认识更多情况可以规避潜在的决策风险。

对了，这里没有讨论 reindex 优化，我感觉这是另外一个话题了。我看到有些高赞文章提到通过配置来增大 reindex 单次索引的文档数量，或者通过 scroll 并发来加快索引。我直观的感觉，这些方法在停机情况下应该是不错的做法，但在不停机时可能会给集群带来更多的压力，尤其是 index 数据量很大、读写频繁的场景，可能会影响到正常的业务。在不停机的情况，也许我们应该更多考虑的不是如何加快 reindex 过程，而是尽可能降低 reindex 对正常业务的影响。

除了 reindex，还有其他一些方法可以“修改”已有字段的索引类型。

新字段替换

“既然不能直接修改原来字段的索引类型，那我重新建个字段好吧……”

很多时候，为了一点点错误索引的数据而 reindex 整个 index，也许是一件大动干戈的事情。利用其他技巧可以更加低成本的解决问题，比如建个新字段。

在 mapping 添加新字段 new_field，设置好需要的索引方式

PUT /my-index/_doc/_mapping
{
"properties": {
"new_field": {
"type": "keyword"
}
}
}

将原来文档的旧字段的值重新赋予到新字段

POST /my-index/_update_by_query?conflicts=proceed
{
"script": {
"source": "ctx._source.new_field = ctx._source.old_field",
"lang": "painless"
},
"query": {
"exists": { "field": "old_field" }
}
}

在业务代码中弃用原来的字段

小结

这个方法非常适合低成本解决少量数据被错误索引的情况，比如在发布前忘记修改 mapping。但是如果需要修改索引类型的数据很多，这个方法需要更新大量已有数据，可能会对集群带来一定压力。毕竟在 ElasticSearch 里，所谓的文档修改就是先标记删除、然后重新插入，如果要更新整个 index 的所有文档，也许还不如 reindex 来得痛快……

采用 multi-field

“作为一个成熟的 DB，总是可以为一个字段建立多种索引……”

ElasticSearch 的 multi-field 特性，让同一个字段可以有多种不同的索引类型。我们可以利用这个特性在 mapping 中为老字段追加新的索引类型。比如这个例子：

PUT /my-index/_doc/_mapping
{
"properties": {
"company": {
"type": "keyword",
"fields": {
"name": {
"type": "text"
}
}
}
}
}

原本 company 字段采用了 keyword 的索引类型，只能用于数值匹配。在上面的例子中，为 company 字段追加了另一种支持全文搜索的索引类型 text，然后把这个全文搜索版本取名叫 company.name。这样查询条件 { "company.name": "腾讯" } 就可以匹配到 { "company": "腾讯科技有限公司" } 的数据了。

因为本质上只是对同一个字段添加不同的索引，实际文档（documents）中并不会真的多出来一个叫 company.name 的字段，插入数据时也不需要为 company.name 赋值。一切索引工作都由 ElasticSearch 自动完成。

然而用这种方法修改 mapping 后，只有新的写入才会让该文档的新索引生效。也就是说，只有插入新的文档、或者更新旧文档时，ElasticSearch 才会给该文档重新索引、将该文档写入新索引。除非老数据有更新，用 company.name 无法搜索到老数据，因为老数据根本不在这个索引里！

但问题总是可以解决，不就是还差一次全局更新嘛～（坏笑脸

// 这个更新没有任何意义，纯粹是为了触发老数据的重新索引
POST /my-index/_update_by_query?conflicts=proceed
{
"script": {
"source": "ctx",
"lang": "painless"
},
"query": {
"exists": { "field": "company" }
}
}

小结

这个方法不仅适合低成本解决少量数据被错误索引的情况，而且在同个字段需要多种索引方式（尤其需要是搭配不同的分析器）时这几乎是唯一的做法，因为 multi-field 就是为了这种场景准备的。但这个方法同样需要注意更新数据的规模，以及对性能的影响……

最后

我在中英互联网上搜索时，发现很难找到详细讨论这个话题的文章。其中我找到最好的资料是 ElasticSearch 官博的一篇文章，里面简要介绍了这三种方法，但是很少介绍各个方法的局限、已知问题和适用场景，比如几乎没有提到 reindex 的数据丢失问题。我还找到了很多只言片语，它们大多只是简单提供了一个解决方法，却很少介绍方法的用意和局限。

所以我尝试写篇文章，想着结合自己的认识和理解，试着更加全面地讨论一下各个方法的利弊权衡，看看能不能从这个常见的小问题出发，窥探到一点点原理和设计的影子，填补一点点底层技术与实际业务的缝隙，引发一些可能的讨论和思路。

最后不得不感叹：方法常有，银弹难寻！只有根据实际情况，在业务可接受的影响范围内，找到最简单方法，往往那就是最佳实践。

benn博客

为什么你的 OpenClaw 上网总是遇到验证码

一、被拦截

二、为什么会暴露

三、在引擎层面解决

四、让 OpenClaw 用起来

Moltbot 初体验：真的太像 AI 实习生了

为什么说像实习生

1. 像真人一样能处理各种电脑数据，主动解决问题

2. 很强的"可培养"能力

3. 做事很有主动性

缺点

使用技巧

总结

Go 内存溢出的线上排查小记

背景

出现问题

诊断问题

紧急应对

定位问题

1. 接入 pprof

2. 导出 heap 文件

3. 本地分析 heap 文件

问题分析

问题修复

总结

Wire：Go最优雅的依赖注入工具

导语

依赖注入

Wire 介绍

上手介绍

第一步：下载安装 Wire

第二步：创建 wire.go 文件

第三步：生成初始化代码

第四步：使用初始化代码

使用技巧

组件按需加载

编辑器与 IDE 的辅助配置

多个同类型实例的冲突问题

自动生成构造函数

总结

深入讨论几种 ES Mapping 修改方法和局限

前言

一个常见的错误

Reindex

新字段替换

采用 multi-field

最后

参考