c#中的一些流似乎有一个 "方向"，即它们是要单向使用的。对于其中的一些流，如FileStream和NetworkStream，这是有意义的，但其他的流就没有意义了。
例如，对于GZipStream，你可以通过写入流来压缩或解压数据，这取决于构造函数参数。而CryptoStream则将加密后的数据强制到远端，解密被强制为读操作，而加密是写操作。
特别是在使用加密实现的时候，被强制将数据推送到特定的方向上，已经很烦了。
有什么特殊的设计动机，让一些流只朝一个方向实现吗？
更新一下。 澄清一下，我想了解的是为什么有些设计只使用一个方向，而不是选择什么方向。之前有没有人想过这个问题，找到了解释，或者说没有。
接收一个正在运行的数据流，需要尽快处理。因此你要在接收到字节时将其写入解码流。
对于CryptoStream来说，你在memoryystream中放入多少字节和你能读到多少字节的解密是没有自然关系的。在这里，你必须考虑到具体的实现细节，比如块大小。
GZipStream可以通过改变压缩的方向来处理这个问题。
解密被强制为读操作，加密为写操作。
是否有什么特殊的设计动机来实现一些流只朝一个方向发展？
好吧，假设是反过来。一边解密一边写入文件听起来很合理，但数据还是要从某个地方来。
这意味着你需要一个 Stream.CopyTo() 和偶尔的MemoryStream。而这些也是你现在可以使用的工具。
这个选择可能略显武断，但你需要选择一个方向，而边写边加密似乎（对我来说）是最自然的。
如果你把 CryptoStream 视为加密内容的容器，那么很明显，你想读()出来的东西应该是解密的，而你写()进去的东西应该是加密的。
流的方向对实现者来说是任意的，有时它与我们想使用的方向并不一致。
如：FTP文件下载器只接受写流，但你想改用读流。 或者反过来说，FTP上传器只接受读流，但你想写到流。
流是关于分块移动数据，所以可以改变数据向任何一个方向移动。
这里有一个实现。