Firebase下Puppeteer PDF超时，Chrome版本问题，本地MacOS运行正常

首先拆解你看到的报错信息：

1. 核心触发条件是Puppeteer启动Chromium进程后，在30秒默认超时时间内没有和浏览器的远程调试端口建立通信连接，才会抛出TimeoutError
2. 报错里提到的Only Chrome at revision r818858 is guaranteed to work是Puppeteer的固定提示模板内容，不是报错根因——只要浏览器启动失败，不管是何种原因，都会附带这句版本提示，不代表你当前安装的Chromium版本真的不兼容。
3. 本地Mac运行正常、上传到Firebase云函数就超时，本质是本地开发环境和云函数容器环境的运行差异导致浏览器进程根本没成功启动，自然没法建立连接。

• 部署打包错误：如果是本地执行npm install后直接把整个node_modules目录打包上传到云函数，本地Mac环境安装的Puppeteer会下载适配darwin架构的Chromium二进制，传到Linux x64架构的云函数容器里时，这个二进制根本没有执行权限、没法直接运行，启动即失败
• 系统依赖缺失：云函数的Debian精简容器没有预装Chromium运行需要的系统依赖库，就算架构匹配，Chromium启动时因为缺依赖直接崩溃退出
• 容器资源限制不足：默认云函数的共享内存块大小只有64MB，Chromium正常运行需要更大的共享内存空间，会导致进程卡死；如果云函数配置的内存低于1GB，Chromium启动时容易被系统OOM机制直接杀掉
• 启动参数不匹配：当前代码只加了--no-sandbox参数，没有针对容器环境补全禁用沙箱、绕开共享内存限制的必要参数，浏览器进程启动时权限校验不通过直接退出

• 调整部署逻辑：不要本地打包上传node_modules，让Firebase部署流程在云函数的Linux环境下自动执行依赖安装，确保下载的Chromium是适配Linux x64架构的版本
• 补全Puppeteer启动的必要参数，参考调整后的代码片段：

const browser = await puppeteer.launch({
  headless: 'new',
  timeout: 60000, // 把默认30秒连接超时拉长，适配冷启动节奏
  args: [
    '--no-sandbox',
    '--disable-setuid-sandbox', // 配合沙箱禁用的必要参数
    '--disable-dev-shm-usage', // 把共享内存访问切到/tmp目录，解决shm不足问题
    '--single-process' // 容器环境下减少多进程权限冲突
  ]
});

• 把对应云函数的内存配置调整到1GB及以上，避免Chromium启动时被OOM机制终止
• 不要被报错里的Chrome版本提示误导去盲目升级/降级Puppeteer版本，绝大多数场景下版本错配不是根因

内容的提问来源于stack exchange，提问作者juliusphysics