PHP 7.2 全局变量命名冲突是运行时隐患而非语法错误，根本解法是通过命名空间类、函数封装、常量定义或注册表模式避免冲突，禁用 $GLOBALS 直接赋值。
PHP 7.2 中全局变量命名冲突不是语法错误，而是运行时隐患——它不会报错，但会静默覆盖、逻辑错乱、调试困难。根本解法不是“怎么修冲突”，而是“不让冲突发生”。
用命名空间隔离变量声明（PHP 7.2 原生支持）
PHP 7.2 完全支持命名空间，但注意：namespace 只能包裹类、接口、函数和常量，不能直接包裹普通变量。所以你不能写 namespace foo; $bar = 'baz'; —— 这会报 Parse error。
可行做法是把变量封装进类或函数中：
- 定义一个空的命名空间类，仅用于组织常量或静态属性：
class Config { const DB_HOST = 'localhost'; } - 用命名空间下的函数返回值代替裸变量：
function get_app_name() { return 'myapp'; }，调用时用myproject\get_app_name() - 若必须存状态，用
static属性 + 命名空间类：class Registry { public static $cache_ttl = 300; }，访问用myproject\Registry::$cache_ttl
彻底弃用 $GLOBALS 数组直接赋值
在 PHP 7.2 中仍可向 $GLOBALS 写入任意键，比如 $GLOBALS['user_id'] = 123;，但这等于把变量扔进公共广场——任何 require 的文件、任何第三方库都可能覆盖它。
立即学习“PHP免费学习笔记（深入）”；
常见踩坑点：
- 多个配置文件先后执行
$GLOBALS['debug'] = true;和$GLOBALS['debug'] = false;，结果以最后加载的为准，难以追溯 - Composer 包里的代码也可能操作
$GLOBALS，尤其老版本 Zend Framework 或 Smarty 插件 -
$GLOBALS键名无命名空间约束，$GLOBALS['config']和$GLOBALS['CONFIG']在 Windows 下还可能被当成同一个键（取决于 SAPI）
替代方案：用 define() 定义常量（适合不可变值），或用单例类管理可变状态。
用 define() 和 const 替代可读性差的全局变量
如果变量值从不改变（如 API 密钥前缀、环境标识），define() 是最轻量且无冲突风险的方式：
define('APP_ENV', 'production');
define('API_VERSION', 'v2');
注意区别：
-
define('MY_VAR', 'x')是运行时定义，可在任何作用域调用，但不能用于命名空间内 const 的位置 -
namespace myapp; const VERSION = '1.0';是命名空间级常量，PHP 7.2 支持，引用时需完整路径myapp\VERSION - 两者都避免了变量名污染全局符号表，也杜绝了被意外 unset 或重赋值
引入注册表（Registry）模式管理共享状态
PHP 7.2 不再支持 zend-registry 的旧扩展，但纯 PHP 实现完全可行。一个极简注册表类就能替代 90% 的全局变量场景：
class Registry
{
private static $data = [];
public static function set($key, $value)
{
self::$data[$key] = $value;
}
public static function get($key, $default = null)
{
return self::$data[$key] ?? $default;
}
}
使用方式：
- 初始化时集中注入：
Registry::set('db', new PDO(...)); - 各处按需取用：
$db = Registry::get('db'); - 键名可控（如加前缀
'myapp.db.connection'），天然规避冲突 - 比
global $db更易 mock，单元测试友好
真正容易被忽略的是：哪怕只在一个文件里写了 $config = [...];，只要它被多个入口 include，就等同于创建了隐式全局变量——PHP 7.2 不会警告，但模块间耦合已形成。控制变量暴露面，比修复冲突更重要。
