DIR 永远指向定义该常量的文件所在物理目录，不随 require 链、chdir() 或进程上下文变化；调试需用 debug_print_backtrace() 确认实际位置，跨目录应统一用 ROOT_DIR 等显式锚定路径。
__DIR__ 永远指向“写这行代码的文件”，不是当前工作目录
这是最常踩的坑：你在 /app/worker.php 里写了 require __DIR__ . '/config/db.php';，结果报错说找不到文件——其实是因为这行代码被 require 进了 /lib/core.php，而 __DIR__ 仍返回 /lib，不是 /app。
它不随 require 链跳转，也不受 chdir() 影响，只回答一个静态问题：“这个 __DIR__ 字样写在哪个物理文件里？”
- 调试时用
debug_print_backtrace()快速确认当前执行栈中“这行__DIR__所在的文件路径” - 别在公共库文件（如
Helper.php）里用__DIR__拼业务配置路径，容易被不同项目引入后路径错乱 - 若必须跨目录加载，优先定义全局常量：
define('ROOT_DIR', dirname(__DIR__));放在入口文件最顶部
Windows 下反斜杠拼接导致路径失效
在 Windows 上 __DIR__ 返回 C:\project\src，直接拼 __DIR__ . '\config.php' 可能被某些函数（如 file_get_contents）接受，但传给 shell 命令、正则或外部程序时会出错——尤其当路径里含空格或特殊字符时。
- 统一用正斜杠：
__DIR__ . '/config.php'（PHP 内部兼容，也更可读） - 需要标准化路径（比如消除
../、统一分隔符），用realpath(__DIR__)，它比手动str_replace更可靠 - 避免
__DIR__ . 'sub/file.php'这种漏斜杠写法，PHP 不会自动补，Linux 下可能意外成功，Windows 下直接失败
Workerman CLI 启动时 __DIR__ 路径和预期不符
Workerman 入口脚本（如 start.php）常被 cd 到某个目录后运行：cd /var/www/myapp && php start.php start。这时 __DIR__ 是 /var/www/myapp，但如果 start.php 又 require 了 vendor/autoload.php，而你误以为 __DIR__ 在 vendor 目录下，就全错了。
- CLI 模式下不要依赖当前 shell 的工作目录，所有路径基准必须显式锚定
-
require_once __DIR__ . '/Workerman/Autoloader.php';—— 这里的__DIR__必须是你本地 Workerman 源码的实际位置，不是 Composer vendor 路径 - 如果用了 Composer 安装 Workerman（不推荐），
__DIR__会指向vendor/workerman/workerman，但你的配置文件还在项目根目录，此时必须用dirname(__DIR__, 3)往上跳三级
GatewayWorker 场景下 __DIR__ 容易被误用于连接路由
在 GatewayWorker 架构中，BusinessWorker 和 Gateway 是分离进程，各自有独立入口文件。有人试图在 Events.php 里用 __DIR__ 加载客户端协议类，结果发现 BusinessWorker 进程启动时路径是 /app/Worker，而 Gateway 进程却是 /app/Gateway，同一份代码行为不一致。
- 这种场景下，
__DIR__不具备跨进程一致性，不能作为共享路径依据 - 应统一用项目根目录常量（如
APP_PATH），并在所有进程入口文件中提前定义 - 别在
onMessage回调里动态拼路径加载 handler 类，先在 Worker 初始化阶段完成类映射注册
__DIR__ 本身，而是把它当成“项目起点”或“运行上下文”来用。它只提供一个确定的物理位置，剩下的路径组织逻辑，得你自己设计清楚边界。 
