node.js 的 close 回调阶段专门执行已释放资源的句柄善后逻辑，包括 tcp/http 服务器、socket、文件流、udp 套接字等关闭后的 'close' 回调，不处理定时器清除、promise 完成或未显式关闭的句柄。
Node.js 的 close 回调阶段（Close Callbacks phase）专门处理那些已明确进入关闭流程、且底层资源已完成释放的句柄（handles）所关联的回调。它不负责触发关闭动作，而是执行关闭完成后的“善后”逻辑。
会进入 close 阶段的句柄类型
以下几类句柄在被显式关闭、异常终止或资源自然耗尽后，其 close 回调 会被排入该阶段执行：
-
TCP/HTTP 服务器句柄：调用
server.close()后，当所有连接真正断开、监听端口释放完毕，触发'close'事件； -
网络 socket 句柄：如
socket.destroy()或远程对端主动断连导致 socket 关闭，其'close'监听器在此阶段运行； -
文件系统流句柄：包括
fs.createReadStream()/fs.createWriteStream()，当流因end、error或手动stream.destroy()而关闭，且底层文件描述符（fd）已释放，对应'close'回调入队； -
UDP 套接字句柄：调用
socket.close()后，待内核完成清理，执行绑定的'close'回调； -
定时器句柄（极少见）：虽然定时器主要在 timers 阶段处理，但若在关闭过程中被
clearTimeout或clearInterval清理，且 libuv 内部将其视为需 close 处理的 handle，也可能走此路径（属底层实现细节，开发者通常无需关注）。
不会进入 close 阶段的常见情况
以下操作虽涉及“关闭”，但不触发 close 阶段回调：
- 单纯调用
setTimeout/setInterval并清除——它们由 timers 阶段管理，清理不产生 close 回调； -
Promise或async/await的完成——属于微任务，与 handle 生命周期无关； - 未显式关闭的句柄（如忘记调用
server.close()）——只要句柄仍活跃，就不会进入 close 阶段，可能导致进程无法退出； - 仅关闭流的写入端（如
writable.end()）但读取端仍在工作——此时流尚未完全关闭，'close'不会触发。
close 阶段的本质是资源释放确认
它不是“发起关闭”，而是响应 libuv 底层的 uv_close() 调用结果。每当一个 handle 被标记为 closing（例如通过 uv_close(handle, cb)），libuv 就会在该 handle 真正释放资源后，把 cb 推入 close 队列。这意味着：
- 回调执行时，对应资源（端口、fd、内存缓冲区等）已确定不可用；
- 它是事件循环中最后一个宏任务阶段，确保其他 I/O、定时器、setImmediate 都已处理完毕；
- 若应用中存在未关闭的活跃句柄，事件循环会持续运行，close 阶段也不会被触发——这也是排查内存泄漏或进程无法退出的关键线索。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
