命名管道传大文件卡在writefile是因为字节流模式+64kb缓冲区限制导致阻塞；应改用消息模式分块、异步i/o、边写边读，并用transmitfile零拷贝优化，配合协议头与校验确保完整性。
命名管道传输大文件时为什么卡在 WriteFile 不返回？
因为默认管道模式是字节流（PIPE_TYPE_BYTE），且缓冲区有限（通常 64KB），WriteFile 会阻塞直到对方调用 ReadFile 消费数据，或者写满内核缓冲区。跨进程传 GB 级文件时，若接收端没及时读、或网络/磁盘慢，发送端就卡住。
解决办法是：改用消息模式 + 合理分块 + 异步 I/O：
- 创建管道时指定
PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE，避免粘包，但注意：消息模式单条上限 64KB，超长会被截断 - 发送端拆成 ≤64KB 的
std::vector<char></char>分块，每块单独调用WriteFile - 务必用
FILE_FLAG_OVERLAPPED创建句柄，配合GetOverlappedResult或 IOCP，否则阻塞式写在大文件下极易拖垮整个线程 - 接收端不能等“全部写完再读”，必须边写边读——启动独立读线程，持续调用
ReadFile并写入目标文件
CreateNamedPipe 的 nMaxInstances 设成 1 还是 255？
这不是并发连接数的自由选择，而是和你的通信模型强绑定。设成 1 表示“严格一对一”，第二个客户端连上来会直接被 ConnectNamedPipe 拒绝；设成 255 是为了支持“服务端复用同一管道名，轮流服务多个客户端”，但前提是每次服务完必须调用 DisconnectNamedPipe，再重新 ConnectNamedPipe 等待下一个。
文件传输场景下，几乎总是选 1：
- 传输过程需要稳定上下文（如已协商的压缩算法、校验方式），多实例共享同一管道名会导致状态混乱
- Windows 内核对每个实例分配独立缓冲区，设太高反而浪费内存，且无实际并发收益
- 如果真需要一对多分发文件，应该由主服务进程创建多个独立管道（如
\.pipe ile_xfer_001、\.pipe ile_xfer_002），而不是靠nMaxInstances混用
为什么用 TransmitFile 替代循环 ReadFile+WriteFile？
因为绕过用户态内存拷贝。传统方式要把文件内容从磁盘读到用户缓冲区，再从缓冲区写进管道内核缓冲区，两次 memcpy；而 TransmitFile 让内核直接把文件映射页链表接续到管道发送队列，零拷贝，实测 1GB 文件快 30%–50%。
但要注意限制条件：
- 只支持同步句柄（不能带
FILE_FLAG_OVERLAPPED），所以得配专用线程，不能和异步逻辑混用 - 源文件句柄必须是
GENERIC_READ打开，且支持FILE_FLAG_SEQUENTIAL_SCAN（提升预读效率） - 目标句柄必须是命名管道或套接字，且处于已连接状态（
ConnectNamedPipe返回 true 后） - 别忘了加
TF_USE_KERNEL_APC标志，否则在高负载下可能触发 APC 注入延迟
示例关键调用：TransmitFile(hPipe, hFile, liFileSize.QuadPart, 0, nullptr, nullptr, TF_USE_KERNEL_APC)
接收端用 ReadFile 读到 0 字节就代表传完了？
不是。命名管道关闭时，ReadFile 才返回 0；但发送端可能只是暂时停顿、网络抖动、或对方进程卡住。盲目按 0 字节结束，会导致文件截断。
正确做法是双方约定协议头：
- 发送端先写 8 字节
uint64_t file_size，再发原始数据 - 接收端先用循环
ReadFile确保读满 8 字节，解析出总长度 - 之后累计读取字节数，等于
file_size时才关闭目标文件句柄 - 额外加一层校验：发送端末尾追一个 32 位
crc32，接收端验证失败则删除临时文件并报错
别依赖 EOF 或错误码判断完成——管道没有“文件结束符”概念，只有连接断开或写端关闭。
最易被忽略的是缓冲区生命周期管理：所有 OVERLAPPED 结构体必须在对应 I/O 完成前保持有效，不能放在栈上然后函数返回；异步读写回调里释放内存前，务必检查 GetLastError() == ERROR_IO_INCOMPLETE 是否仍存在未完成操作。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
