应通过node --max-old-space-size=4096显式设置堆内存上限，并结合--trace-gc、Chrome DevTools堆快照对比及files.watcherExclude精准排除监听目录来定位和解决内存泄漏，而非盲目扩容。
npm run崩溃报JavaScript heap out of memory，怎么加内存限制
这不是 VSCode 的问题，而是你执行的 npm run 启动的独立 Node 进程堆内存超限。VSCode 只是开了个终端，真正跑命令的是 CLI 工具（比如 vue-cli-service、webpack 或 ts-node），它默认只用 1.4GB 堆空间，大项目很容易爆。
- 直接改
package.json的scripts字段，在命令前加node --max-old-space-size=4096，例如："dev": "node --max-old-space-size=4096 ./node_modules/.bin/vue-cli-service serve" - Windows 下必须用
cross-env注入环境变量："dev": "cross-env NODE_OPTIONS=--max-old-space-size=4096 vue-cli-service serve"—— 直接set NODE_OPTIONS=...对 GUI 启动的终端无效 - 别装
increase-memory-limit这类包：它只是帮你往package.json里写参数，还可能覆盖你手动配的值；更糟的是，它会去改.bin/*.cmd文件里的双引号，而 Windows 命令行对"%_prog%"解析不稳定，容易报'node --max-old-space-size=...' is not recognized -
--max-old-space-size=4096是常见安全上限，超过 4096MB 很少必要，反而会掩盖真正的问题，比如没排除node_modules或dist目录导致打包器加载了不该加载的文件
怎么确认是不是内存泄漏，而不是单纯不够用
加了 4GB 还崩？那大概率不是“不够”，而是“没回收”——Node 进程在反复分配却没释放对象，典型表现是：多次执行 npm run build 后，堆内存峰值持续抬高，或 GC 频次猛增但回收量变少。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 启动时加
--trace-gc参数观察日志：node --max-old-space-size=4096 --trace-gc ./node_modules/.bin/webpack，如果看到大量scavenge或mark-sweep但heap size不回落，说明 GC 没法清理掉某些强引用 - 用
process.memoryUsage()打点：在构建脚本关键节点（如 loader 开始前、插件 apply 后）打印内存，看哪一步突增且不降 - 对比两次堆快照：用
node --inspect启动，Chrome DevTools →chrome://inspect→ attach → Memory → Take snapshot，操作前后各抓一次，右键 Compare to previous snapshot，重点看Retained Size大且类型为Closure、Array或Buffer的项 - 常见泄漏源：Webpack 插件缓存未清、自定义 loader 闭包持有大文件内容、TypeScript
program实例重复创建没销毁、事件监听器注册后没off
VSCode 里怎么调试 Node 内存泄漏，不是看日志而是真抓对象
VSCode 自带的调试器不支持完整内存分析，必须靠 Chrome DevTools 的 Memory 面板，但前提是让进程暴露调试端口，且得在泄漏发生前就 attach 上。
- 别用
launch模式直接跑：那样进程生命周期不可控，GC 行为和 require 阶段的闭包引用都捕不到；改用attach模式 - 终端执行：
node --inspect=9229 --max-old-space-size=2048 app.js（先压低内存上限，加速 OOM 触发定位） -
.vscode/launch.json配type: "pwa-node"+request: "attach"+port: 9229，确保localRoot和remoteRoot都设为"${workspaceFolder}" - 在 Chrome 打开
chrome://inspect→ Configure → 加localhost:9229→ 刷新 → 点 inspect → Memory 标签 → 快照要抓至少三次：空载、触发操作后、等待 30 秒再抓一次，对比看哪些对象 Retainers 面板里始终有引用链 - 特别留意名字含
cache、handlers、pending的 Closure，以及被setInterval箭头函数捕获却没clearInterval的大 Buffer
files.watcherExclude 配错等于没配，Python/TS 项目最容易踩坑
VSCode 默认用 chokidar 监听整个工作区，node_modules 里几万个文件每个都注册 inotify 句柄，Linux/macOS 下这些句柄几乎不回收，Extension Host 内存线性涨——这和你的代码无关，但会让 npm run 启动的子进程更慢、更耗内存，因为文件系统监听器本身就在吃资源。
- 必须写在项目根目录的
.vscode/settings.json，用户级设置在多工作区下 100% 失效 - 规则必须带双星号和尾部斜杠：
"**/node_modules/**": true✅，"**/node_modules"❌（VSCode 直接忽略） - Python 项目至少加四条：
"**/node_modules/**"、"**/.venv/**"、"**/venv/**"、"**/.git/**"；用了 pnpm 就补"**/node_modules/.pnpm/**": true；Turborepo 加"**/.turbo/**": true -
search.exclude完全不影响监听行为，它只过滤搜索结果——别拿它当files.watcherExclude用 - 配完重启 VSCode，然后用
Developer: Open Process Explorer看 Extension Host 内存是否从 600MB+ 降到 200MB 以内
.d.ts 的 AST 却没按需淘汰，或者 Webpack 的 compiler.hooks.done 回调里新建了个 Map 存路径但没清空。加内存只是止痛，不查快照、不看 Retainers，永远不知道谁在 hold 住那几百 MB。 
