这是一个复杂的问题。我将尝试依次回答您的问题，但首先进行一般说明：
回滚缓冲区由终端仿真器（xterm，Konsole，GNOME终端）实现。它包含屏幕上已显示的所有文本，包括在终端中运行的每个程序的标准输出和标准错误。它完全是终端功能，可让您查看过去滚动显示的过去输出或查看前面所说的内容。
您可以将回滚缓冲区视为一长页的日志记录输出，而将终端窗口视为一次可以随时查看其一部分的窗口。如果您还没有向上滚动，那么您正在寻找的是缓冲区的尾端。通常，在终端中会配置一个限制，以限制在开始忘记之前要跟踪多少行。
假设该限制为1000行。对于会话中的前一千行输出，您只需追加到缓冲区，然后可以向上滚动到会话的开始。一旦获得输出的第1001行，缓冲区中的第一行就会被擦除，您可以滚动的最远的那一行将是会话的第二行。缓冲区将始终包含屏幕上显示的最新一千行输出，并且您可以随时向上滚动以查看较早的输出。
它是在“子例程”中还是在“功能”中表示“功能”？
这与“功能”中的“功能”相同。终端仿真器具有记录屏幕上内容的功能，并允许您在屏幕上上下滚动。某些系统上的控制台还支持有限的回滚。
一旦投入使用，它将变得更加复杂screen。那时，screen正在模拟回滚缓冲区本身-这就是为什么您可以在程序中复制和粘贴它的原因，而不仅仅是使用X的选择。
此回滚缓冲区是否有Unix标准或API？
简短的答案是不，它只是由您的终端机提供。我们将在底部找到更长的答案。
在程序的“堆栈”中，例如在终端仿真器中启动的vim在屏幕中启动，在bash中启动，在bash中启动，在哪个程序中控制着回滚缓冲区？
在的情况下，vim和bash，他们是不是在所有控制它（警告，再次，下同）。终端从外壳程序开始为其中的所有程序提供回滚缓冲区。screen如上所述，它本身就是在模拟回滚。
我还使用屏幕将回滚转储到文件中。该文件的顶部有很多空白，并且看来终端仿真器向我显示的“视图”只是缓冲区的底部几行。
这是screen的内部缓冲区。当时屏幕上的内容通常是缓冲区最底部的内容。
这就是为什么像vim这样的程序可以“清除”我的整个终端窗口的原因，因为它可以临时访问父shell的回滚缓冲区？
这是它变得更加复杂的一部分。几乎所有基于X的终端仿真器都在模拟VT100，并且它们所做的一件事就是支持“备用屏幕缓冲区”。与用于大多数终端与顺序输出交互的普通缓冲区不同，备用屏幕缓冲区仅是终端的确切大小。它没有向上或向下滚动的功能，因为它不大于显示的内容。
这样做的想法是允许全屏应用程序执行所需的操作，而不会受到屏幕上已有内容的干扰，然后让您回到以前的显示状态。这就是为什么当您输入vim它时会填满整个屏幕，但是当您离开它时，您之前拥有的终端输出（过去的所有提示和命令输出）会再次返回。vim启动时切换到备用屏幕缓冲区，退出时切换到普通缓冲区。
这个备用缓冲区是我上面提到的警告之一。有时，程序确实确实能够告诉终端如何处理缓冲区。
screen是另一个执行此操作的程序，这就是为什么在进行屏幕会话时终端的滚动功能通常不起作用的原因- screen模拟回滚缓冲区本身，因此您必须使用其内部功能才能获得旧的输出。
还是vim使用自己的回滚缓冲区（以某种方式覆盖在父级回滚缓冲区的顶部）？
我在上一个问题中基本上回答了这个问题，但是对这个特定问题的简短回答是，vim它确实从终端获得了自己的临时缓冲区，没有回滚，然后在内部对文档进行了所有自己的滚动。
我提到的所有这些例外：
它再次变得稍微复杂一些。我说过，应用程序对回滚没有任何控制，它完全由终端提供。在某些情况下，对于某些终端，交互作用有限。该程序会打印出某些转义序列-如果您过去曾经手动使用终端着色，您将看到它们的外观-终端可以解释这些内容并更改其行为，甚至将信息发送回程序。termcap（终端功能）数据库中描述了可用的转义序列。
一些终端确实支持有限的查询和回滚缓冲区的操纵。许多xterm派生具有转义序列，这些转义序列指示终端滚动其视图。许多终端还支持指定要滚动屏幕的特定区域，而其余所有部分均保持不变。这往往会破坏回滚缓冲区。
几乎所有终端都支持在屏幕上移动光标的序列，这就是ncurses库如何更新显示的所有不同部分的方式。您可以查看所支持xterm的VT100序列。它们与回滚缓冲区交互的方式有时可能会有些奇怪，尤其是在某些东西实现了自己的滚动行为的情况下，例如less命令。您可能会在回滚中出现重复的行或缺少行，因为less以您的终端无法预期的方式在顶部重新绘制了文本。其他程序有时最终会用整个显示的多个副本填充缓冲区。