PHP 8.2 中 $GLOBALS['key'] 可正常读写，但整体赋值（如 $GLOBALS = []）会触发致命错误；global $x 与 $GLOBALS['x'] 写入行为不同，前者可能断开引用，后者始终同步；推荐缓存 $GLOBALS 值为局部变量以提升性能并避免重复哈希查找。
PHP 8.2 中 $GLOBALS['key'] 仍可读写，但整个数组不可赋值
PHP 8.2 继续沿用 8.1 起的严格限制：对单个键的读写（如 $GLOBALS['DB_HOST']）完全正常；但任何试图替换、清空或重绑定整个 $GLOBALS 数组的操作都会触发 Fatal error: Cannot assign to $GLOBALS。这不是 bug，是明确的不兼容变更。
-
$GLOBALS['config'] = ['debug' => true];✅ 合法 -
unset($GLOBALS['missing']);✅ 合法（仅删键） -
$GLOBALS = [];❌ 致命错误 -
array_shift($GLOBALS);❌ 致命错误 -
$g = $GLOBALS; $g['x'] = 1;✅ 不影响原变量（副本行为）
写入全局变量时，$GLOBALS['x'] 和 global $x 的行为差异
两者都可用，但底层机制不同，容易在 PHP 8.2 下踩坑：
- 用
global $x声明后，$x = []会切断与$GLOBALS['x']的引用关系——后续再改$x，$GLOBALS['x']不同步 - 用
$GLOBALS['x'] = []则始终保持同步，因为它是直接操作符号表入口 - 若变量是只读的（如
readonly属性或const定义），两种方式都会静默失败或报错，不是语法问题而是语义拒绝 - 函数内首次创建全局数组，推荐统一用
$GLOBALS['cache'] ??= [];，比global $cache; if (!isset($cache)) $cache = [];更简洁且无引用断裂风险
高频访问场景下，避免重复查 $GLOBALS 哈希表
每次读 $GLOBALS['CONFIG'] 都触发一次符号表哈希查找，在循环或高并发接口里会累积可观开销：
- 函数开头缓存为局部变量：
$cfg = $GLOBALS['CONFIG'] ?? [];，后续全用$cfg - 若需写入，先改局部变量，函数末尾统一回写：
$GLOBALS['CONFIG'] = $cfg; - 绝不把
$GLOBALS['CONFIG']['host']拆成多次访问——先取整数组，再取字段 - OPcache 对
$GLOBALS访问无法常量折叠，所以静态配置项应改用define()或const替代
调试时如何确认 $GLOBALS 是否被意外修改
PHP 8.2 不允许整体写，但开发者仍可能误用 foreach ($GLOBALS as &$v) 或第三方库偷偷调用 extract()，导致符号表污染：
立即学习“PHP免费学习笔记（深入）”；
- 加一行断点检查：
error_log('GLOBALS keys: ' . implode(',', array_keys($GLOBALS))); - 用
get_defined_vars()对比函数内外的全局变量快照，看是否有新增/消失的键 - 特别注意
$_ENV、$_SERVER等超全局变量是否被覆盖——它们本就属于$GLOBALS，但覆盖后会影响框架行为 - CI/CD 流程中建议跑一次
grep -r '\$GLOBALS\[' . --include="*.php" | grep -v 'test\|vendor'，人工审查所有写操作点
