我被这个话题迷惑了好几次，被它咬了一口。我查看了许多最佳实践文章和定义，但在我看来，路径并没有完全定义，什么是绝对路径和相对路径似乎因上下文而异。
问题的简短版本：总是在代码中携带（并转换为）绝对路径？但总是把它们写成相对的。
作为一个业余爱好者，由于同时在后端和前端工作，我不断地切换上下文，如果涉及路径，我还没有提出一致的规则并创建可移植的代码。
本质上似乎存在路径类型。绝对路径和相对路径。但是我经常遇到第三种类型，对我来说可能会被命名为Absolute Relative Path。我面临的挑战是知道我应该存储哪一个以及可能出现什么并发症。
这是一个绝对路径：
/home/me/css/style.css
但不是在 Windows 上。以上在Windows上会做什么？它必须是这样的：
C:/home/me/css/style.css
在 Linux 上工作的绝对路径指的是使用 Windows 是完全不同的。它变得相对于当前分区。
/home/me/css/style.css
变成
C:/home/me/css/style.css
在这种情况下这是正确的，但如果实际应用程序在不同的分区上运行，则可能不是这样。因此，如果需要可移植性，使用“Unix 风格”的绝对路径是有问题的。
这是目录的绝对路径：
/home/me/css/
但这也是目录的绝对路径：
/home/me/css
因此，添加另一个斜线纯粹是向作者传达额外的信息，是吗？
这是一个相对路径：
css/style.css
并到一个目录：
css/
如果在 HTML 文档中使用，这是一个绝对相对路径：
<a href="/css/style.css">Link</a>
虽然它指的是最顶层的 css 目录，而与地址当前指向的位置无关，但它仍然指的是网络服务器正在分发的目录。因此，它在使用中是绝对的，但相对于实际的文件系统而言是相对的。或者在许多情况下，到当前工作目录。纯相对路径也是如此。因此，如果我创建这样的路径，我必须记住，即使它们看起来像绝对路径，但实际上并非如此。令人困惑。
如果应用程序本身被移动到不同的目录，我因此必须想出一个解决方案。这就是我想知道存储相对路径是否是一个坏主意的地方。假设我们编写了一个名为 blogger 的静态博客生成器，它通过 git 下载到某个目录。
/home/me/blogger
应用程序中的所有路径都是相对的，因此我们称之为类似于create_dir('output')伪代码的东西。现在我们可能认为将应用程序移动到其他地方并让用户有机会自己提供输出目录是个好主意。突然间，所有路径定义都会中断。他们成为create_dir(absolute($output_dir) + 'output').
我发现这种计算有时会变得非常冗长和复杂。特别是如果仍然有一些文件或目录与应用程序相关，例如模板或类似文件。但它们将来也可能会移动，所以我发现自己编写的代码类似于copy_dir(cwd() + 'templates', absolute($output_dir) + 'output').
但是等等，当前的工作目录不一定是应用程序所在的位置，尤其是在类 unix 系统上。如果应用程序不知道对于应用程序目录是绝对路径还是对于当前目录是绝对路径，那么 absolute 如何生成绝对路径？我们必须假设后者，所以调用absolute()不是一个好主意，而是cwd() + $output_dir。谢天谢地cwd()，通常会返回一个已经绝对的路径。如果用户提供的路径实际上是相对的，我们只能这样做，但如果它是绝对的，则不能这样做。值得庆幸的是，标准库有办法解决这个问题，但天真的方法会失败，我们最终会得到像“C:/C:/css”这样的东西。
假设用户从不提供我们可以使用的绝对路径：
copy_dir(absolute(app_dir()) + 'output', cwd() + $output_dir)
然后我对自己说，好吧，我每次处理这些文件时都必须这样做，所以为什么不这样做一次并随身携带$abs_output_dir呢？突然，我遇到了一个问题，我必须将绝对相对路径输出到 HTML 文档中，但我不能使用$abs_output_dir，因为我必须以某种方式剪掉绝对部分，使其与用户提供的相关$output_dir。在这一点上，我的大脑通常会停下来，我要么对每条路径进行硬编码，要么随身携带$output_dir $abs_output_dir，$rel_abs_output_dir并$abs_app_dir尝试使所有路径保持最新。
因此，仅携带绝对路径的想法似乎是一个不错的想法，除非我们每个人都到了必须将相对路径或绝对相对路径输出到文件的地步。程序员通常是这样做的吗？