获取PHP当前脚本路径首选__FILE__和$_SERVER['SCRIPT_FILENAME']，前者返回当前文件的绝对路径，后者指向入口脚本，适用于确定应用根目录。
PHP获取当前脚本的文件路径，主要依赖于几个内置的常量和
$_SERVER超全局变量。它们各有侧重，理解其细微差别能帮助我们更准确地定位文件，尤其在构建复杂应用时，这可不是小事。通常，
__FILE__常量和
$_SERVER['SCRIPT_FILENAME']是最直接的选择，但它们的行为在特定场景下会有所不同，值得我们深思。
解决方案
要获取PHP当前脚本的文件路径，我们有多种手段，每种都有其独特的使用场景和考量。
1. __FILE__
常量：
这是我个人最常使用的。
__FILE__会返回当前文件（即包含
__FILE__这行代码的文件）的完整路径和文件名。它是一个魔术常量，在编译时就会被替换为实际值。
其优点在于，无论文件被如何包含或从何处执行，它始终指向自身。结合
dirname(__FILE__)，我们可以轻松获取当前文件所在的目录。
2. $_SERVER['SCRIPT_FILENAME']
：
这个变量提供了被Web服务器执行的入口脚本的绝对路径。
它反映的是整个请求的起点，对于确定应用程序的根目录非常有用。
立即学习“PHP免费学习笔记（深入）”；
3. $_SERVER['PHP_SELF']
：
这个变量返回当前执行脚本相对于文档根目录的路径。它不包含域名，也不包含绝对文件系统路径。
它常用于表单的
action属性或构建URL，但不能直接用于文件系统操作。
4. dirname()
和 basename()
函数：
这两个函数与
__FILE__或
$_SERVER变量结合使用，能帮助我们进一步处理路径。
dirname(path)
：返回路径中的目录部分。basename(path)
：返回路径中的文件名部分。
5. getcwd()
函数：
这个函数返回当前PHP脚本的当前工作目录（Current Working Directory）。这通常是脚本被执行的目录，或者在Web服务器环境下，是Web服务器的根目录或入口脚本所在的目录。
需要注意的是，
getcwd()可能与脚本实际所在目录不同，特别是当脚本通过
include或
require从另一个目录被调用时。
__FILE__
与 $_SERVER['SCRIPT_FILENAME']
在文件包含中的差异解析
这是一个经常让人感到困惑的地方，也是理解PHP路径处理的关键。我个人在处理模块化应用时，曾因为对这两者的理解不到位而遇到过一些路径问题。简单来说，它们的核心区别在于“谁”被执行和“谁”是当前文件。
__FILE__总是指向它自身所在的那个物理文件。如果你有一个
index.php文件，它
require 'config/database.php'，那么在
index.php中，
__FILE__就是
/path/to/index.php。而在
database.php文件中，
__FILE__就是
/path/to/config/database.php。这让
__FILE__在构建相对路径时非常有用，比如
dirname(__FILE__) . '/../templates'，这样无论
database.php被包含在哪里，它都能正确地找到
templates目录。它提供了一种“自知之明”的能力。
而
$_SERVER['SCRIPT_FILENAME']则不同，它始终指向最初被Web服务器或CLI解释器执行的那个“入口”脚本。在上面的例子中，无论你是在
index.php里打印
$_SERVER['SCRIPT_FILENAME']，还是在被
index.php包含的
database.php里打印，结果都会是
/path/to/index.php。它代表了整个请求的起点，是应用层面的“根”。
所以，当你需要知道当前代码块所在的具体文件位置时，
__FILE__是首选。而当你需要获取整个应用程序的入口文件路径，例如用于定义全局的根目录常量时，
$_SERVER['SCRIPT_FILENAME']则更为合适。混淆这两者，就可能导致文件找不到，或者加载了错误的配置文件。
安全地构建基于脚本路径的绝对路径的最佳实践
在实际开发中，尤其是在处理文件系统操作时，构建绝对路径是家常便饭。但如果处理不当，不仅可能导致路径错误，甚至会引入安全漏洞。我见过太多硬编码斜杠导致跨平台问题，或者没有正确处理符号链接导致路径混乱的案例。
一个非常推荐的做法是结合
dirname(__FILE__)和
realpath()，并使用
DIRECTORY_SEPARATOR常量。
这里有几个关键点：
-
dirname(__FILE__)
: 提供当前文件的目录，这是一个可靠的起点。 -
DIRECTORY_SEPARATOR
: 这是一个PHP内置常量，根据操作系统的不同，它会自动是/
（Unix/Linux）或\
（Windows）。这避免了硬编码斜杠带来的跨平台兼容性问题。 -
realpath()
: 这个函数至关重要。它会解析所有符号链接（symlinks）、/./
和/../
引用，返回一个规范化的绝对路径。这意味着即使你的应用部署在一个通过符号链接指向的目录中，realpath()
也能帮你找到真实的物理路径，这对于安全性（避免路径遍历）和路径一致性都非常重要。没有realpath()
，你可能会得到一个包含..
的逻辑路径，而不是实际的文件系统路径，这在某些文件操作函数中可能会出问题。 -
定义常量: 将应用程序的根目录定义为一个常量（如
APP_ROOT
），可以避免在代码中重复计算路径，提高可读性和维护性。
我个人经验是，每次涉及到文件路径的定义，尤其是全局性的路径，都应该考虑使用
realpath()。它就像给路径做了一次“清理”，确保我们得到的是最准确、最可靠的地址。
在命令行（CLI）环境下获取脚本路径的特殊考量
当PHP脚本在命令行界面（CLI）下运行时，其环境与Web服务器环境有所不同，这直接影响到我们获取脚本路径的方式。
$_SERVER超全局变量虽然依然存在，但其内容会相对精简，一些Web特有的变量可能缺失或值不同。
在CLI环境下，
__FILE__常量依然保持其可靠性。它会给出当前执行文件的绝对路径，这一点与Web环境无异。
$_SERVER['SCRIPT_FILENAME']也通常是可靠的，它会提供被执行的PHP脚本的完整路径。
然而，CLI环境有一个Web环境没有的特性：
$argv数组。这个数组包含了命令行传递给脚本的所有参数，其中
$argv[0]通常就是脚本自身的名称（或路径）。
$argv[0]的路径形式取决于你如何调用脚本。如果仅仅是
php cli.php，它可能是相对路径甚至只有文件名。如果用
php /path/to/cli.php，它就是绝对路径。这使得
$argv[0]不如
__FILE__或
$_SERVER['SCRIPT_FILENAME']那样直接给出绝对路径。
getcwd()在CLI环境中变得尤为重要。它返回的是脚本被执行时所在的“当前工作目录”。
这与Web服务器中
getcwd()通常指向Web根目录的行为形成对比。在CLI中，
getcwd()可以动态变化，取决于用户在哪个目录下执行了
php命令。
我的建议是，在CLI脚本中，如果需要获取脚本自身的物理位置，
__FILE__依然是最稳妥和直接的方式。如果需要获取脚本执行时的当前目录（例如，脚本需要处理当前目录下的文件），那么
getcwd()就非常有用。而
$argv[0]虽然能提供脚本名，但在构建绝对路径时，通常需要额外的处理（如结合
realpath()和
dirname()）才能确保其可靠性。在CLI应用中，路径处理的灵活性和潜在的复杂性都更高，因此选择合适的路径获取方式，并辅以
realpath()进行规范化，是保证脚本健壮性的关键。
