__FILE__最可靠，返回当前文件绝对路径（含文件名），不受chdir、include嵌套或CLI工作目录影响；目录路径优先用__DIR__（PHP 5.3+），末尾不带斜杠，拼接时需手动加/。
PHP获取当前脚本路径用__FILE__最可靠
直接用__FILE__，它返回当前文件的**绝对路径（含文件名）**，不受chdir()、include嵌套或CLI工作目录影响。这是唯一能100%确定“这个PHP文件本身在哪”的方式。
常见误区是依赖$_SERVER['SCRIPT_FILENAME']——它在Web SAPI下通常可用，但CLI模式下可能为空或不准确；被require_once引入的文件里，$_SERVER变量仍指向入口脚本，不是当前文件。
-
__FILE__是魔术常量，编译期解析，性能无损耗 - 如果只要目录，用
dirname(__FILE__)，不是dirname(__DIR__)（后者等价于__DIR__，但语义更清晰） - 避免用
realpath(__FILE__)除非你明确需要解析符号链接——它会触发IO，且在某些容器或挂载环境下可能失败
需要目录路径？优先用__DIR__而不是dirname(__FILE__)
__DIR__是__FILE__的目录部分，PHP 5.3+ 原生支持，语义更直白、少一次函数调用。两者在绝大多数场景结果一致，但__DIR__更轻量、更易读。
注意：__DIR__末尾**不带斜杠**，拼接子路径时要手动加/，比如__DIR__ . '/config.php'。有人误写成__DIR__ . 'config.php'，导致路径错位。
立即学习“PHP免费学习笔记（深入）”；
- Windows下
__DIR__返回反斜杠\，但PHP内部路径处理兼容正斜杠，建议统一用/拼接，避免双反斜杠问题 - 在phar包中，
__DIR__返回phar://xxx.phar/xxx这样的伪协议路径，不能直接当本地文件操作 - 若需兼容旧PHP版本（dirname(__FILE__)
getcwd()和$_SERVER['PWD']不是当前脚本路径
这两个返回的是**进程当前工作目录（Current Working Directory）**，和脚本存放位置完全无关。用户执行php /var/www/app/cli.php时，工作目录可能是/home/user，getcwd()就返回那个路径，不是/var/www/app。
典型翻车场景：用getcwd() . '/vendor/autoload.php'加载依赖，在Web服务器里可能因工作目录是/var/www而成功，但一到CLI下就报错——因为CLI启动时工作目录是用户家目录。
- 调试时可打印
getcwd()和__DIR__对比，一眼看出差异 -
$_SERVER['PWD']在某些Shell环境可能不存在，不可靠 - 想切换到脚本所在目录再操作？用
chdir(__DIR__)，但要注意这会影响后续所有相对路径操作
调试时快速验证路径是否正确
别只看echo __DIR__，要真正测试路径是否可访问。尤其在Docker、NFS或权限受限环境，路径存在不等于可读。
简单一行检查：
var_dump([__DIR__, is_dir(__DIR__), is_readable(__DIR__)]);
如果项目结构复杂（如Composer autoload、多入口），还要确认__DIR__是否指向你预期的“模块根目录”。例如在src/Helper/Utils.php里，__DIR__是src/Helper，不是src——这时候可能需要向上跳级：dirname(__DIR__)。
路径拼接务必用realpath()或dirname()做归一化，避免../../残留；但生产环境慎用realpath()，它在高并发下可能成为性能瓶颈。
