根本原因是vscode调试器介入过晚导致内存泄漏点无法捕获，必须用node --inspect手动启动后attach；puppeteer未销毁实例致detached dom堆积；扩展宿主与chromium子进程内存易混淆；字体缓冲区未释放加剧泄漏。
为什么Puppeteer生成PDF后VSCode内存不释放
根本原因不是Puppeteer本身，而是VSCode调试器介入时机太晚——launch.json里用type: "node"启动进程时，V8堆从require阶段开始的闭包、缓存、未清理的setInterval全被跳过，泄漏点根本进不了快照。必须改用node --inspect=9229 app.js手动启动，再让VSCodeattach，才能捕获真实泄漏起点。
Puppeteer实例未销毁导致Detached DOM堆积
常见于循环调用screenshot()或pdf()后没显式关闭page和browser。Chrome DevTools Memory面板里会大量出现Detached DOM tree，类型多为HTMLDivElement或CanvasRenderingContext2D，Retained Size持续上涨。
- 每次
browser.newPage()都创建新渲染上下文，不page.close()就卡在Detached状态 -
browser.close()必须在page.close()之后调用，否则残留页面引用 - 若用
headless: "new"模式，还需确认Chromium进程是否真退出（Linux下ps aux | grep chromium验证）
VSCode扩展宿主与Puppeteer子进程内存混淆
执行Developer: Open Process Explorer时，别只盯着renderer或main进程——Puppeteer启动的Chromium子进程内存会算在extensionHost里，尤其当插件封装了PDF生成逻辑时。真正泄漏源可能藏在extensionHost的堆快照中，而非你认为的Node子进程。
- 对比快照前，先用
code --inspect-extensions=9333单独 attach 扩展宿主进程 - 筛选
Constructor为ArrayBuffer或TypedArray的对象，它们常是PDF二进制缓冲区未释放 - 检查
Closure类型里是否有pdfBuffer、htmlContent等变量名，Retainers链若指向webview或context，说明插件层缓存失控
PDF生成中的字体与资源缓存陷阱
中文PDF导出失败常因字体加载阻塞，但更隐蔽的问题是：Puppeteer内部缓存了字体文件句柄，而VSCode调试器无法触发其GC。表现为chrome://inspect里Memory面板中ArrayBuffer数量随PDF生成次数线性增长。
- 避免在循环中重复调用
page.pdf()，改用单次page+ 多次page.setContent()+page.pdf() - Linux服务器务必安装
fontconfig和Noto Sans CJK，否则Puppeteer会不断重试加载字体并缓存失败句柄 - 临时方案：在
puppeteer.launch()里加args: ['--disable-gpu', '--no-sandbox']，减少GPU资源绑定泄漏
