命名管道需服务端先监听、客户端加超时；大数据须分块读写并设消息边界；多客户端需设MaxInstances并循环新建实例；跨进程推荐System.Text.Json或MessagePack。
命名管道在 C# 里怎么建连接不卡死
用 namedpipeclientstream 连不上、connectasync 一直挂起，八成是服务端没启动或管道名不一致。windows 命名管道默认是单实例的，客户端连不上时不会报错，而是阻塞——这是最常被忽略的坑。
- 服务端必须先调用
WaitForConnectionAsync（或WaitForConnection）进入监听态，客户端才能连上 - 管道名格式必须严格为
\.pipeYourPipeName（本地）或\ServerNamepipeYourPipeName（远程），少一个反斜杠或大小写不一致都会失败 - 客户端建议加超时：
await client.ConnectAsync(TimeSpan.FromSeconds(3))，避免无限等待 - 如果服务端已存在同名管道且未关闭，新服务端会抛
IOException：“All pipe instances are busy”，得捕获并重试或换名
大数据传输时为什么一发就断、内存暴涨
直接用 StreamWriter.WriteLine 或 BinaryWriter.Write(byte[]) 一次性塞几百 MB，大概率触发 OutOfMemoryException 或管道缓冲区溢出，底层会静默断开连接。
- 必须分块读写：用固定大小的
byte[8192]缓冲区循环Read/Write，别依赖Stream.CopyTo——它内部不设限，容易撑爆 GC - 服务端和客户端要协商好“消息边界”，比如每条数据前写 4 字节长度头（
BitConverter.GetBytes(length)），否则接收方不知道该读多少 - 启用
TransmissionMode = PipeTransmissionMode.Message可以按消息单位收发，但仅限本地管道，且每次消息不能超过 64KB，超了照样拆包，反而增加解析负担 - 记得调用
FlushAsync（尤其用StreamWriter时），否则数据卡在缓冲区不往下走
如何让命名管道支持多客户端并发
NamedPipeServerStream 默认只允许一个客户端连接，连第二个就会抛 IOException：“The pipe is being closed”。这不是 bug，是设计如此。
- 必须显式设置
MaxInstances = NamedPipeServerStream.MaxAllowedServerInstances（或具体数字，如10） - 每个客户端连接后，要立刻用
new NamedPipeServerStream(...)新建一个实例去WaitForConnectionAsync，形成“监听-接管-再监听”循环 - 别在主线程里同步
WaitForConnection，会阻塞新连接；全部用async/await+Task.Run或while(true)循环套await - 客户端断开时，
IsConnected可能还是true，要用try/catch捕获IOException或ObjectDisposedException来判断真实状态
跨进程传对象时序列化选什么方案
直接 BinaryFormatter 已被标记为过时且不安全，JsonSerializer 又太慢、不支持私有字段和循环引用——实际项目里得权衡。
- 小数据（System.Text.Json，注意开启
IncludeFields = true和IgnoreReadOnlyProperties = false，否则字段丢数据 - 大数据、需二进制紧凑：用
MessagePack（NuGet 包MessagePack），比 JSON 快 3–5 倍，体积小 40%，且原生支持DateTime、Dictionary等复杂类型 - 千万别用
XmlSerializer传大对象，XML 标签膨胀严重，GC 压力大，且不支持readonly字段 - 所有序列化类型必须标记
[Serializable]或[MessagePackObject]，否则运行时报NotSupportedException
命名管道本身不处理重连、心跳、断线重续，这些得自己补。特别是大数据传输中途断开，没有内置的断点续传机制，得靠应用层加校验和+分块 ID 才能可靠恢复。
