重构遗产PHP：消除$ GLOBALS的实用指南

要消除PHP中的$GLOBALS，应首先分析其使用情况，然后通过依赖注入、配置对象和逐步重构替代全局变量。1. 使用grep等工具找出所有$GLOBALS用法，记录键名及位置；2. 将数据库连接、配置等全局变量替换为显式依赖，如通过构造函数注入PDO或Config对象；3. 创建服务类（如Logger、UserService）封装功能，避免函数依赖全局状态；4. 将配置集中管理，从返回数组的配置文件加载，并注入所需类；5. 按步骤小范围重构，每次替换一个$GLOBALS引用，测试确保行为一致；6. 警惕包含文件的副作用，改用显式引入和传递配置；7. 利用PHPStan等工具辅助检测，编写测试防止回归。最终实现代码解耦、可测试、易维护，提升应用的可预测性和协作效率。

Using $GLOBALS in PHP is a common pattern in legacy applications — especially those built before modern practices like dependency injection and proper object-oriented design became widespread. While $GLOBALS might seem convenient for sharing data across functions and files, it introduces tight coupling, makes testing difficult, and obscures data flow. If you're refactoring legacy PHP code, eliminating $GLOBALS should be a top priority.

Here’s a practical guide to help you move away from $GLOBALS and build cleaner, more maintainable code.

Understand What $GLOBALS Is Doing in Your Code

Before removing anything, you need to understand how $GLOBALS is being used. In PHP, $GLOBALS is a superglobal array that provides access to all variables in the global scope. For example:

$apiKey = 'abc123';

function sendRequest() {
    $key = $GLOBALS['apiKey'];
    // use $key
}

Common uses in legacy code:

• Storing configuration values
• Sharing state between functions
• Passing data between included files
• Acting as a makeshift service container

Start by identifying all instances of $GLOBALS:

grep -r "\$GLOBALS" ./src/

Document what keys are being used and where (e.g., $GLOBALS['db'], $GLOBALS['user'], $GLOBALS['config']).

Replace Global Variables with Dependency Injection

The core principle: instead of reaching into the global scope, pass dependencies explicitly.

Step 1: Extract Variables into Configuration or Services

Take a global like $GLOBALS['db'] — this likely represents a database connection. Replace it with a dedicated service:

// Before
$GLOBALS['db'] = new PDO('mysql:host=localhost;dbname=test', $user, $pass);

function getUser($id) {
    return $GLOBALS['db']->query("SELECT * FROM users WHERE id = $id");
}

// After
class UserService {
    private $pdo;

    public function __construct(PDO $pdo) {
        $this->pdo = $pdo;
    }

    public function getUser($id) {
        $stmt = $this->pdo->prepare("SELECT * FROM users WHERE id = ?");
        $stmt->execute([$id]);
        return $stmt->fetch();
    }
}

Now the dependency is explicit and can be mocked in tests.

Step 2: Use Constructors or Method Arguments

Gradually refactor functions that rely on $GLOBALS to accept parameters:

// Before
function logMessage($msg) {
    $file = $GLOBALS['logFile'];
    file_put_contents($file, $msg . "\n", FILE_APPEND);
}

// After
function logMessage($msg, $logFile) {
    file_put_contents($logFile, $msg . "\n", FILE_APPEND);
}

Eventually, wrap such functionality in a class:

class Logger {
    private $file;

    public function __construct(string $file) {
        $this->file = $file;
    }

    public function log($msg) {
        file_put_contents($this->file, $msg . "\n", FILE_APPEND);
    }
}

Use a Configuration Container

For values like API keys, paths, or settings, replace scattered $GLOBALS['config'] usage with a centralized config array or object:

$config = [
    'api_key' => 'abc123',
    'log_file' => '/var/log/app.log',
    'db_dsn' => 'mysql:host=localhost;dbname=test',
];

Pass this config where needed, or wrap it in a simple class:

class Config {
    private $data;

    public function __construct(array $data) {
        $this->data = $data;
    }

    public function get($key) {
        return $this->data[$key] ?? null;
    }
}

Now inject Config into classes that need settings.

Refactor in Small, Safe Steps

You don’t need to rewrite everything at once. Follow this incremental strategy:

• Step 1: Identify one $GLOBALS usage (e.g., $GLOBALS['user'])
• Step 2: Find all read/write locations
• Step 3: Introduce a setter/getter or service class
• Step 4: Redirect reads/writes to the new system
• Step 5: Remove the $GLOBALS reference
• Step 6: Test thoroughly

Use version control to isolate each change. Write tests if possible — even basic assertions can prevent regressions.

Watch Out for Hidden Dependencies

Some legacy code might rely on side effects from included files that populate $GLOBALS. For example:

// config.php
$GLOBALS['theme'] = 'dark';
$GLOBALS['lang'] = 'en';

// somewhere else
echo "Language: " . $GLOBALS['lang'];

In such cases:

• Convert the config file to return an array
• Require it once and pass the result around
• Or use a config loader class

// config.php
return [
    'theme' => 'dark',
    'lang' => 'en',
];

// bootstrap.php
$config = require 'config.php';
$renderer = new Renderer($config);

Avoid relying on side effects from include/require.

Use Static Analysis and Testing

Tools like PHPStan, Psalm, or even grep can help track down $GLOBALS usage. Write regression tests to ensure behavior stays consistent during refactoring.

If the app lacks tests, start with integration tests around key workflows (e.g., user login, form submission) to catch breakage early.

Summary: Replace $GLOBALS with Explicit Patterns

• ❌ Avoid: $GLOBALS['db'], $GLOBALS['config'], etc.
• ✅ Use: Dependency injection, constructor injection, service classes
• ✅ Centralize config in a Config object or array
• ✅ Refactor incrementally, not all at once
• ✅ Test each change

Eliminating $GLOBALS isn’t just about cleaning up syntax — it’s about making your application more predictable, testable, and easier to evolve. The effort pays off quickly in reduced bugs and better team collaboration.

Basically, treat $GLOBALS like technical debt: identify it, isolate it, and replace it with something maintainable.

以上是重构遗产PHP：消除$ GLOBALS的实用指南的详细内容。更多信息请关注PHP中文网其他相关文章！