静态属性严格绑定声明类的完整命名空间，同名不同命名空间类的静态属性完全隔离；require/include不触发共享，Composer自动加载仅确保类定义唯一，静态属性生命周期限于单次PHP执行。
静态属性在不同命名空间下的隔离性
PHP 的 static 属性作用域严格绑定到**声明它的类**，哪怕两个类同名但位于不同命名空间，它们的静态属性也完全独立。这不是“跨模块共享”的基础，而是隔离的起点。
常见错误：把 App\ModuleA\Manager 和 App\ModuleB\Manager 当作同一类，误以为修改前者会影响后者——实际毫无关系。
- 每个
class定义（含完整命名空间）构成一个独立的静态存储域 - 即使使用
class_alias()创建别名，也不会共享静态属性 -
trait中定义的static属性，会在每个使用它的类中各自复制一份，不互通
require / include 不等于模块加载，更不触发静态共享
PHP 没有原生“模块加载器”概念。用 require 或 include 引入另一个文件，只是执行其中代码；如果该文件定义了类，类本身被注册进 autoloader，但**不会自动初始化其静态属性，也不会与当前上下文建立共享通道**。
典型误区：在 module_a.php 里给 Config::$env = 'prod'，然后在 module_b.php 中直接读 Config::$env —— 这能工作，仅因为两次都命中了同一个 Config 类（相同命名空间+类名），而非“模块间传递”。
立即学习“PHP免费学习笔记（深入）”；
- 确保类定义路径唯一，避免因多处
require导致重复定义 fatal error - 不要依赖引入顺序来“初始化”静态状态；应显式调用初始化方法（如
Config::init()） - Composer autoloading 下，类只加载一次，静态属性生命周期贯穿整个请求
跨模块访问静态成员必须走明确类引用
所谓“跨模块调用”，本质就是从一个命名空间内的代码，去访问另一个命名空间中某个类的 public static 成员。没有魔法，只有明确的类名（带命名空间）和可见性控制。
示例：模块 B 想读模块 A 的配置
// 在 module_b/Service.php 中
use App\ModuleA\Config;
class Processor {
public function handle() {
$mode = Config::$mode; // ✅ 正确：显式 use + 全限定访问
// $mode = \App\ModuleA\Config::$mode; // ✅ 也可全路径写法
}
}
- 若目标静态属性是
protected或private，外部模块无法直接访问，需提供public staticgetter 方法 - 避免在静态属性中存资源句柄（如
mysqli、Redis实例），因无法保证单例语义且易泄漏 - 高并发下，对静态属性的写操作（尤其是复合赋值如
++）不是线程安全的；PHP-FPM 模型下虽无真线程，但多 worker 并发仍可能引发竞态
Composer autoload 后的类复用 ≠ 静态状态复用
很多人以为 “用了 Composer，所有模块自动共享同一个类实例”，这是混淆了“类定义加载”和“静态数据状态”。Autoloader 确保你 new Foo() 总拿到同一个类定义，但 Foo::$counter 的值，在每次请求开始时都是初始值（除非构造函数或静态构造逻辑已运行）。
容易被忽略的一点：CLI 脚本与 Web 请求的生命周期完全隔离。你在 CLI 中改了 Cache::$ttl，不影响任何 Web 请求里的值。
- 静态属性的生命周期 = 单次 PHP 执行周期（request 或 cli script）
- 想跨请求持久化？必须借助外部存储（Redis、DB、APCu）；静态变量不是缓存方案
- 单元测试中，静态状态会污染后续测试；务必在
tearDown()或afterEach()中重置关键静态属性
