云函数触发"Error: could not handle the request"，如何排查非内存/时间类限制？

• 深挖全链路日志
  不要只依赖监控面板的汇总指标，必须抓错误发生时的详细调用日志：

  • 在Puppeteer相关代码（page.goto()、page.pdf()）外层加try-catch，捕获并打印所有内部错误，包括页面加载超时、资源加载失败、渲染异常等，这类错误有时候不会触发顶层的函数报错，但会导致PDF生成失败
  • 对自调用合并PDF的环节，记录每次自调用的HTTP状态码、响应内容，排查是否存在自调用被限流、目标URL返回5xx错误，或者请求参数过大被截断的情况
  • 在PDF合并逻辑（比如使用pdf-lib、pdf-merge等库）中加入异常捕获，打印合并过程中的文件损坏、内存溢出隐性报错

• 检查云函数隐性限制
  除了内存和执行时间，服务商通常还有其他容易忽略的限制：

  • 临时存储配额：长文档生成的临时PDF文件可能占满云函数的临时磁盘空间（多数服务商默认临时空间为1-5GB），可以在代码中打印临时目录的剩余空间（Node.js可使用fs.statfs()）
  • 网络带宽/速率限制：渲染复杂HTML或下载多个PDF时，带宽耗尽会导致请求超时，监控面板可能不展示带宽指标，需要在代码中统计资源加载耗时
  • 并发调用限制：自调用短时间内发起多个请求时，可能触发服务商的并发配额限制，导致部分调用被拒绝

• 排查Puppeteer的隐性问题

  • 确保每次调用后正确销毁资源：每次生成PDF后必须调用page.close()和browser.close()，避免无头浏览器实例泄漏，即使内存没到上限，过多的实例也会导致资源耗尽
  • 复杂文档渲染要等待资源加载完成：长文档可能包含大量异步加载的图片、字体，需要在page.pdf()前添加等待逻辑（比如await page.waitForNavigation({waitUntil: 'networkidle2'})，或等待特定元素加载完成），否则可能出现渲染不完整或隐性失败

• 验证自调用环节的稳定性

  • 测试自调用的负载能力：当函数处于高负载时（比如生成超长文档），发起自调用是否会出现请求超时或失败
  • 检查自调用的参数大小：如果通过请求体传递PDF片段或配置，确认是否超过服务商允许的HTTP请求大小限制（通常为几MB到几十MB）

• 模拟极端场景压测

  • 手动构造最长、最复杂的测试文档，反复调用函数，同时在代码中实时打印内存使用（process.memoryUsage()）、临时磁盘占用、资源加载耗时等数据，定位错误发生时的具体异常指标
  • 拆分流程单独测试：分别测试Puppeteer生成超长PDF、多PDF合并两个环节，确认哪一步是错误的触发点

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