Node进程卡住但CPU很低，基本是fs.readFileSync阻塞事件循环所致，它静默卡主线程却不占CPU，需改用fs.readFile或createReadStream替代。
Node进程卡住但CPU很低，先确认是不是fs.readFileSync阻塞了事件循环
很多开发者看到“假死”第一反应是CPU飙高，但读大文件时更常见的是CPU占用不到1%，进程却完全不响应——这基本就是同步I/O在作祟。fs.readFileSync会把整个文件一次性加载进内存并阻塞主线程，期间所有定时器、网络请求、setTimeout全停摆，但操作系统层面看不到CPU压力。
检查你的代码里是否直接用了：
const data = fs.readFileSync('/path/to/2GB.log');哪怕加了try/catch也拦不住阻塞；Node.js不会报错，只是“静默卡住”。
- 用
fs.readFile或fs.createReadStream替代，它们走异步路径，不锁主线程 - 如果必须同步读（比如启动时加载配置），加个大小判断：
if (stat.size > 10 * 1024 * 1024) throw new Error('file too large for sync read') - 注意：
require('./huge.json')本质也是fs.readFileSync+JSON.parse，同样危险
VSCode调试器连不上，可能是因为Node进程根本没暴露调试端口
你按F5想调试读文件那段代码，结果断点变空心圆、控制台只显示Debugger attached.就结束——大概率不是断点设错了，而是Node进程压根没进调试模式。因为fs.readFileSync卡住后，--inspect-brk参数虽然生效，但V8调试器还没来得及初始化就被堵死了。
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 验证方式：在卡住时执行
lsof -i :9229（macOS/Linux）或netstat -ano | findstr :9229（Windows），如果没输出，说明调试端口根本没起来 - 临时解法：把
fs.readFileSync换成fs.readFile，再用"request": "launch"配"program"字段启动，才能真正进入调试流程 - 别依赖
Attach to Process：一旦进程已卡住，附加进去也看不到堆栈，因为JS线程完全冻结
文件句柄耗尽导致后续open()失败，但错误被静默吞掉
如果你的代码反复打开又忘记close()大文件（尤其用fs.openSync+fs.readSync组合），Node进程可能在几小时内耗尽系统允许的文件描述符上限（Linux默认1024）。此时新请求的fs.open会直接失败，但很多业务逻辑没做err判断，导致后续逻辑拿不到数据就一直挂起。
- 查当前句柄数：
lsof -p <pid> | wc -l，超过800就要警惕 - Node里没显式
fs.close()？那几乎肯定泄漏——fs.createReadStream会在流结束时自动释放，fs.openSync则必须配对fs.closeSync - 别信
process.on('exit', ...)能兜底：进程假死时这个钩子根本不会触发
VSCode自身对大文件的处理干扰了Node进程行为
你以为在VSCode里跑node index.js就是纯终端环境？其实不是。VSCode的集成终端默认启用pty层，并可能注入语言服务器、文件监听器甚至GitLens等插件的钩子。当Node进程试图读取一个被VSCode同时监控的巨型日志文件时，内核级inotify事件和Node的fs.read调用可能产生竞争，导致read()系统调用返回EAGAIN或长时间阻塞。
- 复现对比：在纯终端（Terminal.app / gnome-terminal）里运行同一脚本，如果正常，问题就出在VSCode环境
- 临时绕过：用
code --disable-extensions --read-only启动VSCode，再开集成终端，避免插件干扰 - 终极隔离：调试阶段改用
node --inspect-brk index.js，然后用Chrome DevTools连接，彻底脱离VSCode的终端层
真正难排查的，从来不是“哪行代码卡住了”，而是“为什么卡住后连错误都吐不出来”——Node的同步I/O、文件句柄泄漏、VSCode底层PTY机制，三者叠加时，进程看起来像睡着了，其实正在内核态死等一个永远不来的完成通知。
