$GLOBALS不是推荐方式，它是全局变量的镜像数组而非声明机制；直接操作易引发Undefined index警告、意外覆盖、类型不匹配及调试困难，应优先使用global声明、参数传递或封装类。
PHP 8.3 中 $GLOBALS 不是“读写全局变量的推荐方式”
它确实能访问/修改所有全局作用域变量，但本质是引用数组而非声明机制——你改的是变量本身，$GLOBALS 只是它的镜像。PHP 8.3 没改变这个行为，也没新增限制，但严格模式和 JIT 下，误用更容易暴露问题。
为什么直接操作 $GLOBALS['foo'] 很容易出错
常见错误现象：Undefined index 警告、变量值被意外覆盖、函数内修改影响到其他逻辑块，甚至在 declare(strict_types=1) 下触发类型不匹配（比如 $GLOBALS['count'] = 'abc' 后又被期望为 int）。
-
$GLOBALS包含所有全局变量，包括$_GET、$_SERVER、$argc等——删或改它们可能破坏运行时环境 - 写入不存在的键（如
$GLOBALS['new_var'] = 42）会创建新全局变量，但无法触发__set或__get魔术方法 - 在函数里用
$GLOBALS['x']修改，等价于在全局作用域赋值，但调用栈里看不出来源，调试困难
替代方案：什么时候该用 global，什么时候该用参数传递
真正需要跨作用域共享数据时，优先考虑显式声明而非依赖 $GLOBALS：
- 函数内要读写已有全局变量 → 用
global $var_name;，语义清晰且 IDE 可识别 - 函数间传递状态 → 直接传参或返回值，例如
function process($config, $data)，避免隐式依赖 - 配置类或单例 → 把全局状态封装进类，用静态属性或依赖注入管理，比裸数组安全得多
- 真要动态访问变量名 → 用
$$varname（可变变量），但需确保$varname来源可信，否则有代码执行风险
如果非得用 $GLOBALS，必须检查这三点
仅限调试、框架底层或极少数兼容旧代码场景。操作前务必确认：
立即学习“PHP免费学习笔记（深入）”；
- 键名是否存在：
isset($GLOBALS['my_flag'])或array_key_exists('my_flag', $GLOBALS)，避免 Notice - 类型是否匹配：
is_int($GLOBALS['counter'])，尤其 PHP 8.3 对联合类型更严格 - 是否在只读上下文（如某些 SAPI 或 opcode 缓存启用时）——部分部署环境会冻结
$GLOBALS写权限，报Cannot modify read-only variable
复杂点在于：它看起来简单，实则把变量生命周期、作用域边界和类型契约全揉在一起。多数时候，不是“怎么用对”，而是“为什么非要用”。
