后期静态绑定是解决继承中静态上下文错位的核心机制，static::在运行时确定类名，而self::在编译时锁定定义类；static::指向最初发起非转发调用的类，支持子类差异化配置与方法委托，但受可见性约束且依赖调用链起点。
后期静态绑定不是“让静态方法变灵活”的语法糖，而是解决继承中静态上下文错位的核心机制。关键在于：static:: 在运行时才确定类名，而 self:: 在编译时就锁死了定义它的那个类。
为什么 self:: 在继承里总是指向父类
当你在父类中写 self::CONFIG 或 self::getInstance()，PHP 在解析这行代码时就把它和父类名绑定了——不管最后是 A::run() 还是 B::run() 调用，self:: 永远解析为 A。这导致子类无法自然覆盖常量、静态属性或单例实例。
常见错误现象：
- 子类重写了
const TABLE = 'users'，但父类方法里用self::TABLE仍读到父类的值 - 工厂方法返回父类实例，而不是实际调用的子类
- ORM 中
User::find(1)正常，但Admin::find(1)却查了user表
根本原因：继承不等于重写。没在子类里重新声明同名静态方法，self:: 就不会“跳过去”。
立即学习“PHP免费学习笔记（深入）”；
static:: 是怎么做到运行时绑定的
static:: 不是指向“当前类”，而是指向“最初发起非转发调用的那个类”。比如 B::init() → 父类 A::init() 中用了 static::connect()，那它就去找 B::connect()（如果存在），否则继续向上找，直到找到可调用的方法或报错。
使用场景明确：
- 需要子类提供差异化配置（如数据库表名、API endpoint）
- 构建通用基类，但具体行为由子类决定（如日志格式、缓存键生成）
- 避免在每个子类里重复写几乎一样的静态工厂方法
注意：static:: 只能用于静态属性、静态方法、类常量；不能用于实例上下文（比如 $this->foo() 里不能写 static::bar()）。
forward_static_call 是 static:: 的安全补丁
当你要在父类静态方法里“主动调用子类重写的版本”，又不想暴露调用逻辑给子类时，forward_static_call() 就派上用场了。它把当前静态调用链的上下文完整传下去，比手动写 static::method() 更可控。
典型用法：
- 父类
init()中统一做前置检查，再通过forward_static_call([static::class, 'connect'])委托给子类实现 - 避免子类忘记调用
parent::init()导致初始化遗漏 - 配合
__callStatic实现动态代理时保留原始调用类信息
性能影响很小，但可读性略降——你得清楚知道这个函数不光是“调用”，还在传递调用栈上下文。
容易被忽略的边界情况
后期静态绑定只在“非转发调用”起点生效。也就是说，如果你从 B::run() 开始，中间经过 self::do() → static::step()，那 static::step() 里的 static:: 仍然指向 B；但一旦中间插了一个 parent::step()，后续的 static:: 就会以 parent 所在类为新起点重新计算。
最常踩的坑：
- 在 trait 中使用
static::，但 trait 被多个类引入，结果行为不一致 - 误以为
static::能访问 private 静态成员——它依然受可见性限制 - 在
__construct里用static::访问常量没问题，但在__clone或__wakeup中可能因对象状态未完全恢复而出错
真正复杂的地方不在语法，而在你是否意识到：每一次静态调用，都隐含着一个“谁最先敲下 ::”的上下文快照。漏掉这个视角，static:: 就只是个换汤不换药的 self::。
