AHK 里做“找图找色”，很多人第一反应是 ImageSearch，但如果从实战维护、效率和发布脚本的角度看，我更建议把 FindText 放在找图方案的第一位。日常取色用 PixelGetColor 就够了；需要更高性能、更强截图能力时，再进阶到 WinCaptureV1封装调用。
这篇文章的核心结论很明确：找图找色主推 FindText，日常取色用 PixelGetColor，进阶截图识别用 WinCaptureV1。 ImageSearch 作为 AHK 自带命令可以了解，但它依赖图片文件，效率和维护体验都不占优，通常不是我最推荐的路线。很多 ImageSearch 能完成的需求，其实都可以用 FindText 实现，而且 FindText 也是 AHK 圈里最受欢迎、最值得长期掌握的库之一。
文章会引用站内一些高浏览量内容作为延伸阅读，例如 【v1版】FindText – 屏幕找图找字的自动化神器、FindText 深度教程 v1.2、最快的截图取色找图库-WinCaptureV1封装调用、FindText + WinCapture 结合使用 By FeiYue。具体请到原文查看。
一、先给推荐顺序
| 需求 | 推荐方法 | 推荐程度 | 原因 |
|---|---|---|---|
| 找按钮、图标、固定 UI 特征 | FindText | 最推荐 | 不用携带图片文件，特征可文本化保存，维护和分享都方便 |
| 判断颜色状态 | PixelGetColor | 日常首选 | 轻量、简单、AHK 原生支持，适合状态灯、血条、颜色开关 |
| 高频截图、窗口采集、后台识别 | WinCaptureV1 | 进阶推荐 | 截图性能和采集方式更强，适合和 FindText 组合 |
| 复杂视觉算法 | OpenCV | 专项使用 | 适合模板匹配、特征点、轮廓、边缘等图像算法 |
| 读取自然文字 | OCR | 专项使用 | 适合不可复制文字、截图文字、题目和票据类内容 |
| 传统固定图片查找 | ImageSearch | 了解即可 | 依赖图片文件，受缩放和素材变化影响大，效率和维护性一般 |
如果只记一条：找图优先 FindText，不要把 ImageSearch 当成默认方案。 ImageSearch 能做的固定图标、按钮、文字形状识别，FindText 基本都能做，而且后期维护体验通常更好。
二、FindText：找图找字的主力方案
FindText 的强大之处，是它把屏幕上的图形或文字特征转换成一段可保存、可复制、可放进脚本里的 Text 字符串。这样你不需要额外带一堆 png 图片文件，也不容易遇到路径、打包、图片丢失的问题。对于 AHK 脚本分享和长期维护来说，这一点非常舒服。
站内 FindText v1 版 和 FindText 深度教程 都是高浏览文章，也说明它确实是 AHK 用户最常用、最受欢迎的库之一。新手学找图找字，不建议只停留在 ImageSearch，应该尽早把 FindText 学起来。
#Requires AutoHotkey v1.1
#NoEnv
#SingleInstance Force
CoordMode, Mouse, Screen
#Include
; Text 需要用 FindText 自带抓图工具生成，这里只放占位示例
Text := "|<确定>*150$18.zzzzzzzzzzzzzzzz"
if (ok := FindText(0, 0, A_ScreenWidth, A_ScreenHeight, 0, 0, Text)) {
x := ok[1].x
y := ok[1].y
MouseMove, %x%, %y%, 0
Click
} else {
MsgBox, 没找到目标特征。
}
FindText 的日常使用思路是：先用工具抓取目标按钮、图标或文字区域，生成 Text；然后在脚本里指定搜索范围；找到后取 ok[1].x、ok[1].y 执行下一步。它既能找图，也能找字，还能处理很多 ImageSearch 不太舒服的场景。
三、为什么不主推 ImageSearch
ImageSearch 是 AHK 自带命令，优点是不用安装库，写几行就能跑。站内 AHK自带命令 找图 示例带注释 可以作为基础了解。但从实战角度看，它有几个明显短板：
- 需要单独保存图片文件，脚本迁移、分享、打包时更麻烦。
- 图片路径、文件名、工作目录容易出问题。
- DPI 缩放、主题变化、按钮状态变化会导致匹配失败。
- 全屏搜索效率一般，频繁循环时更容易拖慢脚本。
- 想维护多个目标时，图片素材管理会越来越乱。
所以 ImageSearch 可以作为入门命令认识一下，但不建议作为长期主力。尤其是固定按钮、图标、文字形状这类需求，直接用 FindText 往往更省心。
CoordMode, Pixel, Screen
CoordMode, Mouse, Screen
; 这是 ImageSearch 的传统写法，可以了解，但不作为优先推荐
img := A_ScriptDir "\img\ok.png"
ImageSearch, fx, fy, 0, 0, %A_ScreenWidth%, %A_ScreenHeight%, *80 %img%
if (ErrorLevel = 0) {
Click, %fx%, %fy%
}
如果你发现自己为了 ImageSearch 截了很多张小图，还要担心图片路径、缩放、透明边缘、按钮 hover 状态，那么基本就该考虑换 FindText 了。
四、PixelGetColor：日常取色就用它
取色和找色不是一回事。只是读取鼠标所在位置、固定坐标或小范围界面状态的颜色时，日常首选 PixelGetColor；如果要在一片区域里寻找指定颜色 或者 多点找色，就用 FindText。
站内可以参考 全屏找色、单点取色比较 示例、快速获取多个颜色 By FeiYue。
CoordMode, Pixel, Screen CoordMode, Mouse, Screen ; 读取鼠标当前位置的颜色，RGB 参数让颜色按常见 0xRRGGBB 格式返回 MouseGetPos, mx, my PixelGetColor, color, %mx%, %my%, RGB ToolTip, 当前坐标：%mx%`, %my%`n颜色值：%color%
PixelGetColor 的重点是先明确坐标，再读取这个点的颜色。它适合取色、记录颜色、判断固定位置状态；如果需求变成“在一片区域里找某个颜色出现在哪里”，再换 FindText，并注意限制区域和设置容差。抗锯齿、透明度、夜间模式、远程桌面压缩，都可能让颜色产生轻微偏差。
五、WinCaptureV1：进阶截图取色找图底座
当你开始关心截图速度、后台窗口、采集方式、CPU 占用时，就可以看 WinCaptureV1。它不是简单替代 PixelGetColor、PixelSearch 或 FindText，而是更像一个高性能“截图取图底座”。站内 最快的截图取色找图库-WinCaptureV1封装调用 浏览量很高，说明这类需求非常常见。
更推荐的进阶组合是：WinCapture 负责截图，FindText 负责识别。 这也是 FindText + WinCapture 结合使用 By FeiYue 这类文章的价值所在。前者解决“怎么更快、更稳定地拿到画面”，后者解决“怎么识别画面里的目标”。
; 推荐思路：把截图和识别拆开
; 1. 先确定窗口或区域
; 2. 用 WinCapture 获取更稳定的截图数据
; 3. 用 FindText / 找色逻辑识别目标
; 4. 找不到时降低频率，避免无 Sleep 死循环
SetTimer, CheckTarget, 200
return
CheckTarget:
; 这里接 WinCaptureV1 的截图函数
; 再接 FindText 或颜色判断
return
如果你的脚本只是偶尔找一次按钮，不一定要马上上 WinCapture。但如果你要持续监控画面、频繁识别、做后台截图或多窗口识别，WinCaptureV1 就很值得研究。
六、OpenCV：复杂视觉算法才需要
OpenCV 很强，但不适合拿来解决所有找图问题。它更适合模板匹配、特征点匹配、轮廓检测、边缘检测、颜色空间转换等图像算法场景。站内可以参考 OpenCV-DXGI截图-多线程屏幕找图-模板匹配-特征点匹配、OpenCV实现人脸识别DynamicFace、OpenCV截图搜图+Bitmap转MAT示例。
我的建议是：普通找图找色先 FindText，普通取色先 PixelGetColor，需要高性能截图再 WinCapture；只有当目标存在旋转、缩放、变形、多目标、相似度评分、轮廓分析这些需求时，再考虑 OpenCV。
七、OCR：读自然文字，不是替代 FindText
OCR 适合读取自然文字，比如截图里的题目、订单号、聊天内容、不可复制的界面文字。站内可以看 PaddleOCR_通用文字识别 精简版、Win自带API实现OCR识别、纯API调用在线百度OCR示例、字符串相似性比较+OCR答题的实际应用。
但 OCR 不应该用来替代所有找图找字。固定 UI 文字、按钮字样、图标特征，FindText 往往更快、更稳定，也更容易控制误判。OCR 更适合“内容会变化、文字本身需要读出来”的场景。
八、推荐组合路线
- 固定按钮 / 图标 / 小区域文字 / 区域找色：优先 FindText。
- 颜色状态 / 状态灯 / 血条：固定点取色优先 PixelGetColor。
- 高频识别 / 后台截图：WinCaptureV1 + FindText。
- 复杂图像算法：OpenCV。
- 自然语言文字识别：OCR + 字符串清洗 / 相似度判断。
- 传统简单示例：ImageSearch 可以了解，但不作为主推。
这套选择思路和 AHK 自动化到底该用哪种方法 是一致的：先选最贴近任务的方法。找图找色不是工具越重越好，也不是命令越原生越好，而是后期越好维护越好。
九、找不到目标时怎么排查
- 搜索区域太大：能搜小区域就不要全屏搜。
- DPI 缩放变化：125%、150% 缩放会影响图片和文字形状。
- 界面主题变化：浅色、深色、悬停态、禁用态都可能影响识别。
- 颜色容差太死：找色要给合理误差，特别是渐变和抗锯齿区域。
- 循环太快：找图找色不要写无 Sleep 死循环，容易占 CPU。
- 素材维护混乱：如果 ImageSearch 图片越来越多，优先考虑 FindText 文本化管理。
- 窗口截图方式不对：前台能识别、后台不能识别时，考虑 WinCaptureV1。
十、最终建议
如果你是 AHK 新手，我建议这样学：先掌握 PixelGetColor 解决日常取色，然后重点学 FindText 的找图找色，把它作为找图找字的主力；再学习 WinCaptureV1，把截图性能和后台能力补上。ImageSearch 不用完全忽略，但不要把它当成主推方案。
FindText 的优势不是“能不能找”，而是“找得到、好保存、好分享、好维护”。这也是它能成为 AHK 圈常用库的原因。
