Codex 调用 Chrome 速度慢？这几个优化技巧让你的环境起飞

最近发现不少朋友在用 Codex 这类 AI 编程助手时，都遇到了一个让人抓狂的问题：调用 Chrome 进行网页渲染或测试时，速度慢得像在拨号上网。

本来想着让 AI 帮我快速写个爬虫或者自动化脚本，结果光等浏览器加载就花了大半天，这就有点“杀鸡用牛刀”最后牛刀还生锈的意思了。作为一个天天和各种开发环境打交道的博主，今天就借这个话题，和大家深聊一下为什么 Codex 调用 Chrome 会这么慢，以及我们到底该怎么优化。

为什么会这么慢？

无头模式抛弃了图形界面，能有效降低资源消耗。

首先我们得搞清楚，这不是 Codex 本身的问题，很多时候是浏览器运行环境的配置掉链子了。

当我们通过代码（比如 Puppeteer 或 Selenium）启动 Chrome 时，默认配置往往是为“图形化界面”准备的。这意味着它会加载一堆我们根本不需要的东西：扩展程序、复杂的渲染特效、甚至 GPU 加速。在服务器环境或者资源受限的容器里，这些多余的开销就是卡顿的元凶。

内存资源争抢是导致卡顿的常见原因。

此外，如果是在虚拟机或 VPS 上跑，内存和 CPU 的争抢也是一大原因。Chrome 本身就是个吃资源大户，Codex 再在旁边跑模型，稍微配置低一点的机器马上就会顶不住，导致严重的 IO 等待，直观感受就是“卡”。

给 Chrome 减肥：无头模式是关键

要解决这个问题，第一招也是最有效的一招，就是强制开启无头模式（Headless Mode），同时关闭一切不需要的组件。

很多时候代码里只是简单写了一句 launch()，其实我们可以塞进去很多参数来让 Chrome 变得“轻量级”。比如，我们可以禁用 GPU、禁用沙箱（如果是可信环境）、忽略证书错误、甚至不加载图片。

优化启动参数示例：

虽然具体代码取决于你用的语言，但核心逻辑是一样的。我们需要告诉浏览器：“别渲染花哨的界面，只给我核心功能。”

• --headless：必须开启，不运行图形界面。
• --disable-gpu：服务器没显卡，别白费力气。
• --no-sandbox：在 Docker 或容器中常需要，解决权限卡顿。
• --disable-dev-shm-usage：这点极其重要！ 默认情况下 /dev/shm 分区太小，Chrome 崩溃或变慢多半是它惹的祸，改成用 /tmp 能稳很多。

别让资源成瓶颈

如果你的机器配置本身就比较极限，比如只有 1G 或 2G 内存，那不管怎么调参数，只要网页稍微复杂一点，还是会卡。这时候就要靠“限流”了。

在启动浏览器实例时，限制一下并发标签页的数量。不要试图一次性打开几十个页面，让 Codex 按照队列一个一个来处理。虽然听起来慢了点，但比起因为 OOM（内存溢出）导致整个环境崩盘重启，这种“排队”机制的总体效率反而更高。

还有一种情况是存储 IO 瓶颈。如果你的 VPS 是那种烂磁盘（比如老旧的 HDD 或被超卖的 NVMe），Chrome 的缓存读写会拖累一切。考虑将缓存目录挂载到内存盘（tmpfs）上，读写速度能提升一个数量级，处理速度自然就上去了。

还有这些小细节

除了上面的大方向，有时候问题出在一些不起眼的地方：

1. 网络问题：如果 Codex 需要访问国外网站，而你本地网络不给力，那慢是必然的。给 Docker 容器或者系统配置好合适的代理节点，能立竿见影。
2. 版本过旧：Chrome 和对应的驱动版本如果不匹配，或者使用了过旧版本的浏览器内核，对新特性的支持会有性能损耗。记得保持更新。
3. 阻塞式代码：检查一下你的代码逻辑，是不是在等待浏览器响应的时候写了死循环或者没有正确的异步等待？有时候是代码逻辑锁死了线程，而不是浏览器真的慢。

总结一下

Codex 调用 Chrome 慢，多半不是 AI 变笨了，而是环境太臃肿。开启无头模式、关闭不必要的硬件加速、解决 /dev/shm 容量限制，这三板斧下去，90% 的卡顿都能缓解。

技术折腾就是这样，看起来是软件问题，最后往往要在系统层面找答案。希望今天的分享能帮大家省下那些白白浪费在等待上的时间，早点把项目做完下班！