管道关闭传播仅通知对端写入结束并触发读端返回EOF，不自动回收句柄；真正的资源释放必须显式调用CloseHandle（Windows）或close()（POSIX），否则导致句柄泄漏。
管道流的关闭传播机制本身并不直接回收文件句柄或网络套接字，它只负责通知对端“写入已结束”。真正的句柄回收必须由进程显式调用 CloseHandle（Windows）或 close()（POSIX），系统不会因管道关闭而自动释放未关闭的句柄。
理解关闭传播的实际作用
当所有写入端句柄被关闭时，读取端的 ReadFile（Windows）或 read()（Linux）会返回 0，表示 EOF。这只是一个信号，不是资源清理动作。系统仍保留该句柄，直到进程主动关闭它或进程终止。
- 匿名管道中，父进程若未关闭自己的写入句柄，即使子进程已退出，
ReadFile也不会返回 0 —— 因为管道仍有打开的写入端 - 命名管道中，客户端断开连接后，服务器端的
ConnectNamedPipe返回失败，但服务器持有的句柄仍有效，需手动CloseHandle - 网络套接字与管道不同：TCP 连接关闭（FIN）不等于套接字句柄释放；
closesocket()或close()才真正归还内核资源
自动化回收的关键在于生命周期绑定
不能依赖“关闭传播”触发回收，而应让句柄生命周期与逻辑作用域严格对齐。常见可靠做法包括：
- 使用 RAII 模式（C++）或
using语句（C#）封装句柄，确保作用域退出时自动调用CloseHandle - 在创建子进程后，父进程立即关闭继承来的写入句柄（如重定向 stdout 场景），避免悬空引用
- 对网络服务端，每个客户端连接对应一个独立套接字，应在处理完请求并发送响应后立即
shutdown(SD_SEND)+closesocket()，而非等待对方断连 - 避免跨线程共享句柄；若必须共享，使用引用计数管理，最后一次使用后关闭
避免常见误操作
许多开发者误以为“对方关闭连接 = 我方句柄可忽略”，结果导致句柄泄漏、端口耗尽或 ERROR_PIPE_BUSY 等错误。
- 不要仅靠
WaitForSingleObject等待子进程退出来决定何时关管道句柄——子进程可能卡住，但父进程仍需及时释放句柄 - 不要在
ReadFile返回 0 后继续持有读取句柄——应立刻CloseHandle，否则占用内核对象槽位 - 不要复用已关闭的句柄进行新操作（如再次
WriteFile），Windows 可能返回ERROR_INVALID_HANDLE，但某些情况下会静默失败
结合 I/O 完成端口或事件驱动模型统一管理
在高并发场景下，可将管道句柄、文件句柄、套接字统一注册到 I/O 完成端口（Windows）或 epoll/kqueue（Linux），并在完成例程中集中处理关闭逻辑：
- 收到
ERROR_BROKEN_PIPE或WSAENOTCONN时，标记该连接为待清理 - 在下一次调度周期中执行
CloseHandle或closesocket，避免在回调中同步阻塞 - 配合超时机制：对空闲超过阈值的句柄强制关闭，防止长连接泄漏
