上面没有目录，那里面/的有什么意义呢？..
答案1
..根目录中的条目是一种特殊情况。
来自 POSIX 标准 (4.13 路径名解析，其中.和..条目分别称为“点”和“点-点”）：
特殊文件名点应引用其前身指定的目录。特殊文件名点-点应引用其前任目录的父目录。作为特殊情况，在根目录中，点-点可以指根目录本身。
理由是要添加这一点（A.4.13 路径名解析）
文件名点点相对于根目录所指的内容是实现定义的。在版本 7 中，它指的是根目录本身；这是 POSIX.1-2017 中提到的行为。在某些网络系统中，该结构
/../hostname/用于引用另一台主机的根目录，并且 POSIX.1 允许这种行为。其他网络系统使用该结构
//hostname来达到相同的目的；即<slash>使用双首字母。 [...]
因此，简而言之，POSIX 标准规定每个目录都应该同时具有.和..条目，并允许..目录条目/ 引用/目录本身（请注意引用的第一个文本中的“可能”一词），但它也允许实现让它指代其他东西。
文件系统的最常见实现都/..解析为/.
答案2
善行难陀已经告诉过您这是 POSIX 标准指定的行为。然而，UNIX 的历史20世纪70年代初正式开始。POSIX历史只能追溯到 20 世纪 80 年代后半叶，整整十五年后。在实践中，POSIX 只是指定已经完成的事情通过实施。
相反，UNIX 很早就支持将不同设备上的文件系统安装到其单一的统一目录层次结构中。实际上，每个文件系统都有它自己的根目录;挂载的文件系统/无论如何都不是特别特别。 （它是内容可能是，但文件系统本身不是。）
sysmount和系统调用sysumount似乎已在 1970-1971 年的 UNIX V1 中引入（V1 的日期为 1971-11，根据Unix 遗产协会的 Unix 树）。它们定义在u1.s（分别是系统调用号 21 和 22）并在u7.s。 （PDP7 UNIX，日期为 1970 年 1 月，似乎没有任何明显的祖先）。
您可能会看到这是怎么回事：什么时候任何文件系统可以安装在任何为了避免出现特殊情况，每个目录（包括每个文件系统的根目录）都应包含一个指向其父目录的条目。在磁盘上，指向文件系统根目录的父目录条目的逻辑位置是文件系统的根目录，因为在文件系统的根目录“之上”没有任何其他内容。只有当文件系统安装在层次结构根目录之外的某个位置时，根目录“之上”的概念才会发挥作用。
挂载时，可以重写根目录内存副本中的“父目录”指针，使其指向挂载点目录的父目录。如果没有挂载点目录的父目录（换句话说，文件系统正在挂载为/），则只需保留该数据片段（因为无论如何可能没有其他明智的地方可以将其指向）或单独处理它稍后（ Kusalananda 的回答中提到的/../hostname/path和案例可能就是这种情况）。//hostname/path
由此产生的行为是，在除 之外的任何目录中/，无论它是特定文件系统的根目录还是子目录（在任何嵌套级别），..都指向该目录的父目录；在 中/，..指向/。前者感觉很自然（..总是以相同的方式工作，将你向根目录移动一步），而后者虽然有点特殊，但至少不会明显破坏任何东西（几乎没有伤害无法进一步移动到根目录而不是根目录本身）。例如，您可以敲定任意数量的../并知道那些至少不会导致错误因为..在某些时候不存在。
答案3
那里是上面的目录本身/。/根目录的父目录就是它本身。cd ..或者cd ../..在根目录中应该让您留在同一位置，而不会导致错误。
请注意，在某些文件系统中，它们都不是.或..可能作为实际目录条目存在，它们可能只是由操作系统的虚拟文件系统层模拟。
像这样的路径/../hostname应该可以让您在一些早期的 pre-vfs 和 pre-nfs 系统中访问另一台主机的根目录，例如UNIX系统（使用《纽卡斯尔连线》）但我不知道还有哪个这样的系统仍在使用，而且源代码也无处可寻。
可用的信息非常矛盾，但部署此类系统的最常用方法似乎是重新编译所有程序，以便所有使用路径的调用都open(2)可以在用户空间中重定向（当时没有共享库）。
可能有数百个这样的黑客（刮刮盒是一个更新的版本，我不得不使用它），所以根本不清楚为什么他们觉得有必要将它纳入 POSIX 标准。
答案4
除了这里提到的所有其他原因之外设计简单，UNIX 因而闻名。所有目录都包含..;特殊情况总是会在黑暗中隐约出现绊倒危险（出于安全性或稳健性）。因此，不是强迫程序员在许多地方处理一种罕见的情况，而是将所有目录设计为具有.和..条目并进行统一处理，并且/不需要考虑发生的情况。