浏览器自动化怎么选：Chrome.ahk、Selenium、JS 注入、HTTP 请求

AHK 做浏览器自动化，最容易混在一起的几个概念是：控制浏览器、操作网页 DOM、注入 JS、直接请求接口。它们看起来都能“自动化网页”，但稳定性、速度、维护成本完全不一样。

这篇文章把 Chrome.ahk、Selenium、JS 注入、HTTP 请求 放在一起比较。站内相关内容里，AHK操控浏览器入门教程 浏览量很高，适合作为 Chrome.ahk 入门主线；适合AHK操控的Chrome免启动浏览器 – 百分浏览器、百分浏览器多开独立脚本控制 也很适合延伸阅读。HTTP 方向可以看 AHKhttp_搭建网页API_远程控制 和 Post发送JSON请求，并返回JSON。

一、先给结论：能请求接口，就别模拟网页

我的选择顺序通常是：先看有没有 HTTP 接口；没有接口再考虑 Chrome.ahk + JS；需要标准测试流程再考虑 Selenium；页面外壳、弹窗、浏览器 UI 再用 UIA 或 Acc 辅助。

二、HTTP 请求：最快，但要求你看懂接口

如果目标网站的操作本质上是调用接口，比如搜索、提交表单、获取列表、下载数据，那直接用 HTTP 请求通常比控制浏览器更好。它不需要加载页面、渲染 CSS、等待按钮出现，也不会受窗口焦点影响。

#Requires AutoHotkey v1.1
#NoEnv
#SingleInstance Force

url := "https://www.AutoHotkey.com/"
http := ComObjCreate("WinHttp.WinHttpRequest.5.1")
http.Open("GET", url, false)
http.SetRequestHeader("User-Agent", "AutoHotkey Browser Automation Demo")
http.Send()

MsgBox, % "状态码：" http.Status "`n`n" SubStr(http.ResponseText, 1, 300)

HTTP 请求适合做数据型自动化，不适合处理复杂页面交互。你需要在浏览器开发者工具的 Network 面板里看请求 URL、请求方法、请求头、Cookie、Token、提交参数和返回 JSON。站内 WinHttp库 By 空、发送多个异步网络请求获得返回值 也可以作为网络请求方向的补充。

三、Chrome.ahk：AHK 操控 Chrome 的主力路线

如果你需要真实打开网页、保留登录态、执行页面 JS、读取 DOM、监听页面状态，Chrome.ahk 是 AHK 用户非常常用的路线。它的底层思路是通过 Chrome DevTools Protocol 和浏览器通信。站内的 AHK操控浏览器入门教程 就是这条线的重点资料。

现在使用 Chrome.ahk 要特别注意一个变化：Chrome 136 以后，Chrome 对远程调试参数做了安全限制，调试默认用户数据目录时，--remote-debugging-port / --remote-debugging-pipe 会被忽略，必须配合非默认的 --user-data-dir。这个变化可以参考 Chrome 官方说明：Changes to remote debugging switches。所以实战中更建议给自动化单独准备浏览器用户目录，不要直接拿日常主浏览器配置硬接。

#Include <Chrome>

profileDir := A_ScriptDir "\ChromeProfile"
if !FileExist(profileDir)
    FileCreateDir, %profileDir%

ChromeInst := new Chrome(profileDir, "https://www.AutoHotkey.com")
Page := ChromeInst.GetPage()
Page.WaitForLoad()

ret := Page.Evaluate("document.title")
MsgBox, % "当前页面标题：" ret.value

Chrome.ahk 的优势是和 AHK 脚本结合自然，适合个人工具、网页辅助、半自动流程。缺点是你要理解调试端口、浏览器 profile、页面加载等待、JS 执行结果这些概念。

四、JS 注入：页面内操作优先用它

JS 注入不是单独的一套浏览器自动化框架，而是一种“进入网页内部做事”的能力。Chrome.ahk 可以执行 JS，Selenium 也可以执行 JS。只要你能进入页面上下文，填表、点击、读取文本、监听事件，很多时候都比鼠标坐标稳定。

