vscode中node.js内存问题需分四层解决：终端脚本、插件进程、远程服务、主渲染进程，每层参数不同且互不影响。npm脚本崩溃应改script或设node_options；远程开发需配remote.ssh.remoteserverenv；主界面卡顿须用code --max-memory启动；大文件需调files.maxmemoryforlargefilesmb并重启。
VSCode 里 Node.js 相关内存问题，90% 不是调一个参数就能解决的——它分四层：终端里跑的 npm run 脚本、Extension Host 插件进程、远程 tsserver/searchService、主界面 Electron 渲染进程。每层用的参数、生效方式、甚至单位都不同，混着加只会白忙。
npm run build 或 dev 崩了，报 JavaScript heap out of memory
这是你在内置终端执行命令时，背后独立的 Node.js 进程堆内存超限（默认约 1.4GB），和 VSCode 主界面无关。
- 优先改
package.json的 script 字段，例如把"build": "vite build"改成"build": "node --max-old-space-size=4096 ./node_modules/vite/bin/vite.js build" - Windows 下临时生效可用
set NODE_OPTIONS=--max-old-space-size=4096；macOS/Linux 用export NODE_OPTIONS=--max-old-space-size=4096 - 别全局设
NODE_OPTIONS：它会影响你本地起的所有 Node 进程（比如 mock server、TypeScript 编译器），容易冲突 - 值不建议超过
4096：真到这一步还崩，大概率是构建配置缺陷或插件泄漏，不是内存不够
远程开发连上就卡死，Ctrl+Click 失效、类型提示消失
远端的 tsserver、searchService 是独立 Node 进程，默认没内存限制，服务器 OOM killer 一来就杀掉它们。
wechat-article-extraction-mp-weixin-qq-com news-webpage-cleaning blog-post-parsing metadata-extraction-title-author-date multiple-output-formats-markdown-json-plain-text batch-processing-support
下载
基于三引擎设计，从微信文章、新闻和博客网页提取干净内容，支持标题作者日期元数据，多格式和批量处理。
- 必须在本地 VSCode 的
settings.json中配"remote.SSH.remoteServerEnv"，例如："remote.SSH.remoteServerEnv": { "VSCODE_NODE_OPTIONS": "--max-old-space-size=2048" } -
2048是稳妥起点；含大量.d.ts或 Lerna monorepo 可试3072；超过4096很少必要，还可能触发服务器 swap - 改完必须完全关闭当前远程窗口（不只是 Reload Window），再重新 Connect —— 否则远端进程沿用旧参数
- 顺手加固
search.exclude和files.watcherExclude，否则光调内存也扛不住递归扫node_modules
VSCode 启动就卡、白屏、弹“内存不足”
这不是 Node 脚本问题，是 Electron 渲染进程本身 RSS 内存飙高（常超 3GB），桌面图标双击启动完全不读 --max-old-space-size。
- 必须终端启动：
code --max-memory=4096 --disable-extensions --disable-gpu .——--max-memory单位是 MB，只管主进程 -
--disable-extensions不是可选动作，是必要隔离：GitLens、ESLint 预热阶段就能占掉 500MB+ - Windows 快捷方式也能加参数，但目标字段末尾要加空格再写
--max-memory=4096；路径含空格时整个路径得加英文引号 -
--disable-gpu在 Intel 核显或 macOS 外接显示器下能省 200–500MB 渲染内存
打开大 JSON 或日志文件时报错、静默降级
VSCode 默认单文件内存上限是 50 MB（files.maxMemoryForLargeFilesMB），超了就放弃语法高亮、折叠，甚至崩溃。
- 在 settings.json 中设
"files.maxMemoryForLargeFilesMB": 200—— 能稳开 50–80MB 文件，不明显拖慢响应 - 设到
4096（4GB）极少必要：V8 堆本身有上限，且渲染进程可能因内存碎片提前崩溃 - 必须重启 VSCode 才生效：热重载不刷新该阈值
- 配合
"editor.largeFileOptimizations": true使用，否则高亮和折叠会卡死
最常被忽略的是分层意识：你看到的“内存不足”，可能来自四个互不通信的进程。改错一层，其他层照样崩。比如给主进程加了 --max-memory，但远程 tsserver 还在吃光服务器内存；或者调高了 files.maxMemoryForLargeFilesMB，却忘了关掉 searchService 对 node_modules 的递归扫描。
