全局变量在函数内不可直接访问，需用global或$globals显式声明；二者功能相似但global受限于作用域，$globals更灵活；应避免滥用全局变量，优先使用参数传递、静态属性或依赖注入。
全局变量不能直接在函数里用 $var
PHP 函数内部默认是局部作用域，哪怕你在外面写了 $user_id = 123;，进函数后直接写 echo $user_id; 就是空的，甚至报 Notice: Undefined variable。这不是“没声明”，是根本看不见。
常见错误现象：在 index.php 顶部赋值 $config，进 get_user() 里一用就炸；或者误以为 include 进来的文件里变量会自动变成全局。
- 必须显式声明访问意图：用
global $var;或$GLOBALS['var'] -
global是语法糖，本质就是给局部变量绑到全局符号表，不是复制值 - 如果变量还没定义，
global $x;不会创建它，只会让后续赋值写入全局作用域
global 和 $GLOBALS 的实际区别在哪
两者都能读写全局变量，但行为和可读性差得挺多。别只看“都能用”，得看维护时谁容易翻车。
-
global $db;：只能在函数内第一层作用域生效，嵌套函数、匿名函数里无效；且一旦漏写，后面所有操作都静默失败 -
$GLOBALS['db']：始终可用，不依赖作用域声明，适合动态键名（比如$GLOBALS[$key]），但写法啰嗦，易拼错键名 - 性能上几乎没差别，PHP 内部都是查同一个哈希表，不用纠结“哪个更快”
- 现代 PHP（7.4+）中，用
global在严格模式下更容易触发 IDE 提示，而$GLOBALS常被当成魔法数组忽略类型检查
示例：
function save_log() {
global $log_path;
$log_path .= '_backup'; // 修改全局变量
}
// 等价于
function save_log() {
$GLOBALS['log_path'] .= '_backup';
}
哪些地方绝对不该用全局变量
不是语法不允许，而是会让代码快速失控。尤其当项目从单文件扩展到多个 require、类、Composer 包之后。
立即学习“PHP免费学习笔记（深入）”；
- 配置项：用
return ['host' => '...'];的数组文件，或Config::get('db.host')类封装，别扔一堆$db_host、$api_timeout在全局 - 数据库连接：每次 new PDO 或复用连接池对象，而不是靠
global $pdo;隐式传递——你没法控制它什么时候被谁 close 了 - 用户状态：$_SESSION 已经是全局了，再额外挂个
$current_user容易和 session 数据不同步 - CLI 脚本里临时用一下可以，但上线前务必抽离成参数或依赖注入
替代方案比死磕 global 更省事
真遇到“非共享不可”的场景，优先考虑语言原生支持的方式，而不是硬加 global。
- 函数参数传入：最直白，调用方明确知道依赖什么，IDE 可跳转，单元测试好 mock
- 静态属性：
class Config { public static $env = 'prod'; }，比裸变量有命名空间和访问控制 - 依赖容器（如 PHP-DI）：适合中大型项目，
$app->get(UserService::class)比到处global $user_service清晰得多 - 超全局数组够用就别造轮子：$_SERVER、$_ENV、$_SESSION 已经是合法全局上下文，别重复发明
$g_server
一个容易被忽略的点：PHP 的 include 和 require 是在当前作用域执行的，所以 require 'config.php'; 后面的函数里，只要 config.php 里写了 $cache_ttl = 300;，你依然得靠 global $cache_ttl; 才能用——include 不等于“自动全局化”。
