简介本资源为面向Windows 64位系统的Chrome浏览器稳定版离线安装包适合普通用户日常上网、办公及开发者进行网页调试与兼容性测试。压缩包共308个文件以223个pak资源包、52个hyb数据文件、10个dll动态库、7个exe可执行程序及若干json、js、dat等配置与脚本文件为主整体约173.03MB解压后即可获得完整的浏览器运行环境。该版本号145.0.7632.46属Stable稳定分支经过多轮测试内置沙盒隔离与自动更新机制兼顾安全性与性能64位架构在处理大量数据和资源密集型任务时表现更优。开发者可借助其内置开发者工具完成网页调试、性能分析与代码编辑。目前已有55人学习下载适合需要离线部署、版本固定或批量安装Chrome的用户参考使用。1. 拿到 chrome-win64-145.0.7632.46 这个包先别急着双击上周帮一个做前端自动化的朋友排查环境问题他本地跑 Playwright 脚本一直报browserType.launch: Executable doesnt exist折腾了一下午最后发现是他从某个渠道拿的 Chrome 压缩包解压后目录结构不对chrome.exe被套了两层文件夹脚本里配的executablePath自然找不到。这类问题在离线部署、CI 固定浏览器版本、内网测试机这些场景里特别常见——你手上有一个chrome-win64-145.0.7632.46(Stable).zip但怎么把它变成一个「能跑起来、能被脚本调用、版本号对得上」的浏览器中间其实有好几个坑。这个包本质上就是 Chrome 稳定版 145.0.7632.46 的 Windows 64 位免安装压缩版解压即用不需要走安装程序也不会往注册表里写东西。它适合三类人一是需要在多台机器上锁定同一个浏览器版本做兼容性测试的二是 CI/CD 流水线里不想每次跑apt install或联网下载的三是内网环境根本连不上外网、只能靠离线包分发的。如果你只是想在自己电脑上日常上网那直接装官方安装版更省事这个包的价值在于「可控」和「可复制」。2. 解压与目录结构为什么你的 chrome.exe 总是找不到2.1 压缩包里的真实布局拿到这个 zip 之后很多人习惯性右键「解压到当前文件夹」然后得到一个叫chrome-win64的文件夹里面再套一层同名文件夹chrome.exe躺在最里面。这个多出来的层级就是脚本找不到可执行文件的头号原因。正常的解压结果应该是这样的chrome-win64/ ├── chrome.exe ├── chrome.dll ├── chrome_100_percent.pak ├── chrome_200_percent.pak ├── resources.pak ├── icudtl.dat ├── v8_context_snapshot.bin ├── locales/ │ ├── en-US.pak │ └── zh-CN.pak ├── swiftshader/ └── ...其余依赖文件关键判断标准chrome.exe必须和chrome.dll、resources.pak在同一层。如果你解压出来发现chrome.exe上面还有一层chrome-win64说明解压工具多建了一层目录手动把内层所有文件剪切到外层即可。用命令行解压更可控Windows 10 以上自带的tar就能处理 zip# 先看清楚压缩包内部的顶层结构别盲目解压 tar -tf chrome-win64-145.0.7632.46\(Stable\).zip | head -20 # 解压到指定目录避免污染当前工作区 mkdir -p D:\browsers\chrome-145 tar -xf chrome-win64-145.0.7632.46\(Stable\).zip -C D:\browsers\chrome-145tar -tf只列出内容不解压这一步能帮你确认压缩包内部是不是已经有一层chrome-win64/。-C参数指定解压目标目录比右键解压后再手动搬文件靠谱得多。解压完检查一下D:\browsers\chrome-145\chrome-win64\chrome.exe是否存在存在就说明层级对了。2.2 验证版本号是否真的是 145.0.7632.46解压完别急着用先确认版本号。有些渠道的包文件名写的是一个版本实际内容是另一个这种「挂羊头卖狗肉」的情况在第三方镜像站不少见。验证方法有两种# 方法一直接查文件版本信息Windows wmic datafile where nameD:\\browsers\\chrome-145\\chrome-win64\\chrome.exe get Version /value # 方法二启动后看版本页 D:\browsers\chrome-145\chrome-win64\chrome.exe --version--version参数在 Windows 上有时不会输出到控制台而是弹窗更稳的方式是启动后访问chrome://version看第一行的版本号。如果显示的不是145.0.7632.46那这个包就有问题别往下用了。版本号对不上会导致两个后果一是你针对 145 写的兼容性测试结论无效二是某些依赖特定 API 的自动化脚本会行为异常。3. 让自动化脚本认到这个 Chrome路径配置与启动参数3.1 Playwright / Puppeteer 里怎么指向它这是这个包最高频的使用场景。Playwright 默认会去下载自己管理的浏览器但离线环境或者你想固定版本时就得手动指定executablePath。以 PlaywrightNode.js为例// playwright-launch.js const { chromium } require(playwright); (async () { const browser await chromium.launch({ // 指向你解压出来的 chrome.exe 绝对路径 executablePath: D:\\browsers\\chrome-145\\chrome-win64\\chrome.exe, headless: false, args: [ --no-first-run, // 跳过首次运行引导 --no-default-browser-check, // 不检查默认浏览器 --disable-featuresTranslate, // 关掉翻译弹窗 ], }); const page await browser.newPage(); await page.goto(https://example.com); console.log(await page.title()); await browser.close(); })();executablePath必须是绝对路径反斜杠要转义。--no-first-run和--no-default-browser-check这两个参数在自动化场景里几乎是必加的否则每次启动都可能弹引导页干扰脚本执行。Puppeteer 的写法类似参数名也是executablePath放在launch的配置对象里。Python 版的 Playwright 写法# playwright_launch.py from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch( executable_pathrD:\browsers\chrome-145\chrome-win64\chrome.exe, headlessFalse, args[--no-first-run, --no-default-browser-check], ) page browser.new_page() page.goto(https://example.com) print(page.title()) browser.close()注意 Python 里用原始字符串r...避免反斜杠转义问题。如果你在 CI 里跑路径最好通过环境变量传入别硬编码否则换台机器就翻车。3.2 常用启动参数与适用场景除了上面两个还有几个参数在实际项目里很实用参数作用什么时候用--user-data-dir路径指定用户数据目录需要保持登录态、Cookie 时--headlessnew新版无头模式CI 环境跑不需要界面--disable-gpu禁用 GPU 加速虚拟机、无显卡服务器--window-size1920,1080固定窗口尺寸截图、视觉回归测试--proxy-serverhost:port指定代理内网需要走统一出口时--user-data-dir特别值得说一句。默认情况下每次启动都是全新会话登录态不保留。如果你做的是需要登录后才能访问的页面测试就得指定一个固定目录让 Cookie 和 LocalStorage 持久化。但注意别多个脚本实例同时用同一个user-data-dirChrome 会锁目录第二个实例直接启动失败。# 手动启动一个带独立数据目录的实例方便调试 D:\browsers\chrome-145\chrome-win64\chrome.exe ^ --user-data-dirD:\chrome-profiles\test01 ^ --no-first-run ^ --window-size1920,1080Windows 命令行里换行用^在 PowerShell 里用反引号。这个手动启动方式适合你先确认浏览器本身没问题再去调脚本。4. 避坑与排查五个真实翻车现场4.1 现象脚本报 “Executable doesnt exist” → 原因路径层级或转义错误 → 解决用绝对路径并确认文件存在这是最高频的问题。除了前面说的多一层目录还有一个隐蔽原因是路径里有空格或中文某些版本的 Playwright 对这类路径处理有 bug。解决办法是把浏览器解压到纯英文、无空格的路径下比如D:\browsers\chrome-145\。另外在 Node.js 里写 Windows 路径D:\browsers里的\b会被当成转义字符必须写成D:\\browsers或用path.join拼接。4.2 现象浏览器启动后闪退 → 原因缺少 VC 运行库或解压不完整 → 解决补运行库、重新解压Chrome 依赖 Microsoft Visual C Redistributable。如果目标机器是刚装好的干净系统可能没装这个运行库chrome.exe双击一闪就没了。去装一个 VC 2015-2022 x64 运行库即可。另一个原因是解压过程中断了chrome.dll不完整重新解压一遍解压时关掉杀毒软件的实时监控有些杀软会误删 Chrome 的某些组件。4.3 现象版本号显示不对 → 原因包里混了旧版本文件或解压到了旧目录 → 解决清空目录重新解压如果你之前在同一目录解压过旧版本新文件覆盖旧文件时可能残留旧版 DLL导致版本号混乱。最稳妥的做法是每次换版本都用一个全新目录别在旧目录上覆盖。解压完用chrome://version确认别信文件名。4.4 现象多实例同时启动失败 → 原因user-data-dir 被占用 → 解决每个实例分配独立目录Chrome 对用户数据目录加锁同一个目录同时只能有一个实例。如果你并行跑多个测试脚本每个脚本必须用不同的--user-data-dir。常见做法是用进程 ID 或时间戳生成目录名const path require(path); const os require(os); const userDataDir path.join(os.tmpdir(), chrome-profile-${process.pid}-${Date.now()});这样每次启动都是干净且独立的会话跑完可以顺手删掉临时目录。4.5 现象无头模式下截图空白或字体乱码 → 原因缺少字体或 GPU 渲染问题 → 解决加--disable-gpu并安装中文字体在 Linux 容器里跑 Windows 版 Chrome 不现实但如果你是在 Windows Server 核心版上跑无头模式可能遇到截图全白。加--disable-gpu和--font-render-hintingnone通常能解决。中文字体乱码则是系统没装中文字体装一个思源黑体或微软雅黑即可。这个包本身不带字体字体是系统级的。5. 进阶把固定版本 Chrome 塞进 CI 流水线的一个小技巧前面讲的都是单机操作但真正体现这个包价值的地方是 CI。假设你用 GitHub Actions 或者自建的 Jenkins每次跑测试都希望用完全相同的 Chrome 版本而不是让 Playwright 去下载最新版。做法是把解压后的chrome-win64目录打包成一个制品artifact在流水线里解压到固定路径然后通过环境变量传给测试脚本。以 GitHub Actions 为例核心步骤大概是这样# 片段示意不是完整 workflow - name: Restore Chrome 145 run: | tar -xf chrome-win64-145.0.7632.46.zip -C ${{ runner.temp }} echo CHROME_PATH${{ runner.temp }}\chrome-win64\chrome.exe $env:GITHUB_ENV - name: Run tests run: node playwright-launch.js env: CHROME_EXECUTABLE: ${{ env.CHROME_PATH }}脚本里改成从process.env.CHROME_EXECUTABLE读路径这样本地和 CI 用同一套代码只是环境变量不同。这个习惯我坚持了两年多最大的好处是「本地能跑CI 就能跑」不会再出现本地通过、流水线挂掉的玄学问题。还有一个细节CI 机器上通常没有--user-data-dir的持久化需求每次都是全新会话所以可以放心用临时目录。但记得在流水线结束前清理否则磁盘会被一堆 profile 目录撑满。我一般会在afterAll钩子里加一句删除逻辑或者直接用系统的临时目录让 runner 自己回收。从那以后我每次拿到一个新的浏览器离线包都强制走一遍「解压 → 验证版本 → 手动启动 → 脚本调用」这四步确认没问题再往 CI 里塞。希望帮到你。本文还有配套的精品资源点击获取