使用 global 关键字制作 concat 函数是没有意义的。

它用于访问全局变量，例如数据库对象。

例：

function getCustomer($id) {
  global $db;
  $row = $db->fetchRow('SELECT * FROM customer WHERE id = '.$db->quote($id));
  return $row;
}

它可以用作单例模式的变体

简而言之，恕我直言，在现代 PHP 代码中很少有理由，也从来没有一个好的理由。特别是如果你使用的是 PHP 5。如果你正在开发面向对象的代码，那就更特别了。global

全局变量对代码的可维护性、可读性和可测试性产生负面影响。可以并且应该用依赖注入或简单地将全局对象作为参数传递来替换。global

function getCustomer($db, $id) {
    $row = $db->fetchRow('SELECT * FROM customer WHERE id = '.$db->quote($id));
    return $row;
}

反对的一个重要原因是，这意味着该函数依赖于另一个作用域。这很快就会变得一团糟。global

$str1 = 'foo';
$str2 = 'bar';
$str3 = exampleConcat();

与。

$str = exampleConcat('foo', 'bar');

要求 和 在调用范围内设置函数才能正常工作意味着引入不必要的依赖项。如果不在函数中重命名这些变量，则无法再重命名此作用域中的这些变量，因此在使用此函数的所有其他作用域中也是如此。这很快就会陷入混乱，因为您正在尝试跟踪您的变量名称。$str1$str2

global即使包括资源等全球事物，也是一个不好的模式。总有一天，您想重命名但无法重命名，因为您的整个应用程序都依赖于该名称。$db$db

限制和分离变量的范围对于编写任何半复杂的应用程序都是必不可少的。

全局变量是邪恶的

对于关键字以及从局部范围到全局范围的所有其他内容（静态、单例、注册表、常量）都是如此。你不想使用它们。函数调用不应该依赖于外部的任何内容，例如global

function fn()
{
    global $foo;              // never ever use that
    $a = SOME_CONSTANT        // do not use that
    $b = Foo::SOME_CONSTANT;  // do not use that unless self::
    $c = $GLOBALS['foo'];     // incl. any other superglobal ($_GET, …)
    $d = Foo::bar();          // any static call, incl. Singletons and Registries
}

所有这些都会使你的代码依赖于外部。这意味着，您必须知道应用程序所处的完整全局状态，然后才能可靠地调用其中任何一个。没有该环境，该函数就无法存在。

使用超全局变量可能不是一个明显的缺陷，但是如果您从命令行调用代码，则没有 or .如果你的代码依赖于这些输入，那么你就把自己限制在了 Web 环境中。只需将请求抽象到一个对象中，然后改用它即可。$_GET$_POST

在耦合硬编码类名（static、常量）的情况下，如果没有该类可用，您的函数也无法存在。当它是来自同一命名空间的类时，这不是一个问题，但是当你从不同的命名空间开始混合时，你就会造成一团糟。

上述所有因素都严重阻碍了重用。单元测试也是如此。

此外，当您耦合到全局范围时，您的函数签名是在撒谎

function fn()

是一个骗子，因为它声称我可以调用该函数而无需向它传递任何东西。只有当我看到函数体时，我才知道我必须将环境设置为某种状态。

如果您的函数需要参数才能运行，请显式执行并传入：

function fn($arg1, $arg2)
{
    // do sth with $arguments
}

从签名中清楚地传达了它需要被调用的内容。它不依赖于处于特定状态的环境。你不必这样做

$arg1 = 'foo';
$arg2 = 'bar';
fn();

这是一个拉入（全局关键字）与推入（参数）的问题。当您推入/注入依赖项时，函数不再依赖外部。当你这样做时，你不必有一个变量在外面的某个地方保持 1。但是，当你在函数中拉入全局时，你会耦合到全局作用域，并期望它在某处定义一个变量。然后，该功能不再独立。fn(1)$one

更糟糕的是，当你在函数中更改全局变量时，你的代码很快就会完全无法理解，因为你的函数到处都是副作用。

在没有更好的例子的情况下，考虑

