解读

在 PHP 中，接口（interface）和类（class）都可以定义常量。当某个类实现接口时，如果接口里已经声明了常量，而类里又写了同名常量，就会触发“优先级冲突”。
国内面试官问这道题，并不是想听你背手册，而是考察三点：

1. 是否知道 PHP 的常量解析顺序是“编译期绑定”，不存在运行期覆盖；
2. 是否理解“接口常量是契约，必须只读不可改”这一设计哲学；
3. 能否给出工程级解决方案，而不是简单回答“改名字”。

知识点

1. 常量属于编译期符号，PHP 7.1+ 在编译阶段就会做冲突检测，同名即报错：
   Fatal error: Cannot inherit previously-inherited or override constant XXX
2. 接口常量默认是 public，且不允许重写；类常量可以是 public/protected/private，但一旦被接口“占坑”，子类就不能再声明同名常量。
3. trait 常量、父类常量、接口常量三者同时出现时，优先级顺序为：
   当前类 > trait > 父类 > 接口；但“同名即冲突”原则优先于优先级，只要出现同名，编译直接失败。
4. 从 PHP 8.1 起，类常量可以声明为 final，进一步防止被子类覆盖，但对接口常量无效——接口常量本身就是 final。
5. 国内 PSR-12 规范建议：业务代码里接口常量只放“契约型”值（如版本号、错误码前缀），业务可变成量应放到枚举（PHP 8.1 Enum）或配置对象，从源头避免冲突。

答案

第一步：承认冲突
“PHP 的常量解析发生在编译期，只要接口和实现类出现同名常量，就会直接 Fatal，不存在谁覆盖谁的问题。”

第二步：给出三种工程级策略

1. 命名隔离
   接口里使用大前缀：interface PaymentInterface { const CODE_ALIPAY = 'alipay'; }
   实现类里用业务前缀：class AlipayStrategy { const STRATEGY_CODE = 'alipay'; }
   通过命名空间层级或字符串前缀物理隔离，冲突自然消失。
2. 枚举/配置对象化（PHP 8.1+ 推荐）
   把原来接口里的常量升级为 Enum：
   enum PaymentCode: string { case ALIPAY = 'alipay'; }
   实现类直接引用 PaymentCode::ALIPAY->value，不再定义任何常量，彻底消除冲突。
3. 反射兜底（极端兼容场景）
   如果历史代码里接口常量已被 100+ 实现类引用，不能改接口，也不能改类，可用反射在容器启动时做一次冲突检测：

   $rc = new ReflectionClass($class);
   foreach ($rc->getInterfaceNames() as $iface) {
       $ri = new ReflectionClass($iface);
       foreach ($ri->getConstants() as $name => $value) {
           if ($rc->hasConstant($name) && $rc->getConstant($name) !== $value) {
               throw new RuntimeException("常量{$name}冲突，请按规范重构");
           }
       }
   }
   

   上线前 CI 阶段跑一遍，提前失败，避免生产爆炸。

第三步：总结一句
“核心思想是：接口常量一旦定义就是最终契约，业务侧永远不要尝试‘覆盖’，而是通过命名隔离或 Enum 化把‘可变’与‘不可变’分离。”

拓展思考

1. 如果团队仍在 PHP 7.4，无法使用 Enum，可以用 final 类+private 构造+常量的方式模拟“不可变配置对象”，达到同样效果。
2. 当接口常量与 trait 常量同名时，PHP 会先报 trait 冲突；此时可用 insteadof 或 as 别名机制解决，但常量不支持别名，唯一办法还是改名。
3. 在 Laravel 容器里，可以把接口常量绑定到 config/payment.php，再用 config('payment.alipay') 读取，实现“常量配置化”，既保留契约语义，又避免编译期冲突，是国内中大型 SaaS 的常见套路。