c＃中的某些流似乎具有“方向”，因为它们意味着在单向上使用。对于其中一些，例如FileStream和NetworkStream是有意义的，但其他人没有。
例如，使用GZipStream，您可以根据构造函数参数将数据写入流中来压缩或解压缩数据。另一方面，CryptoStream强制加密数据到远端，解密被强制进行读操作，加密是写操作。
特别是在使用加密实现时，强行将数据推向特定方向一直很烦人。
是否有任何特定的设计动机只能在一个方向上实现某些流？
更新为了澄清，我正在寻找的是理解为什么有些设计只使用单一方向，而不是方向的选择。之前有没有人想到这个并找到解释或者没有解释。
接收需要尽快处理的正在运行的数据流。因此，您希望在接收到解码流时将字节写入解码流。
使用CryptoStream，您在内存流中放入了多少字节，以及您可以读取多少字节，这与自然无关。在这里，您必须考虑实现特定的细节，例如块大小。
GZipStream可以通过改变压缩方向来解决这个问题。
答案 0 :(得分：3)
解密被强制执行读操作，加密是写操作
是否有任何特定的设计动机只能在一个方向上实现某些流？
好吧，假设它是另一回事。解密写入文件听起来很明智，但数据仍然来自某个地方。
意味着你需要一个Stream.CopyTo()和偶尔的MemoryStream。这些也是您现在可以使用的工具。
这个选择可能有点武断，但你需要选择一个方向，而写作时加密似乎（对我而言）是最自然的。
答案 1 :(得分：1)
如果您认为CryptoStream是加密内容的容器，那么显而易见......你想要读取（）它应该解密和某事。你写入（）应加密。
答案 2 :(得分：0)
流方向对于实现者是任意的，有时它与我们要使用的方向不匹配。
例如FTP文件下载器仅接受写入流，但是您想读取该流。或以反向方式，FTP上传器仅接受读取流，但是您想改为写入该流。
流是关于大块移动数据的，因此可以将其更改为向任一方向移动。
这是一个实现：