function fn()
{
    global $foo;
    echo $foo;     // side effect: echo'ing
    $foo = 'bar';  // side effect: changing
}

然后你做到了

$foo = 'foo';
fn(); // prints foo
fn(); // prints bar <-- WTF!!

没有办法从这三条线看到它发生了变化。为什么使用相同参数调用相同的函数会突然更改其输出或更改全局状态中的值？函数应该对定义的输入 Y 执行 X。$foo

当使用 OOP 时，这种情况会变得更加严重，因为 OOP 是关于封装的，并且通过触及全局范围，您正在破坏封装。您在框架中看到的所有这些单例和注册表都是代码气味，应该删除它们以支持依赖注入。解耦代码。

更多资源：

• http://c2.com/cgi/wiki?GlobalVariablesAreBad
• 在 PHP 中测试注册表模式或单例如何困难？
• 缺陷：脆性全局状态和单例
• 静电被认为是有害的
• 为什么单例在 PHP 中没有用处
• SOLID（面向对象设计）

全局变量是不可避免的。

这是一个古老的讨论，但我仍然想补充一些想法，因为我在上面提到的答案中错过了它们。这些答案简化了什么是全球太多，并提出了根本不能解决问题的解决方案。问题是：处理全局变量和关键字 global 的正确方法是什么？为此，我们首先必须检查和描述什么是全局。

看看 Zend 的这段代码 - 请理解，我并不是说 Zend 写得不好：

