改libuv线程池大小直接影响node.js中依赖线程池的i/o操作（如fs.readfile、dns.lookup）并发性能，默认4线程易造成排队阻塞；通过uv_threadpool_size环境变量设置，需结合具体场景压测验证，盲目增大反而可能因上下文切换降低吞吐。
为什么改Libuv线程池大小对Node.js性能有实际影响
因为Node.js中部分I/O操作（比如fs.readFile、dns.lookup）没有原生异步API，必须走Libuv的线程池。默认4个线程，一旦并发请求超过这个数，后续任务就排队——不是卡在JS层，而是卡在线程池调度上，表现为“明明是异步调用，却像同步一样慢”。实测8个并发fs.readFile时，后4个平均延迟比前4个高2.3倍。
如何查看和修改当前线程池大小
线程池大小由环境变量UV_THREADPOOL_SIZE控制，运行时生效，无需改代码或重编译Node.js。
Rydberg Agent Node
下载
使用一条命令部署ProbeChain Rydberg测试网代理节点。自动注册为Agent(NodeType=1)，免gas，支持macOS/Linux/Windows。触发词：/r
- 启动前设置：
UV_THREADPOOL_SIZE=8 node app.js - 运行中动态改（仅对后续新任务生效）：
process.env.UV_THREADPOOL_SIZE = '12'，但注意这不会扩大已创建的线程池，只影响libuv下次初始化时的行为 - 验证是否生效：在Node.js里打印
require('os').cpus().length只是CPU核数，不能代替线程池大小；真正有效的是启动时读取的环境变量值，可通过console.log(process.env.UV_THREADPOOL_SIZE)确认
本地性能验证该不该调大
盲目增大线程池未必提速，反而可能因上下文切换开销拖累整体吞吐。验证要分场景：
- 纯文件读写密集型（如日志归档服务）：用
fs.promises.readFile发起16个并发请求，对比UV_THREADPOOL_SIZE=4和=16下的P95延迟，通常提升明显 - DNS高频查询（如微服务注册中心客户端）：用
dns.promises.lookup压测，线程池不足时会出现大量ENOTFOUND超时，而非连接拒绝 - 混合负载（HTTP + 文件IO）：增大线程池可能抢走事件循环资源，导致
setTimeout回调延迟升高，需同时监控process.nextTick队列长度和eventLoopDelay
VSCode调试时的特殊注意事项
VSCode的Node.js调试器（node-debug或js-debug）本身会注入额外的钩子逻辑，可能干扰线程池行为：
- 调试模式下
UV_THREADPOOL_SIZE仍生效，但线程池任务执行会被断点中断，导致排队现象被放大 - 使用
code --inspect-brk启动时，若同时开启--prof，V8采样可能误将线程池等待时间归为“C++”耗时，需结合perf_hooks的performance.measure单独标记I/O段 - 推荐验证方式：关闭所有断点，用
console.time包裹关键I/O操作，在终端直接运行而非通过VSCode的Run按钮启动，避免调试器IPC开销污染结果
