pipereader 的 readasync 后必须调用 advanceto，因其不自动推进缓冲区位置；需显式告知 consumed（已处理）和 examined（已扫描）位置，否则后续读取阻塞或数据丢失。
PipeReader 读取不是“把数据拷出来”，而是获取一个跨内存块的只读视图；不调用 AdvanceTo，下次 ReadAsync 就卡住不动。
为什么 ReadAsync 后必须调用 AdvanceTo
因为 PipeReader 不管理“哪些字节已被业务逻辑真正消费”，它只靠你显式告知：已处理到哪（consumed），看到但未处理的最远位置在哪（examined）。不调 AdvanceTo，缓冲区不会推进，后续 ReadAsync 会反复返回同一段 ReadOnlySequence<byte></byte>，甚至永远阻塞在背压状态。
常见错误现象：
-
ReadAsync返回后直接解析、丢弃结果，没调AdvanceTo→ 下次读不到新数据 - 只传
consumed，漏传examined→ 未扫描的字节可能被管道回收，导致协议解析错位 - 把整个
result.Buffer当作已消费 →consumed设为result.Buffer.End，但实际只解析了前几个字节 → 后续数据被跳过
如何安全遍历 ReadOnlySequence 并定位 consumed/examined
不能直接转 ToArray() 或 Span<byte></byte> 全量拷贝——这破坏零拷贝优势，还可能触发 GC。应使用 ReadOnlySequence<byte>.GetPosition()</byte> 和 ReadOnlySequence<byte>.Slice()</byte> 分段访问。
典型解析循环结构：
while (result.Buffer.Length > 0)
{
if (result.Buffer.IsSingleSegment)
{
var span = result.Buffer.First.Span;
// 解析 span，记录实际 consumedPosition 和 examinedPosition
break;
}
else
{
foreach (var segment in result.Buffer)
{
// 遍历 Memory<byte>，用 Span<byte> 解析每段
// 每次移动时用 GetPosition(offset, segment) 更新位置
}
break;
}
}</byte></byte>
关键点：
-
consumed必须是已完全解析、可丢弃的位置；examined至少要覆盖所有已扫描过的字节（比如协议头长度） - 若解析中途发现不完整帧（如缺少结尾标记），
consumed设为 0，examined设为当前扫描终点 → 管道保留未完成帧，下次继续拼接 - 不要用
buffer.Length直接算偏移 ——ReadOnlySequence<byte></byte>可能跨多个非连续内存块
ReadResult.IsCompleted 为 true 却收不到完整数据？
这通常不是管道问题，而是上游写入端没正确调用 CompleteAsync()，或调早了：比如 FileStream.ReadAsync 返回 0 后立刻 CompleteAsync()，但上一批数据还没 FlushAsync() 出去，导致最后一点数据滞留在 PipeWriter 内部缓冲中，下游 ReadAsync 先收到 IsCompleted == true，但 Buffer 里还剩未推进的尾部。
正确收尾顺序必须是：
- 文件读完（
ReadAsync返回 0）→ 调writer.FlushAsync()→ 等它完成 → 再调writer.CompleteAsync() - 如果用了
cancellationToken，需在FlushAsync前检查是否已取消，否则CompleteAsync()可能被跳过，造成 Reader 永远等不到IsCompleted -
reader.ReadAsync()返回的result中，IsCompleted和Buffer.Length == 0要同时判断，不能只看一个
性能陷阱：过度切分 Sequence 导致 Span 分配开销
有人习惯对每个字节都调 Sequence.GetPosition(1) + Sequence.Slice()，看似精细，实则每次调用都涉及内部链表遍历和对象分配（即使没 new），在高频小包场景下反而比一次性取 First.Span 更慢。
建议策略：
- 协议头固定长度（如 4 字节 magic + 2 字节 length）→ 直接
TryGetFirstSpan(out Span<byte> span)</byte>，用span.Slice(0, 6)解析 - 需要查找分隔符（如
\r\n\r\n）→ 用ReadOnlySequence<byte>.IndexOf()</byte>，它内部做了向量化优化，比手动遍历快得多 - 真要逐字节处理（如文本流 tokenizer）→ 先
TryGetSpan()获取整段可访问区域，再用for循环遍历Span，避免重复调GetPosition
最易被忽略的一点：无论你用什么方式解析，只要没调 AdvanceTo，整个管道就停在那里——这不是 bug，是设计使然；它把流控权彻底交给你，也意味着责任全在你手上。
