因为PHP中只有$GLOBALS（无下划线），不存在$_GLOBALS，写错会导致Undefined variable警告；安全查看方式是var_dump($GLOBALS)，但建议用get_defined_vars()聚焦当前作用域变量，避免资源触发异常。
为什么 var_dump($_GLOBALS) 会报错
因为变量名写错了，PHP 里没有 $_GLOBALS，只有 $_SERVER、$_GET 这类带下划线的复数形式，但全局变量表是 $GLOBALS（没有下划线）。输成 $_GLOBALS 会导致未定义变量警告，甚至在严格模式下直接报 Notice: Undefined variable。
如何安全地查看 $GLOBALS 的全部内容
$GLOBALS 是一个关联数组，键为变量名（字符串），值为对应变量的引用。直接 var_dump($GLOBALS) 能看到所有已声明的全局变量，但要注意：
- 它包含大量内置变量（如
$GLOBALS['argv']、$GLOBALS['_POST']），可能干扰排查 - 如果某个全局变量是资源（如数据库连接）、对象或闭包，
var_dump可能触发不可预期行为或输出大量冗余信息 - 建议加条件过滤：只看当前作用域里你手动声明过的变量，比如
array_keys(array_filter($GLOBALS, function($v) { return !is_internal($v); }))不现实，更实用的是用get_defined_vars()替代——它返回当前作用域所有变量，不含 PHP 内部预设项
调试时该不该修改 $GLOBALS 中的值
可以改，但非常危险。因为 $GLOBALS 存储的是变量的引用，修改其中某一项（如 $GLOBALS['foo'] = 'bar'）等价于直接赋值 $foo = 'bar'，会影响后续所有读取该变量的地方。
- 在函数内部修改
$GLOBALS['something']，相当于污染全局状态，尤其在并发请求或长生命周期脚本（如 CLI）中容易引发隐性 bug - 调试阶段临时覆盖没问题，但上线前必须清理；更推荐用
error_log(print_r($GLOBALS, true), 3, '/tmp/globals-debug.log')记录快照，避免副作用 - 注意：
$GLOBALS本身不能被 unset 或重新赋值（$GLOBALS = []会报Fatal error: Cannot re-assign $GLOBALS）
PHP7.0 下 $GLOBALS 和 get_defined_vars() 的关键区别
两者都反映变量状态，但语义和范围不同：
立即学习“PHP免费学习笔记（深入）”；
-
$GLOBALS始终是全局作用域的完整映射，不管你在函数内还是类方法里调用，它都包含$_POST、$GLOBALS自身、以及所有已声明的全局变量 -
get_defined_vars()返回「当前作用域」所有变量——在函数里调用，只返回函数参数 + 局部变量 +global $x声明引入的变量；在全局作用域调用，结果才接近$GLOBALS - PHP7.0 中二者性能差异可忽略，但
get_defined_vars()更适合定位“当前上下文漏了什么变量”，而$GLOBALS更适合确认“某个变量是否真的存在于全局空间”
真正容易被忽略的是：PHP7.0 开始，$GLOBALS 对象属性访问（如 $GLOBALS->foo）会静默失败，必须用数组语法 $GLOBALS['foo']；另外，var_export($GLOBALS) 在含资源或循环引用时会崩溃，比 var_dump 更脆弱。
