PHP全局变量为何是不良实践？HTTP并发请求下是否存在风险？

没问题，我明白你可能已经看过不少相关讨论，但还是想彻底搞透这个点——完全理解这种较真的需求！先从你举的PHP例子说起，再延伸到全局变量的核心问题。

先澄清你的PHP代码：这不是全局变量的问题！ #

首先要纠正一个误解：你写的$variable1在PHP的Web运行环境里并不是全局变量，它是当前请求的局部变量。PHP处理每个HTTP请求时，都是在独立的执行上下文里（比如FPM的每个进程对应一个请求，或者FastCGI的线程），不同请求的变量是完全隔离的。

所以当User1输入'request1'、User2输入'request2'同时发起请求时：

• User1的请求会被分配到进程A，进程A创建$variable1 = 'request1'，然后进入sleep；
• 同时User2的请求被分配到进程B，进程B创建$variable1 = 'request2'，也进入sleep；
• 两个sleep结束后，进程A输出'request1'，进程B输出'request2'，完全不会互相覆盖。

你可能混淆了PHP里的全局变量定义——比如用global关键字声明、或者在函数外部定义但在函数内调用的变量，但哪怕是这类全局变量，在不同请求之间也是完全隔离的，每个请求的全局变量只存在于自己的执行上下文里。

那全局变量为什么是不良实践？ #

全局变量的坑主要集中在两个场景：单个请求的代码逻辑内部，以及跨请求共享状态的全局存储（比如静态变量、单例、全局缓存），具体来说：

1. 代码可读性与可维护性直接拉胯 #

全局变量可以在代码的任何地方被修改，你很难追踪它的变化轨迹。比如一个复杂系统里，某个全局变量被10个不同的函数修改，当出现bug时，你根本不知道是哪一步把它改坏了——排查起来简直是噩梦。

2. 代码耦合度太高，没法独立复用 #

依赖全局变量的代码，根本没法独立测试或复用。你不能把某个函数单独拿出来用，因为它死死依赖一个外部的全局状态，这严重违反了编程里的单一职责原则和依赖注入原则，时间长了代码会变成一团乱麻。

3. 并发场景下的真正风险：跨请求共享的全局状态 #

如果你的“全局变量”是跨请求共享的（比如类里的静态属性、APC/Redis这类全局缓存、服务器内存里的全局对象），那才会在并发场景下踩大雷。举个典型的例子：

class PageCounter {
    public static $visitCount = 0;

    public static function addVisit() {
        self::$visitCount++;
        return self::$visitCount;
    }
}

// 处理请求时调用
echo PageCounter::addVisit();

当100个请求同时调用addVisit()时，因为$visitCount是静态变量（存在服务器进程的全局内存里），多个请求会同时读写它，导致竞态条件——最终的计数可能远小于100，因为多个请求同时读取到同一个值，各自加1后又覆盖了彼此的修改。

这种情况下你得加锁（比如文件锁、Redis分布式锁）来保证操作的原子性，但这会直接增加系统的复杂度。

总结一下 #

• 你举的PHP例子里的变量是请求隔离的，不会出现覆盖问题，因为它不是跨请求的全局状态；
• 全局变量（尤其是跨请求共享的）的核心问题是状态不可控、耦合度高、并发下的竞态条件；
• 哪怕是单个请求内的全局变量，也会让代码变得难以维护，所以尽量用局部变量、依赖注入来替代。

内容的提问来源于stack exchange，提问作者aj go