这只是一个概念，另一个层次的抽象，让你的生活更容易。它们都有共同的接口，这意味着你可以以类似管道的方式组合它们。例如，编码到base64，然后压缩，然后将其写入磁盘，所有这些都在一行中!

流表示可以按顺序访问的对象序列(通常是字节，但不一定是这样)。流的典型操作:

read one byte. Next time you read, you'll get the next byte, and so on. read several bytes from the stream into an array seek (move your current position in the stream, so that next time you read you get bytes from the new position) write one byte write several bytes from an array into the stream skip bytes from the stream (this is like read, but you ignore the data. Or if you prefer it's like seek but can only go forwards.) push back bytes into an input stream (this is like "undo" for read - you shove a few bytes back up the stream, so that next time you read that's what you'll see. It's occasionally useful for parsers, as is: peek (look at bytes without reading them, so that they're still there in the stream to be read later)

一个特定的流可能支持读(在这种情况下，它是一个“输入流”)，写(“输出流”)或两者都支持。并不是所有的溪流都是可搜索的。

Push back is fairly rare, but you can always add it to a stream by wrapping the real input stream in another input stream that holds an internal buffer. Reads come from the buffer, and if you push back then data is placed in the buffer. If there's nothing in the buffer then the push back stream reads from the real stream. This is a simple example of a "stream adaptor": it sits on the "end" of an input stream, it is an input stream itself, and it does something extra that the original stream didn't.

Stream is a useful abstraction because it can describe files (which are really arrays, hence seek is straightforward) but also terminal input/output (which is not seekable unless buffered), sockets, serial ports, etc. So you can write code which says either "I want some data, and I don't care where it comes from or how it got here", or "I'll produce some data, and it's entirely up to my caller what happens to it". The former takes an input stream parameter, the latter takes an output stream parameter.

我能想到的最好的比喻是，溪流是一条传送带，向你走来或离开你(有时两者兼而有之)。你从输入流中取出东西，你把东西放到输出流中。有些传送带你可以认为是从墙上的一个洞里出来的——它们是不可寻找的，阅读或写作是一次性的交易。一些传送带就摆在你面前，你可以在溪流中选择你想读/写的位置——这就是寻找。

As IRBMe says, though, it's best to think of a stream in terms of the operations it offers (which vary from implementation to implementation, but have a lot in common) rather than by a physical analogy. Streams are "things you can read or write". When you start connecting up stream adaptors, you can think of them as a box with a conveyor in, and a conveyor out, that you connect to other streams and then the box performs some transformation on the data (zipping it, or changing UNIX linefeeds to DOS ones, or whatever). Pipes are another thorough test of the metaphor: that's where you create a pair of streams such that anything you write into one can be read out of the other. Think wormholes :-)

流是一种抽象，它提供了一组用于与数据交互的标准方法和属性。通过从实际的存储介质中抽象出来，可以编写代码而不完全依赖于该介质是什么，甚至不依赖于该介质的实现。

一个很好的类比可能是考虑一个袋子。你不在乎一个包是什么做的，也不在乎当你把东西放进去的时候它能做什么，只要这个包能发挥它的功能，你就能把东西拿出来。流为存储介质定义了袋的概念，就像袋的概念为袋的不同实例(如垃圾袋、手提包、背包等)定义的那样——交互规则。

为了增加回声室，流是一个抽象，所以您不关心底层存储。当您考虑有和没有流的场景时，这是最有意义的。

文件在很大程度上是无趣的，因为除了我熟悉的非基于流的方法之外，流并没有做太多事情。让我们从网络文件开始。

如果我想从互联网上下载一个文件，我必须打开一个TCP套接字，建立一个连接，并接收字节，直到没有更多的字节。我必须管理一个缓冲区，知道预期文件的大小，并编写代码来检测连接何时断开并适当地处理这个问题。

假设我有某种TcpDataStream对象。我用适当的连接信息创建它，然后从流中读取字节，直到它说没有任何字节。流处理缓冲区管理、数据结束条件和连接管理。

通过这种方式，流使I/O更容易。当然，您可以编写一个TcpFileDownloader类来完成流所做的工作，但是这样您就有了一个特定于TCP的类。大多数流接口只提供Read()和Write()方法，任何更复杂的概念都由内部实现处理。因此，您可以使用相同的基本代码来读写内存、磁盘文件、套接字和许多其他数据存储。

关键是你不应该知道后台存储是什么——它只是一个抽象。实际上，甚至可能没有备份存储——您可能正在从网络中读取数据，而数据根本就没有“存储”。

如果你写的代码能够在文件系统、内存、网络或任何支持流思想的东西上工作，那么你的代码就会更加灵活。

此外，流通常是链接在一起的——你可以有一个流来压缩放入其中的任何内容，将压缩的表单写入另一个流，或者加密数据，等等。在另一端是反向链，解密，解压缩等等。

除了上面提到的东西，还有一种不同类型的流——在函数式编程语言(如Scheme或Haskell)中定义的流——一种可能无限的数据结构，由一些函数按需生成。