静态方法中使用 $this 会触发致命错误，因其无对象上下文；应改用 self:: 或 Static:: 调用静态成员，或改用实例方法。
静态方法里直接用 $this 会报致命错误
php 静态方法运行时没有对象上下文，$this 根本不存在。新手常把“写了 static”和“能像实例一样调用”混为一谈，结果一在 static 方法里写 $this->foo() 就触发 Fatal Error: using $this when not in Object context。
正确做法是：要么改用 self::foo() 或 static::foo() 调用其他静态成员；要么确认真需要对象行为——那就别声明成 static，老老实实 new 一个实例。
- 静态方法不能访问非静态属性或方法（哪怕它们在同一个类里）
-
self::绑定定义时的类，static::支持后期静态绑定（LSP），继承时行为不同 - 若只是想“不 new 就能用”，优先考虑依赖注入或工厂，而非硬塞进静态
把静态属性当“每个实例独有”的容器
静态属性属于类本身，所有实例共享同一份值。新手常误以为 static $data = []; 在每个 new 出来的对象里都是独立副本，结果 A 实例 push 进去的数据，B 实例读出来也有了——这不是 bug，是设计如此。
典型翻车场景：用静态数组存“当前请求的用户信息”，却没意识到多线程/多请求下会互相污染；或在单元测试中没重置静态状态，导致测试间相互干扰。
立即学习“PHP免费学习笔记（深入）”；
- 需要实例隔离？去掉
static，用普通属性 + 构造函数初始化 - 真要全局缓存？明确加注释，并配
clearCache()方法供测试/重置 - 静态属性初始化只在类首次加载时执行一次，后续 new 不会再触发
在构造函数里调用静态方法，却忘了它无法访问 $this
看似安全的操作，比如在 __construct() 里调用 self::initConfig()，但如果这个静态方法内部又试图读 $this->config，照样崩。问题不在调用位置，而在静态方法自身的约束。
更隐蔽的是：静态方法里调用了另一个非静态方法（通过 new static 或传入实例），但开发者没意识到那个非静态方法依赖 $this 的完整生命周期——比如它依赖 __get()、__set() 或未初始化的普通属性。
- 静态方法应保持无状态、无副作用，或只操作传入的参数和静态成员
- 若初始化逻辑复杂且依赖实例状态，拆出来做成普通方法，由构造函数显式调用
- 用 ide 的静态分析（如 PHPStan level 5+）能提前捕获这类跨上下文调用
用 static 替代单例，却不处理多例风险
不少教程教“用静态属性 + 静态工厂方法实现单例”，但新手常漏掉关键一步：没加 private 构造函数和克隆限制。结果外部仍可 new MyClass()，静态 $instance 变成摆设，多个实例并存，状态混乱。
更麻烦的是，在 CLI 模式或长生命周期 swoole 服务中，静态变量不会随请求结束自动销毁，上一个请求留下的状态可能影响下一个。
- 真要用单例，必须封死构造、克隆、反序列化：
__construct()、__clone()、__wakeup()全设为 private - 静态单例不适合有状态的服务（如数据库连接池），应交由容器管理生命周期
- PHP 8.1+ 推荐用
readonly属性 + 构造注入替代静态状态缓存
静态不是语法糖，是运行时模型的切换。错把它当“省略 new 的快捷方式”，迟早掉进共享状态、上下文丢失、测试不可靠的坑里。最稳妥的做法：先写非静态，等明确需要跨实例共享或无状态工具行为时，再谨慎引入 static，并同步审视调用链是否全在静态边界内。