You need to read about libuv, the "magic" behind node's non-blocking I/O.
The important thing to take away from the libuv book is that libuv uses the host OS's asynchronous I/O facilities; it does not simply create a new thread for every connection.
libuv tells the OS that it would like to know about any changes (connection state, data received, etc) that happen on a particular set of sockets. It is then up to the OS to deal with managing the connections. The OS itself may create one or more threads to accomplish that, but that's not our concern. (And it certainly won't create a thread for every connection.)
For other types of operations like calls to C libraries that may be computationally expensive (ie crypto), libuv provides a thread pool on which those operations may run. Since it is a thread pool, again you don't have to worry about thread count growing without bound. When the pool is fully busy, operations are queued.
So yes, JavaScript runs on a single thread. Yes, node (via libuv) spawns many threads in the background to do work so that it need not block the JavaScript thread. However, the thread count is always controlled, and I/O generally doesn't even get its own node-allocated thread because that's handled by the OS.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…