PHP命名空间不支持直接声明变量，变量始终遵循作用域规则而非命名空间；应使用class静态属性或const定义命名空间级数据，避免全局变量或$GLOBALs。
PHP命名空间里不能直接声明变量
PHP的namespace只作用于类、接口、函数和常量，**不支持在命名空间中直接定义变量**。你写namespace App\Utils; $config = [];这种代码会报错或被当成全局变量——它根本不在命名空间里。
常见错误现象：Parse error: syntax error, unexpected '$config' (T_VARIABLE)，或者变量看似“生效”了，但实际始终是全局作用域下的。
- 所有变量（包括
$GLOBALS、局部变量、静态属性）都遵循作用域规则，和namespace无关 - 想“封装”配置或状态？只能靠
const（命名空间常量）、class静态属性、或闭包返回的函数 - 别试图用
use导入变量——use只支持类、函数、常量别名
用class静态属性模拟命名空间级变量
这是最常用也最安全的做法：把变量收进一个空类里，用public static暴露。它能获得命名空间的逻辑隔离，又符合PHP运行时模型。
使用场景：框架配置、工具类开关、模块级缓存控制。
立即学习“PHP免费学习笔记（深入）”；
示例：
namespace App\Utils;
class Config
{
public static array $db = [
'host' => 'localhost',
'port' => 3306,
];
public static bool $debug = true;
}
调用时用App\Utils\Config::$db，清晰、可 autoload、可类型提示。
- 避免用
private static+ getter——除非真需要封装逻辑，否则纯增加调用开销 - 注意
static属性在FPM多请求间不共享，CLI下可能跨命令残留，别默认它“全局持久” - 如果值是对象（如
PDO），记得考虑实例生命周期，别在静态属性里直接new耗资源对象
const定义命名空间常量（只读变量）
适合配置项、标识符、路径前缀等不变数据。它被编译进opcode，性能略优于静态属性，且语义明确——就是常量。
示例：
namespace App\Utils; const API_VERSION = 'v2'; const UPLOAD_PATH = __DIR__ . '/uploads/';
访问方式：App\Utils\API_VERSION 或在同命名空间内直接用API_VERSION（需未启用strict_types或已use const）。
-
const不支持表达式（如__DIR__ . '/foo'在PHP 8.2+才允许，旧版必须拼好字符串） - 无法用
use const App\Utils\API_VERSION导入后简写为API_VERSION，除非在同一文件中且无命名冲突 - 别用
define()——它只能注册全局常量，无视命名空间
为什么不用global或$GLOBALs加前缀？
有人试过$GLOBALS['APP_UTILS_CONFIG'] = [...]或global $app_utils_config，这确实“能跑”，但等于主动放弃命名空间带来的自动加载、IDE识别、类型检查能力。
性能上没优势，维护成本高：没有autoload，不能用phpstan分析，重构时搜索$app_utils_config会命中所有文件。
- 命名空间不是装饰，是PHP自动加载和符号解析的基础设施，绕开它就等于退化到PHP 5.2时代
- 哪怕只是临时脚本，也建议用
class或const，几行代码的事，省掉后续所有人猜变量归属的精力 - 唯一例外：极简CLI工具（单文件、无autoload、不测不维护），那随便，但得清楚代价
真正容易被忽略的是：命名空间本身不改变变量作用域规则，它只改类/函数/常量的解析路径。变量永远只认function、class、global、$this这几层作用域。记混这点，后面所有封装都会走偏。
