推荐在入口文件（如/public/index.php）首行用define('ROOT_PATH', dirname(__DIR__));定义，因__DIR__始终返回当前文件目录且编译期解析，不受chdir()或执行位置影响，而$_SERVER['DOCUMENT_ROOT']在CLI下不存在、getcwd()依赖工作目录不可靠。
PHP中定义项目根目录常量的推荐方式
直接用 __DIR__ 配合相对路径定义，而不是依赖 $_SERVER['DOCUMENT_ROOT'] 或当前脚本名拼接。前者稳定、可预测；后者在 CLI、重写规则、子目录部署等场景下极易出错。
为什么不用 dirname(__FILE__) 或 getcwd()
dirname(__FILE__) 和 __DIR__ 等价，但 __DIR__ 更简洁、语义更清晰；getcwd() 返回的是进程当前工作目录，在 CLI 下可能指向任意路径（比如你从 /tmp 运行 php /var/www/app/index.php），完全不可靠。
-
__DIR__总是返回当前文件所在目录的绝对路径，不受执行位置影响 - 如果入口文件固定在项目根目录（如
public/index.php），就在该文件里定义：define('ROOT_PATH', dirname(__DIR__)); - 若入口在
public/，而项目根是它的上一级，则dirname(__DIR__)才是真实根目录
多环境部署时如何保证 ROOT_PATH 正确
关键不是“怎么定义”，而是“在哪定义”。必须在所有其他逻辑加载前、且路径最稳定的入口点定义——通常是 public/index.php 开头第一行（早于任何 require 或 autoloader）。
- 不要在配置文件、函数库或类中定义，否则可能被多次 include 导致
Notice: Constant ROOT_PATH already defined - 加一层判断避免重复定义：
if (!defined('ROOT_PATH')) { define('ROOT_PATH', dirname(__DIR__)); } - 不建议用
realpath()包裹——它会解析符号链接，反而掩盖了部署结构问题，调试时更难定位
常见错误：用 $_SERVER['SCRIPT_FILENAME'] 反推根目录
这种写法看似聪明，实则脆弱：
define('ROOT_PATH', str_replace('/public/index.php', '', $_SERVER['SCRIPT_FILENAME']));一旦 URL 重写把请求代理到其他 PHP 文件（如 api.php），或入口改名，就立刻失效。
立即学习“PHP免费学习笔记（深入）”；
- 它假设入口永远叫
index.php、永远在/public/下，违背了“约定优于配置”的前提 - 在 FastCGI 环境中，
$_SERVER['SCRIPT_FILENAME']可能被 Web 服务器篡改，值不可信 - 真正需要的是“项目代码所在位置”，不是“当前请求脚本的位置”——这两者在现代 PHP 项目中通常不同
最易被忽略的一点：定义时机比定义方式更重要。哪怕路径计算完全正确，只要在自动加载之后才定义，很多依赖 ROOT_PATH 的类或配置就已提前加载失败了。
