【BeetleX重构】实现ReadOnlySequence Stream在支持SslSteram出现的狗血问题
内容提要
最近在重写BeetleX中的ReadOnlySequence Stream功能时遇到问题，无论传入什么参数，传到自定义的内部Stream总是byte[0]。经过调试发现问题出在一行代码上，试探性发起一个Read byte[0]，导致功能无法正常使用。最后通过重写ReadAsync方法解决了问题。
延伸解读
问题根源：SslStream 的零长度读取试探
文章指出，SslStream 内部会调用 ReadAsync 并传入 Memory<byte>.Empty，即零长度缓冲区，作为试探性操作。如果自定义 Stream 没有正确处理零长度读取，而是返回等待任务，就会导致后续逻辑无法继续。这提醒开发者在实现 Stream 子类时，必须严格遵循 .NET 流约定：零长度读取应立即返回 0，而不是阻塞。
解决方案：重写 ReadAsync 并处理零长度
作者通过重写 ReadAsync 方法解决了问题。在新实现中，首先检查缓冲区长度是否为 0，若是则直接返回 0；否则根据当前是否有数据决定是立即读取还是等待。这种处理方式确保了与 SslStream 的兼容性，也避免了因零长度读取导致的死锁或功能异常。
调试经验：深入 .NET SDK 源码
由于 SslStream 的问题难以直接举证，作者选择调试 .NET SDK 源码，最终在 EnsureFullTlsFrameAsync 方法中定位到零长度读取的调用。这体现了在复杂网络编程中，理解底层实现细节的重要性，尤其是当自定义组件与框架内部行为交互时，源码级调试往往是解决问题的关键。
Q&A
BeetleX中的ReadOnlySequence Stream功能是什么？
ReadOnlySequence Stream功能用于处理数据流，支持SslStream的功能。
在重写ReadOnlySequence Stream时遇到了什么问题？
遇到的问题是传入SslStream的Read方法总是返回byte[0]。
如何解决ReadOnlySequence Stream中的问题？
通过重写ReadAsync方法，处理SSL完成状态和读取缓冲区的逻辑来解决问题。
为什么SslStream的Read方法返回byte[0]？
因为试探性发起的Read byte[0]影响了后续的逻辑，导致功能无法正常使用。
ReadAsync方法的主要逻辑是什么？
ReadAsync方法处理SSL状态，读取数据到缓冲区，并根据情况返回读取的字节数。
BeetleX支持哪些通信协议？
BeetleX支持HTTP、Websocket、MQTT、Redis、RPC和服务网关等协议。
