NamedPipeServerStream 构造时管道名须为纯名称（如"MyPipe"），PipeDirection需匹配读写需求，maxNumberOfServerInstances>1才支持并发，PipeOptions.WriteThrough避免数据未刷出；WaitForConnectionAsync()异步但需确保实例未被释放且正确处理异常与Dispose。
NamedPipeServerStream 构造参数怎么设才不会立刻报错
创建 NamedPipeServerStream 时最常踩的坑是权限和管道名格式。Windows 默认只允许本地连接，若用 "\\.\pipe\MyPipe" 这种 UNC 格式会直接抛 ArgumentException；正确写法是纯名称，比如 "MyPipe"。另外，PipeDirection 和 PipeOptions 不匹配也会导致后续 WaitForConnectionAsync() 失败——例如设成 PipeDirection.In 却试图从服务端写入，就会卡住或抛 InvalidOperationException。
推荐初始化写法：
var server = new NamedPipeServerStream(
"MyPipe", // 管道名，不带前缀
PipeDirection.InOut, // 必须双向，除非你真只读或只写
maxNumberOfServerInstances: 10,
PipeTransmissionMode.Message,
PipeOptions.Asynchronous | PipeOptions.WriteThrough
);-
maxNumberOfServerInstances设为 1 表示单连接，>1 才支持并发客户端（但每个连接需单独实例） -
PipeOptions.WriteThrough能避免客户端读不到“未刷出”的数据，尤其在短连接场景下很关键 - 不要设
PipeSecurity除非你明确需要跨用户或网络访问——默认安全描述符已足够本地进程通信
WaitForConnectionAsync() 阻塞还是异步？为什么调了没反应
WaitForConnectionAsync() 是真正的异步方法，不会阻塞线程，但它**必须在调用前确保管道处于“等待”状态**。常见错误是：构造完 NamedPipeServerStream 就直接 await，却忘了它此时还没开始监听——实际上构造只是分配资源，监听动作发生在第一次 await WaitForConnectionAsync() 时。
另一个隐形陷阱：如果客户端已断开、服务端没及时 dispose 旧实例，新实例可能因命名冲突无法启动。建议用 try/catch 包裹，并在 finally 中确保 Dispose()：
try
{
await server.WaitForConnectionAsync();
// 处理客户端逻辑
}
catch (OperationCanceledException) { /* 客户端断开 */ }
catch (IOException ex) when (ex.InnerException is PipeException) { /* 管道被强制关闭 */ }
finally
{
server?.Dispose();
}- 不要在
WaitForConnectionAsync()后反复 await 同一个实例——它是一次性的，连接断开后必须新建NamedPipeServerStream - 若需长连接复用，应在连接建立后单独启 Task 处理读写，而不是循环调用
WaitForConnectionAsync()
Message 模式下 Read/Write 怎么保证边界不粘包
设 PipeTransmissionMode.Message 后，WriteAsync() 写入的每一段数据会被当做一个独立消息，ReadAsync() 也会按消息边界返回——但前提是客户端也用相同模式打开管道。否则服务端以为在收消息，客户端却以字节流方式发，就会出现读不完或提前截断。
在 Windows 11 上"直接发声"的 TTS（从 WSL2/TUI 调用 powershell.exe + System.Speech）。适用于用户说"说出来/读出来/语音播报/用TTS"，或反馈"没声音/tts 生成的 mp3 是空的/播不出来"，以及需要中文语音但 OpenClaw 内置 tts 不可用时。
实操要点：
- 服务端
ReadAsync()前先调reader.ReadMessageLengthAsync()（需自己封装，.NET 无内置），或更稳妥地：用固定长度头 + 内容的方式手动拆包 - 务必检查
ReadAsync()返回值——它可能只读到部分消息（尤其大消息+缓冲区小），不能假设一次读完 - 写入时用
WriteAsync(buffer, 0, length)显式传长度，别依赖 buffer.Length，避免写入脏内存
如何让服务端支持多个客户端同时连接
单个 NamedPipeServerStream 实例只能服务一个客户端。要支持并发，必须在每次成功连接后，立即新建一个新实例并再次调用 WaitForConnectionAsync()，形成“监听-接受-派生-再监听”的循环。
典型结构：
async Task ListenLoop()
{
while (!cts.IsCancellationRequested)
{
var server = new NamedPipeServerStream("MyPipe", PipeDirection.InOut, ...);
try
{
await server.WaitForConnectionAsync(cts.Token);
_ = HandleClientAsync(server); // 启动独立 Task 处理该连接
}
catch (OperationCanceledException) { break; }
catch (IOException) { /* 忽略连接失败，继续下一轮 */ }
}
}- 别把
HandleClientAsync()放 await 里——那会串行化连接，失去并发意义 - 每个客户端连接的生命周期管理（超时、心跳、异常清理）必须由
HandleClientAsync()自己负责，主循环只管接新连接 - 注意
maxNumberOfServerInstances参数上限，超出后新连接会被系统拒绝，错误码通常是ERROR_PIPE_BUSY
实际最难的不是启动服务器，而是客户端意外退出时服务端能否干净回收资源——NamedPipeServerStream 的 dispose 时机、是否 await 了所有 pending IO、有没有残留的未完成 Task，这些细节稍有疏忽就会导致句柄泄漏或后续连接失败。
