FILE 和 DIR 返回编译时解析的绝对路径；__FILE__ 是当前文件完整路径，__DIR__ 是其所在目录，比 dirname(__FILE__) 更快安全。
__FILE__ 和 __DIR__ 到底返回什么路径
它们返回的是**编译时解析的绝对路径**，不是运行时当前工作目录下的相对路径。比如在 /var/www/app/index.php 中引入 /var/www/lib/helper.php，后者里的 __FILE__ 仍是 /var/www/lib/helper.php，不会变成 ./helper.php 或其他相对形式。
常见错误现象：用 __FILE__ 拼接路径后 require 失败，实际是因为没意识到它已经带完整路径，又多加了一层 dirname(__FILE__) 或重复拼接。
- 想获取当前文件所在目录 → 用
__DIR__（PHP 5.3+），比dirname(__FILE__)更快、更安全 - 需要兼容老版本 PHP（dirname(__FILE__)，但注意它返回斜杠风格依赖系统（Windows 是反斜杠）
- 不要对
__FILE__做字符串截断或正则提取目录，容易跨平台出错
__LINE__ 和 __FUNCTION__ 在调试中怎么避免误用
__LINE__ 返回的是**该常量出现位置的行号**，不是调用它的函数所在行；__FUNCTION__ 返回的是**当前函数名（不带类、命名空间）**，如果写在全局作用域，值为空字符串。
使用场景多见于日志封装或断言函数，但容易踩坑：
立即学习“PHP免费学习笔记（深入）”；
- 封装一个
log_debug()函数，在内部直接写__LINE__→ 它永远指向log_debug函数体内的行号，不是调用处的行号 - 想获取调用栈信息 → 得用
debug_backtrace()，而不是依赖__FUNCTION__ -
__METHOD__和__FUNCTION__不等价：__METHOD__包含类名，__FUNCTION__不包含，别混用
__CLASS__、__TRAIT__、__NAMESPACE__ 的作用域陷阱
这些常量的值取决于**定义位置**，不是调用位置。尤其在 trait 或继承链中，很容易误解。
例如 trait 里写 echo __CLASS__;，实际输出的是**使用该 trait 的类名**，不是 trait 自身名字；而 __TRAIT__ 才是 trait 名。
-
__CLASS__在类方法中返回当前类（含命名空间），但在静态上下文中可能返回 late static binding 的类，不是定义类 -
__NAMESPACE__返回的是**声明当前代码块的命名空间**，不是调用方的命名空间；全局文件中它是空字符串，不是"\" - trait 中想引用自身方法或常量，别依赖
__CLASS__，用static::或明确写类名更可靠
__FILE__ 和 __DIR__ 在 Composer autoloader 或框架路由中的实际影响
很多框架（如 Laravel、Symfony）在生成缓存或注册自动加载器时，会把 __DIR__ 写死进生成的 PHP 文件。一旦项目移动位置，这些路径就失效了 —— 因为 __DIR__ 是编译期确定的，不会随部署路径动态变化。
这不是 bug，而是设计使然。所以：
- 不要在配置文件或缓存生成逻辑里无条件信任
__DIR__的“稳定性” - 若需可迁移路径（如日志目录、模板根路径），建议用环境变量或配置项驱动，而非硬编码
__DIR__ - Composer 的
vendor/autoload.php里大量使用__DIR__，这是安全的，因为 vendor 目录结构固定且不预期被移动
真正复杂的地方在于：这些常量看着简单，但一旦混入 require 链、缓存机制、CLI 与 Web 环境差异、符号链接路径解析，结果就未必如你所想。别图省事直接拼接，先确认当前上下文到底是谁在解析它。