class DecoratorPluginManager extends AbstractPluginManager
{
/**
 * Default set of decorators
 *
 * @var array
 */
protected $invokableClasses = array(
    'htmlcloud' => 'Zend\Tag\Cloud\Decorator\HtmlCloud',
    'htmltag'   => 'Zend\Tag\Cloud\Decorator\HtmlTag',
    'tag'       => 'Zend\Tag\Cloud\Decorator\HtmlTag',
   );

这里有很多看不见的依赖关系。这些常量实际上是类。 您还可以在此框架的某些页面中看到require_once。Require_once 是全局依赖关系，因此会产生外部依赖关系。对于一个框架来说，这是不可避免的。如何在没有大量外部代码的情况下创建像 DecoratorPluginManager 这样的类？没有很多附加功能，它就无法运行。使用 Zend 框架，您是否曾经更改过接口的实现？接口实际上是一个全局接口。

另一个全球使用的应用程序是Drupal。他们非常关心正确的设计，但就像任何大型框架一样，他们有很多外部依赖。看看这个页面中的全局变量：

/**
 * @file
 * Initiates a browser-based installation of Drupal.
 */

/**
 * Root directory of Drupal installation.
 */
define('DRUPAL_ROOT', getcwd());

/**
 * Global flag to indicate that site is in installation mode.
 */
define('MAINTENANCE_MODE', 'install');

// Exit early if running an incompatible PHP version to avoid fatal errors.
if (version_compare(PHP_VERSION, '5.2.4') < 0) {
  print 'Your PHP installation is too old. Drupal requires at least PHP 5.2.4. See the     <a     href="http://drupal.org/requirements">system requirements</a> page for more     information.';
  exit;
}

// Start the installer.
require_once DRUPAL_ROOT . '/includes/install.core.inc';
install_drupal();

有没有写过重定向到登录页面？这正在改变全球价值。（然后你不是说“WTF”吗，我认为这是对你的应用程序的不良文档的良好反应。全局变量的问题不在于它们是全局变量，而是您需要它们才能拥有有意义的应用程序。问题在于整个应用程序的复杂性，这可能使它成为处理的噩梦。 会话是全局的，$_POST 是全局的，DRUPAL_ROOT 是全局的，includes/install.core.inc' 是不可修改的全局。在任何功能之外都存在着广阔的世界，为了让该功能完成其工作而需要它。

Gordon 的回答是不正确的，因为他高估了函数的独立性，称函数为骗子是过于简单化的情况。函数不会说谎，当你看他的例子时，函数设计不当——他的例子是一个错误。（顺便说一句，我同意这个结论，即应该解耦代码。 欺骗的答案并不是对情况的正确定义。函数总是在更广泛的范围内起作用，而他的例子太简单了。我们都会同意他的观点，即该函数完全无用，因为它返回一个常量。无论如何，这个功能都是糟糕的设计。如果你想证明这种做法是坏的，请提供一个相关的例子。在整个应用程序中重命名变量并没有什么大不了的，因为有一个好的 IDE（或工具）。问题是关于变量的作用域，而不是函数的作用域差异。函数在流程中有一个适当的时间来执行其角色（这就是首先创建它的原因），并且在那个适当的时间，它可能会影响整个应用程序的功能，因此也适用于全局变量。 xzyfer 的答案是一个没有论证的陈述。如果您具有过程函数或 OOP 设计，则全局变量也同样存在于应用程序中。接下来的两种更改全局值的方法本质上是相同的：

function xzy($var){
 global $z;
 $z = $var;
}

function setZ($var){
 $this->z = $var;
}

在这两种情况下，$z的值在特定函数中都发生了变化。在这两种编程方式中，您都可以在代码中的一堆其他地方进行这些更改。你可以说，使用global，你可以打电话给$z任何地方，然后在那里改变。是的， 你可以的。但你会吗？当在不恰当的地方完成时，它不应该被称为错误吗？

Bob Fanger 对 xzyfer 的评论。

那么任何人都应该使用任何东西，尤其是关键字“全球”吗？不，但就像任何类型的设计一样，尝试分析它所依赖的内容以及依赖于它的内容。试着找出它何时变化以及如何变化。更改全局值应该只发生在那些可以随每个请求/响应而变化的变量上。也就是说，仅属于流程功能流的那些变量，而不是其技术实现。将 URL 重定向到登录页面属于进程的功能流，该流程是用于技术实现接口的实现类。您可以在应用程序的不同版本中更改后者，但不应在每个请求/响应中更改它们。

为了进一步理解何时使用全局变量和关键字 global 有问题，何时不是问题，我将介绍下一句话，这句话来自 Wim de Bie 在撰写博客时： “个人是，私人不是”。当一个函数为了它自己的功能而改变全局变量的值时，我将其称为全局变量的私有使用和错误。但是，当全局变量的更改是为了正确处理整个应用程序时，例如将用户重定向到登录页面，那么在我看来，这可能是好的设计，而不是从定义上讲是坏的，当然也不是反模式。

回想起 Gordon、deceze 和 xzyfer 的答案：他们都有“私人是”（和错误）作为例子。这就是为什么他们反对使用全局变量。我也会这样做。然而，他们并没有像我在这个答案中多次做过的那样，带有“个人是，私人不是”的例子。

我想每个人都已经阐述了全球的消极方面。因此，我将添加积极因素以及正确使用全局变量的说明：

1. 全局变量的主要目的是在函数之间共享信息。回到什么时候 没有什么比类更重要了，PHP代码由一堆函数组成。有时 您需要在函数之间共享信息。通常，全局用于 这样做是有风险的，因为数据是全局的。

   现在，在一些快乐的幸运傻瓜开始评论依赖注入之前，我开始了关于依赖注入的评论 想问你，像例子这样的函数的用户怎么会知道 函数的所有依赖项。还要考虑依赖关系可能因版本和服务器而异
   。依赖注入的主要问题 是依赖关系必须事先知道。在无法做到这一点的情况下 或者不需要的全局变量是实现这一目标的唯一方法。get_post(1)

   由于创建了类，现在可以很容易地将常用函数分组到一个类中 并共享数据。通过像 Mediators 这样的实现，即使是不相关的对象也可以共享 信息。这不再是必需的。

2. 全局变量的另一个用途是用于配置目的。主要是在开头 在加载任何自动加载程序、建立数据库连接等之前编写脚本。

