PHP中不存在预定义的SPECIFICATION常量，它是由开发者手动定义的路径别名，常用于规约模式中指向Specification类目录，未定义时会触发致命错误。
PHP里为什么找不到 SPECIFICATION 常量
PHP 标准库和核心中根本不存在名为 SPECIFICATION 的预定义常量。你在框架或项目代码里看到它，一定是某人手动定义的——通常是规约（Specification）模式落地时，为方便定位规约类所在目录而设的路径别名。
它不是语言特性，不随 PHP 版本变化，也不在 phpinfo() 或 get_defined_constants() 默认输出里出现。试图直接使用未定义的 SPECIFICATION 会触发 Undefined constant 'SPECIFICATION' 致命错误。
- 检查是否漏了
define('SPECIFICATION', ...)或const SPECIFICATION = ... - 确认定义语句执行早于任何引用它的代码（比如放在入口文件或自动加载前）
- 注意命名空间影响：
SPECIFICATION是全局常量，\MyApp\SPECIFICATION这种写法无效
如何安全定义 SPECIFICATION 路径常量
推荐用绝对路径定义，避免相对路径在 CLI/Web 环境下解析不一致。典型做法是在项目入口（如 public/index.php）或配置引导文件中初始化：
define('SPECIFICATION', __DIR__ . '/../src/Domain/Specification/');
如果你用 Composer 自动加载，更稳妥的方式是配合 PSR-4 映射，而非依赖路径常量——但若团队已习惯用 SPECIFICATION 写 require_once SPECIFICATION . 'UserActiveSpec.php';，那就得确保路径拼接后真实存在且可读。
立即学习“PHP免费学习笔记（深入）”；
- 务必用
is_dir()和is_readable()在定义后校验一次，开发环境报错比运行时报错好排查 - 避免硬编码斜杠：
SPECIFICATION结尾不要带/，拼接时统一用DIR_SEPARATOR或.拼接，防止 Windows 下出问题 - 如果项目支持多环境，不要把路径写死成绝对路径（如
/var/www/app/...），优先用__DIR__向上追溯
用 SPECIFICATION 加载规约类时的常见陷阱
规约模式本身不依赖路径常量，但一旦引入 SPECIFICATION，就容易在类加载环节翻车。最典型的是：文件存在、路径拼对了，但 class_exists() 仍返回 false。
原因往往不是路径问题，而是自动加载没覆盖到该目录，或者类名与文件名不严格匹配（比如用了大小写混用或下划线）。PHP 对类名区分大小写，而某些文件系统不敏感，会掩盖问题。
- 确认
SPECIFICATION指向的目录已被 Composer 的psr-4或classmap覆盖，否则new UserActiveSpec()会失败 - 不要在
SPECIFICATION下混放非规约类（如 DTO、Exception），否则自动加载器可能误判命名空间 - CLI 下测试时，当前工作目录可能不是项目根目录，
__DIR__是唯一可靠的锚点
替代 SPECIFICATION 的更现代做法
硬编码路径常量在大型项目里越来越少见。主流方案是靠依赖注入容器绑定规约接口，或用工厂类集中管理实例化逻辑。例如 Laravel 中可通过服务容器绑定 UserSpecificationInterface 到具体实现，调用方完全不关心路径。
如果你的框架支持属性注入或注解（如 Symfony + PHP 8 Attributes），甚至可以跳过路径拼接，直接通过反射找到标注了 #[Specification] 的类。
- 路径常量适合小项目快速启动，但不利于单元测试（难 mock 路径）
- 一旦开始写测试，你会发现
SPECIFICATION让测试环境路径配置变得脆弱 - 真正需要“规约层路径”的地方，其实是 IDE 自动补全和静态分析工具（如 PHPStan），它们更认 PSR-4 配置，而不是常量
路径常量本身没有错，错的是把它当成架构解耦的手段。它只是个字符串，不是分层契约。
