标准答案
- 网络 I/O 很多时候由操作系统异步机制处理，不应把所有异步 API 都归因于 libuv 线程池。
- 线程池任务过多会排队，影响同一进程中其他依赖线程池的操作。
- UV_THREADPOOL_SIZE 只能改变线程池上限，不能增加 CPU 或消除磁盘、网络和数据库瓶颈。
- 应观察任务等待、事件循环延迟、CPU、文件系统和加密调用，再通过压测调整。
题目解析
libuv 线程池只承载部分 API，例如某些文件系统、DNS、加密和压缩工作；网络 I/O 常由操作系统机制处理。先确认具体 API 的实现路径，再讨论线程池容量。
线程池是进程内共享资源，某类慢任务会让其他依赖线程池的操作排队。调大 UV_THREADPOOL_SIZE 不能增加 CPU、磁盘或下游容量，可能只带来更多上下文切换。
多个实例的线程池上限会叠加到主机和容器预算。应观察队列等待、event loop delay、CPU、磁盘和调用类型，并按任务类别限制并发。
常见误区
- 误区：认为所有 I/O 都在线程池。改正：区分内核异步网络 I/O、libuv 线程池和业务 Worker。
- 误区：只调大线程池不设任务并发上限。改正：先设置有界任务和下游配额，再评估线程池大小。
- 误区：每个 Node 实例都按最大线程池配置。改正：按实例数、CPU 和主机总资源计算，避免扩容后过载。