   在加载资源期间，全局变量可用于配置数据（即 要使用的数据库、库文件所在的位置、服务器的 URL 等）。最好的 执行此操作的方法是使用函数，因为这些值不会经常更改 并且可以很容易地放在配置文件中。define()

3. 全局变量的最终用途是保存公共数据（即 CRLF、IMAGE_DIR、IMAGE_DIR_URL）、 人类可读的状态标志（即 ITERATOR_IS_RECURSIVE）。这里全局变量用于存储 旨在在整个应用程序范围内使用的信息，允许它们被更改，以及 让这些更改在应用程序范围内显示。

4. 单例模式在 php4 期间在 php 中变得流行，当一个对象的每个实例 占用了内存。单例通过只允许一个实例来帮助节省 ram 要创建的对象。在引用之前，即使是依赖注入也是一个糟糕的 想法。

   PHP 5.4+ 中对象的新 php 实现解决了其中的大部分问题 您可以安全地传递物体，而几乎不会再受到任何惩罚。这不再是 必要。

   单例的另一个用途是只有一个对象实例的特殊实例 必须一次存在，该实例可能在脚本执行之前/之后存在，并且 该对象在不同的脚本/服务器/语言等之间共享。这里有一个 单例模式很好地解决了该解决方案。

因此，总而言之，如果您处于位置 1、2 或 3，那么使用全局是合理的。但是，在其他情况下，应使用方法 1。

请随时更新应使用全局变量的任何其他实例。

不要犹豫，不要在 PHP 的函数中使用全局关键字。特别是不要接受那些古怪地宣扬/大喊全球如何“邪恶”之类的人。

首先，因为你使用的东西完全取决于情况和问题，而且在编码中没有一种解决方案/方法可以做任何事情。完全撇开无法定义的、主观的、宗教形容词（如“邪恶”）的谬误。

举个例子：

Wordpress 及其生态系统在其功能中使用全局关键字。是否是代码 OOP，是否是 OOP。

截至目前，Wordpress 基本上占互联网的 18.9%，它运行着从路透社到索尼、纽约时报到 CNN 等无数巨头的大型网站/应用程序。

它做得很好。

在函数中使用全局关键字使 Wordpress 免于大规模膨胀，鉴于其庞大的生态系统，这种情况会发生。想象一下，每个函数都在从另一个插件 core 请求/传递所需的任何变量，然后返回。加上插件的相互依赖关系，最终将导致变量的噩梦，或者作为变量传递的数组的噩梦。一个地狱要跟踪，一个地狱要调试，一个地狱要开发。由于代码膨胀和变量膨胀，也占用了大量内存。也更难写。

可能会有人站出来批评 Wordpress、它的生态系统、他们的做法以及这些部分发生的事情。

毫无意义，因为这个生态系统几乎占整个互联网的 20%。显然，它确实有效，它完成了它的工作，甚至更多。这意味着全局关键字也是如此。

另一个很好的例子是“iframes是邪恶的”原教旨主义。十年前，使用 iframe 是异端邪说。有成千上万的人在互联网上宣扬反对他们。然后是 Facebook，然后是社交，现在 iframe 无处不在，从“喜欢”框到身份验证，瞧——每个人都闭嘴。有些人仍然没有闭嘴——无论对错。但你知道吗，尽管有这样的观点，生活仍在继续，即使是十年前反对 iframe 的人现在也不得不使用它们将各种社交应用程序集成到他们组织自己的应用程序中，而一言不发。

......

编码员原教旨主义是非常非常糟糕的东西。我们当中有一小部分人可能会在一家坚实的单一公司中得到一份舒适的工作，这家公司有足够的影响力来承受信息技术的不断变化及其在竞争、时间、预算和其他方面带来的压力，因此可以实行原教旨主义并严格遵守感知到的“邪恶”或“商品”。舒适的姿势让人想起老年，即使居住者很年轻。

然而，对于大多数人来说，IT世界是一个不断变化的世界，他们需要思想开放和务实。原教旨主义没有立足之地，在信息技术的前线战壕中抛开“邪恶”等令人发指的关键词。

只要使用任何对手头的问题最有意义的东西，并适当考虑近期、中期和长期的未来。不要回避使用任何功能或方法，因为它在任何给定的编码器子集中都对它有猖獗的意识形态敌意。

他们不会做你的工作。你会的。根据您的情况行事。