PHP静态方法不能被重写，只能被覆盖；因绑定于类名而非实例，static::支持后期静态绑定而self::编译时绑定；parent::调用父类静态方法不改变其内部self::解析；涉及多态应改用实例化策略。
PHP静态方法不能被重写，只能被覆盖
PHP中不存在“重写（override）”静态方法的概念——因为静态方法绑定在类名上，而非对象实例，static:: 和 self:: 的解析时机决定了它不参与运行时多态。所谓“子类定义同名静态方法”，本质是覆盖（hide），不是重写。
常见错误现象：
– 父类调用 self::doSomething()，子类继承后重定义该方法，但父类内部仍执行父类版本；
– 用 static::doSomething() 可实现后期静态绑定（Late Static Binding），但这依赖调用方上下文，不是真正的重写机制。
-
self::总指向定义该语句的类（编译时绑定） -
static::指向实际调用该方法的类（运行时绑定，需 PHP 5.3+） - 子类未定义同名静态方法时，会沿继承链向上查找；一旦定义，就完全屏蔽父类同名方法
为什么 parent:: 在静态方法中调用父类版本要格外小心
使用 parent::methodName() 调用父类静态方法本身可行，但若父类方法内又用了 self::，那依然不会“向下兼容”——它还是锁定在父类作用域。
示例场景：父类 BaseService 有 self::getConfig()，子类 UserService 覆盖了 getConfig() 并希望父类逻辑复用部分配置逻辑，此时直接 parent::getConfig() 可能返回错误结果，因为父类内部的 self:: 不会自动切换到子类。
立即学习“PHP免费学习笔记（深入）”；
- 若父类方法依赖
self::访问常量或静态属性，子类覆盖后无法改变其行为 -
parent::只解决“调用哪一层”的问题，不解决“该层内部如何解析self”的问题 - 想真正共享逻辑，应把核心逻辑抽成 protected 非静态方法，由静态方法委托调用
替代方案：用非静态方法 + 工厂或单例封装静态入口
当业务需要“可被子类定制的行为”，静态方法天然不适合。更务实的做法是放弃“静态即方便”的假设，改用实例化策略。
典型做法：
– 定义抽象基类，含 protected function doWork()；
– 各子类实现该方法；
– 提供静态工厂方法 create() 返回具体实例；
– 或用服务容器统一管理，避免手动 new。
- 静态方法适合无状态、纯计算（如
StringUtils::trim()） - 涉及配置、依赖、上下文（如数据库连接、用户权限）时，实例化才能真正支持多态
- Laravel 的
Cache::get()看似静态，底层其实是通过门面（Facade）代理到容器中真实实例，本质不是静态方法
真要模拟“可重写的静态行为”，得靠 static:: + 显式约定
如果必须保留静态调用表象（比如框架插件接口强制要求静态方法），唯一可控路径是：所有分支逻辑都基于 static::，并约定子类必须覆写特定静态属性或方法。
例如：
abstract class Processor {
protected static $strategy = 'default';
public static function handle($data) {
return static::getStrategy()->process($data);
}
protected static function getStrategy() {
$class = static::$strategy;
return new $class();
}
}
class JsonProcessor extends Processor {
protected static $strategy = 'JsonHandler';
}
这本质上仍是“覆盖+委托”，不是语言级重写。关键点在于：所有对自身类成员的访问都必须用 static::，且子类必须严格遵循命名与结构约定。
容易被忽略的是：这种模式下，IDE 无法推导子类行为，单元测试需显式构造子类上下文，错误排查成本明显升高。
