简介这是面向Windows 64位平台的Chrome无头浏览器可执行包版本为129.0.6668.59适用于需要在不渲染图形界面的环境中运行浏览器自动化任务的开发者、测试工程师及CI/CD集成场景。通过搭配ChromeDriver可完成页面访问、元素操作、Cookie读取等Web自动化测试工作尤其适合服务端后台任务或资源受限环境。压缩包共125个文件主要包含headless_shell主程序及exe可执行文件、dll动态链接库、pak资源文件、hyb二进制数据、以及json、js、dat等配置与快照文件整体大小约100.37MB结构清晰可直接解压使用。目前已有397人学习下载。该版本与Chrome 129.0.6668.59功能对齐解压后即为可运行的headless shell便于开发者快速搭建无头浏览器环境、编写自动化脚本或集成到测试框架中同时也有助于理解Chrome无头模式的组件构成与运行依赖。 前一阵帮客户做数据平台的定时报表截图需要在Windows Server上跑一个无头浏览器每天生成几十张页面截图再拼成邮件附件。一开始图省事直接装了完整版Chrome用--headlessnew跑结果机器上残留一堆进程内存占用还高得离谱。后来翻到Chrome官方分发的chrome-headless-shell-win64-129.0.6668.59这类独立二进制包才发现这个专门给自动化场景用的瘦身浏览器才是对口的工具。这篇文章我把从下载、命令行验证、接入自动化框架到真实项目落地的完整过程都写出来包括我在Windows上踩过的坑希望对刚接触无头浏览器的朋友有帮助。1. 为什么Chrome团队要单独拆一个headless shell出来1.1 从旧无头模式到现在的产物线Chrome做无头模式不是一天两天了早年是在完整Chrome里加一个--headless开关跑但这个旧实现和用户实际用的渲染行为有不少差异自动化脚本里经常出现本地正常、无头环境就变样的问题。Chrome 112以后官方把无头模式的重心切换到--headlessnew行为和完整Chrome几乎一致。可问题跟着来了自动化任务真正需要的只是能解析HTML、执行JS、渲染出结果这部分能力根本用不上下载管理器、系统托盘图标、自动更新服务这些拖油瓶。Chrome团队于是维护了一条独立的产物线叫Chrome for Testing里面专门有一个chrome-headless-shell和主版本号同步发布。129.0.6668.59对应的是Chrome 129内核2024年下半年发布的版本win64后缀代表Windows 64位。拿它做爬虫、自动化测试、报表截图属于真正的对症下药。1.2 它和完整Chrome的真实差距我实际对比过chrome-headless-shell压缩包大概一百多兆解压后也远小于完整Chrome的安装目录里面没有Google Update、没有后台服务、没有默认浏览器注册逻辑就是一个可以直接丢到服务器上跑的可执行文件加一堆配套DLL。启动后的进程树也更清爽完整Chrome打开一个标签往往会拉起渲染进程、GPU进程、网络进程一大家子这个shell在简单页面下明显更瘦。代价也直白不支持浏览器扩展不提供下载管理很多面向消费者的功能被砍掉了。但对自动化来说这些恰恰是噪音。做这行最怕的就是功能没用到资源全被吃掉。2. 在Windows上把环境搭起来下载、解压与首次验证2.1 去哪里下载、选哪个版本下载不要走第三方站点直接看Chrome for Testing的官方渠道。Google维护了一个last-known-good-versions.json接口里面会给出版本号和对应的下载地址也可以直接把URL里的版本号替换成129.0.6668.59下载对应平台的zip包。下载后解压找到目录里的chrome-headless-shell.exe这就是核心了。关于版本选择我的建议是固定版本目录比如C:\tools\chrome-headless-shell-129\。不要解压到桌面更不要放到带空格的用户目录下。Windows环境下很多自动化工具对路径里的空格和中文支持不好这个我后面还会细说总之尽量让路径保持全英文、无空格、无特殊符号。2.2 命令行第一次跑通打开PowerShell或cmd先跑一个最简单的命令验证可执行文件是否正常C:\tools\chrome-headless-shell-129\chrome-headless-shell.exe --headless --disable-gpu --dump-dom https://example.com正常情况会把目标页面的DOM直接打到标准输出。--dump-dom是我拿到新版本后第一个跑的参数用来验证能不能正常工作。然后再试截图chrome-headless-shell.exe --headless --disable-gpu --screenshotC:\tmp\page.png --window-size1280,800 https://example.com有个细节--screenshot后面要跟完整的Windows路径如果目录不存在它也不报错就是不出图。排查时先确认目录存在、路径拼接正确别一上来就怀疑浏览器坏了。2.3 几个高频启动参数--user-data-dir指定用户数据目录。不加的话每次启动都用临时目录Cookie和登录态存不住。做需要登录的自动化这个参数必须给。--no-sandboxWindows上一般不强制但某些远程桌面环境和终端服务环境下不加上可能启动失败报错信息还特别让人摸不着头脑。--virtual-time-budget虚拟时间预算。让浏览器在虚拟时间里加速等待指定毫秒数对SPA页面截图特别有用后面细说。--remote-debugging-port打开调试端口配合CDP协议做精细控制。--disable-gpu服务器上基本没有GPU可用显式关闭能避免一部分兼容性警告。3. 接入自动化框架Puppeteer、CDP直连与Selenium的取舍3.1 Puppeteer指定可执行文件用puppeteer-core是最干净的方式它不会自动下载浏览器路径完全由你控制const puppeteer require(puppeteer-core); const browser await puppeteer.launch({ executablePath: C:\\tools\\chrome-headless-shell-129\\chrome-headless-shell.exe, headless: true, args: [--disable-gpu, --no-first-run] }); const page await browser.newPage(); await page.goto(https://example.com, { waitUntil: networkidle2 }); await page.screenshot({ path: C:\\tmp\\page.png, fullPage: true }); await browser.close();这里有个容易混淆的点不带-core的puppeteer包默认会在自己缓存目录里下载并管理Chrome和chrome-headless-shell版本管起来很绕。干脆用puppeteer-core加显式executablePath整个行为就完全透明了。出问题的时候你能确定用的是哪个浏览器这是一个很大的排查优势。3.2 不引入框架直接用CDP协议控制如果不想为一个小功能引入整个Node依赖走CDP协议是最直接的。启动时开调试端口chrome-headless-shell.exe --headless --disable-gpu --remote-debugging-port9222 --user-data-dirC:\tmp\cdp-profile about:blank然后访问http://127.0.0.1:9222/json/version拿到webSocketDebuggerUrl用任何支持WebSocket的语言连上去发Page.navigate、Runtime.evaluate、Page.captureScreenshot这些命令。我在写跨语言定时任务时经常用这条路径因为不绑定某个SDK以后换语言接入成本最低。3.3 Selenium的搭配建议如果你项目里已经有一堆Selenium用例也可以把ChromeDriver指向这个shell来跑但要注意ChromeDriver的版本必须和Chrome 129这条线匹配否则握手阶段就会报错。我的个人意见是Selenium的老用户别折腾迁移直接用完整Chrome加ChromeDriver更省心新项目、脚本化的任务才建议用Puppeteer或CDP配这个shell。工具没有绝对优劣只有适不适合当前场景。4. 真实项目里的几种打开方式4.1 大批量页面截图巡检给内部系统做每日巡检几十个页面挨个截图是我用得最多的场景。启动一个浏览器实例按清单依次访问关键在于控制每个页面的等待时间和超时。shell模式下页面加载失败不会自己退出脚本必须给每个页面加超时保护否则一个坏页面就能让整个巡检任务卡死到第二天早上。我的做法是每个页面单独try-catch失败就把URL记录下来最后统一生成一份巡检报告而不是中断整个流程。4.2 抓取JS渲染的数据很多网站的正文数据是前端通过接口异步加载的直接用curl拿HTML什么都拿不到。这种场景shell可以顶上访问页面、等数据渲染、再抓取DOM。配合--virtual-time-budget5000让页面在虚拟时间里等5秒真实耗时可能只有一两秒比傻等setTimeout效率高得多。有意思的是这种虚拟时间机制还能让一些懒加载图片提前加载完成截图或抓取时不容易出现空白区域。4.3 自动化测试的冒烟回归在CI里跑冒烟测试shell的价值在于启动快、进程干净。一个检查脚本就能干这个事跑--dump-dom再用字符串匹配或正则判断关键内容是否出现。不需要完整的断言框架一条命令就能确认核心页面没挂。对发布前检查这类需求这种轻量确认往往比大而全的端到端测试更实用。4.4 Windows计划任务里的一条龙在Windows Server上最省事的做法是直接用任务计划程序每天早上调用一个脚本访问几个报表页面、生成截图、调用邮件发送。整个链路不需要安装任何语言运行时核心步骤就是一条shell命令加一个PowerShell脚本。实测跑了好几个月稳定性完全可以接受。5. 实测中踩过的坑与排查思路5.1 进程不退出怎么处理命令行方式执行完截图后有时候进程不会自动退出这在某些版本上是个老毛病。我写脚本时最后都会加一层兜底清理taskkill /F /IM chrome-headless-shell.exe如果用了Puppeteer则在Node侧用try-finally保证browser.close()一定执行。但脚本中途抛异常时进程仍可能残留所以外层定时任务里再加一次进程清理是必须的。宁可错杀不能让僵尸进程越积越多把服务器内存吃光。5.2 Windows Server上的中文字体问题这是个特别隐蔽的坑。服务器没装中文字体时页面渲染看起来正常截图也成功但里面中文全部是方块。我第一次遇到以为是页面样式问题折腾了半天才发现是系统字体缺失。解决办法很直接给Windows Server安装微软雅黑等中文字体或者把开发机上的字体文件复制过去重启后刷新字体缓存。5.3 用户数据目录冲突多个shell实例共用同一个--user-data-dir时后启动的实例会直接失败因为浏览器认为已有实例在运行。并行任务必须给每个实例分配独立目录或者在启动脚本里生成随机临时目录。这个问题多人协作时尤其容易犯一个人写的脚本在本地跑没事放到CI上多任务并行就崩了。5.4 版本匹配引发的静默失效chrome-headless-shell的版本和ChromeDriver、Puppeteer等三方库的版本必须大致匹配。129.0.6668.59 这个版本相对较新如果配套Node库版本太旧会出现启动正常但执行某些命令没反应的诡异现象。遇到这种情况先查框架的版本支持文档不要把时间浪费在排查业务代码上。5.5 闪退问题的排查手段如果shell启动就闪退用下面这条命令把日志打出来chrome-headless-shell.exe --headless --enable-loggingstderr --v1 --dump-dom https://example.com能直接看到是缺DLL、缺依赖还是参数冲突。另外开了--remote-debugging-port后用浏览器访问/json/version也可以确认调试服务是否正常起来。6. 性能调优与资源控制经验6.1 多实例并发时的内存压测shell多开时每个实例都有独立的渲染进程和网络进程内存占用大约是完整Chrome的六成左右但开多了依然扛不住。实测压下来--renderer-process-limit1和--utility-process-limit这两个参数配合使用能把并行任务的内存峰值压下去不少。注意这两个参数在Windows上的表现和Linux略有差异最好压测后在当前机器上验证一遍。6.2 页面加载提速的实用参数只关心文字内容或数据结构时可以禁用图片加载--blink-settingsimagesEnabledfalse大图多的页面提速特别明显。还有--js-flags--max-old-space-size512限制JS堆内存防止某个极端页面把整个机器拖死。对于定时任务这种长期运行的程序这类资源兜底参数比业务逻辑本身更重要。6.3 常用参数组合速查场景推荐参数快速验证--headless --dump-dom URL页面截图--headless --screenshot路径 --window-size宽,高 URLSPA等待渲染--headless --virtual-time-budget5000 --dump-dom URL多实例并发--headless --user-data-dir独立目录 --disable-gpu --renderer-process-limit1CDP精细控制--headless --remote-debugging-port9222最后分享一个我自己的习惯所有版本的chrome-headless-shell都统一放在一个目录下目录名就是版本号绝不叫最新或old这类模糊名字。每次Chrome发大版本就去官方JSON接口拿新链接下载后先命令行验证一遍再改自动化脚本里的exe路径。这样即使新版本出问题也能立刻回退到上一个版本整个过程不需要去翻当初装的是哪个版本这种记忆。自动化工具这东西版本可控心里就不慌。本文还有配套的精品资源点击获取