js =
(
var input = document.querySelector('input[name="q"], textarea[name="q"], input[type="search"]');
if (input) {
    input.value = 'AutoHotkey';
    input.dispatchEvent(new Event('input', { bubbles: true }));
}
)

Page.Evaluate(js)

JS 注入的坑在于：现代前端框架不一定只认 value 变化，有时还要触发 input、change、click 等事件；有些控件在 iframe 里，跨域 iframe 不能随便操作；有些按钮看起来可点，实际由前端状态控制。站内 当前网页注入JS代码、网页搜索框录入信息并提交搜索 可以作为例子方向。

五、Selenium：更偏测试和标准 WebDriver

Selenium 的优势是标准化。它有成熟的元素定位、等待、窗口切换、iframe 切换、截图、执行 JS 等能力，适合自动化测试、跨浏览器验证、比较规范的网页流程。AHK 里常见的是通过 SeleniumBasic 这类 COM 方案调用，站内可以参考 AHK调用SeleniumBasic精简集成包。

driver := ComObjCreate("Selenium.ChromeDriver")
driver.Start("chrome")
driver.Get("https://www.baidu.com")

driver.FindElementByName("wd").SendKeys("AutoHotkey")
driver.FindElementById("su").Click()

; 实际脚本里记得按需要等待结果加载
; driver.Quit()

Selenium 不一定比 Chrome.ahk 更适合 AHK 日常脚本。它更像测试工具链，环境配置、浏览器驱动、版本匹配都要处理。如果只是自己写一个网页辅助工具，Chrome.ahk + JS 通常更轻；如果是做流程测试、跨浏览器或团队工具，Selenium 的规范性会更有价值。

六、浏览器回调与事件监听：让网页主动通知 AHK

很多网页自动化不应该写成“AHK 一直轮询页面有没有变化”。更好的思路是让网页在关键动作发生时主动回调 AHK，或者让脚本监听浏览器事件。站内 浏览器通过网页回调，与AHK协同 和 控制浏览器来监听网页事件 都是这个方向。

比如页面里按钮点击、输入框变化、任务完成、接口返回，都可以通过 JS 侧记录状态，再由 AHK 读取；或者直接把状态回传到 AHK 本地服务。这样比盲目 Sleep 或循环检查更稳定。

七、什么时候不要控制浏览器

有些任务看起来是网页自动化，实际上更适合别的方法：

• 只是调用接口：优先 HTTP 请求。
• 只是下载文件：优先 HTTP / WinHttp，不必打开网页。
• 网页内容能被接口返回：优先解析 JSON，不必读 DOM。
• 只操作浏览器外壳按钮、地址栏、标签页：可以考虑 UIA，参考 UIA窗口控制辅助增强库。
• 页面没有结构可读，只能看画面：再考虑 FindText、OCR 或图片识别。

这和 AHK 自动化到底该用哪种方法 的思路一致：先找更底层、更稳定的数据入口，再考虑模拟操作。

八、排查清单

• Chrome.ahk 连不上：检查 Chrome 是否用独立 user-data-dir 启动，端口是否被占用。
• JS 执行了但页面没反应：补触发 input、change、click 事件，确认是否被前端框架接管。
• 找不到元素：确认选择器是否正确，元素是否在 iframe、Shadow DOM 或异步加载区域里。
• Selenium 报驱动错误：检查浏览器版本、ChromeDriver 版本、SeleniumBasic 配套文件。
• HTTP 请求返回未登录：检查 Cookie、Token、Referer、User-Agent、CSRF 参数。
• 网页能点但脚本不稳定：把坐标点击换成 DOM 操作或 WebDriver 元素定位。

九、最终选择建议

如果你做的是数据提交、读取、批量处理，先研究 HTTP 请求。如果你做的是个人网页辅助工具，Chrome.ahk + JS 注入通常最顺手。如果你做的是规范化测试或跨浏览器流程，Selenium 更合适。如果你只是操作浏览器窗口外壳，UIA/Acc 可能比网页自动化更直接。

浏览器自动化的关键不是“哪个库最强”，而是先判断目标到底是接口、DOM、浏览器窗口，还是屏幕画面。入口选对了，脚本会短很多，也稳很多。