管道关闭传播仅通知对端写入结束并触发读端返回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，避免在回调中同步阻塞
• 配合超时机制：对空闲超过阈值的句柄强制关闭，防止长连接泄漏