单例滥用与全局状态污染：GDScript自动加载脚本的架构替代方案

一、先聊聊自动加载这回事儿

用过 Godot 的朋友，肯定对自动加载不陌生。你在项目设置里把某个脚本挂到 Autoload 列表里，它就会在游戏启动时第一个跑起来，之后你在任何地方都能直接通过它的名字访问它。比如你挂了一个 Global.gd，那你在任何脚本里写 Global.player_hp = 10 都没问题。

这个设计初看特别方便，尤其对刚做游戏的朋友来说。你不需要考虑怎么把引用传来传去，不用新建一个场景再把它实例化，只需要往那一挂，全项目都能用。于是很多人就开始把各种东西往自动加载里塞：玩家数据、音效管理器、关卡状态、UI 控制、随机数生成器、配置表…… 慢慢地，那个 Global 脚本变成了一个几百上千行的大杂烩。

这种“一切都放全局”的做法，在项目小的时候确实还能跑得动。但一旦游戏开始膨胀——当你的角色种类多起来，弹窗系统复杂起来，存档模块越来越厚，你就会发现整个世界好像都乱了。一个脚本改了某个变量，另一个脚本突然就变了行为；你明明只想播放一个音效，结果音效管理器里又连着一堆其他逻辑。最后你排查问题的时候，心里只有一个念头：这到底是哪儿把状态改了？

这就是典型的单例滥用。自动加载本质上就是一个单例，而且是一个“公开的、可变状态的、全进程唯一的”单例。它把全局状态直接暴露给所有脚本，人人可读可写，最后就变成了一种隐性的全局污染。

这篇文章，我们就来掰扯掰扯这个问题，并且聊几个实打实的替代方案。你放心，我不会丢一堆抽象名词吓唬你，咱们就用平时写游戏时遇到的真实场景来说事儿。

二、单例为什么这么好用，又为什么坑人

2.1 方便在哪儿

先说优点，不然不公平。

自动加载最大的好处是：你不用考虑对象是怎么被创建的。Godot 在启动的时候替你把它 new 好，然后以全局变量的形式放在那里。你从任何地方访问它，都不需要持有它的引用。这在处理一些“全局性”的操作时，效率特别高。

比如你想做一个简单的全局得分：

# autoload/GameState.gd
extends Node

var score := 0

func add_score(value: int) -> void:
    score += value
    print("当前得分：", score)

然后你的敌人被消灭时，只需要写 GameState.add_score(100) 即可。这听起来确实简单，对吧？没有依赖注入，没有信号传参，没有场景树的层层查找。

2.2 坑在哪儿

但是，这种“简单”是有代价的。最直接的问题就是：你根本不知道是谁改了这个状态。

假设你现在要做一个小功能：当玩家吃到金币时，加上 50 分，同时播放一个音效。于是你在金币脚本里写：

GameState.add_score(50)
AudioManager.play_sfx("coin")

这看起来很正常。但是过了几天，你又写了一个限时任务系统，它也需要关注得分变化。于是你又得在任务系统里轮询 GameState.score，或者每隔一段时间检查一次。再后来，你发现有些金币是假的，不应该加分，于是你给金币加了一个布尔字段，然后在加分之前判断。可是你忘了——还有另外两个脚本也在直接改 score，它们可没检查这个字段。于是 bug 出现了，游戏里总有一些场合得分不对。

你开始调试。你打开了 GameState.gd，在 add_score 里加了很多打印，然后一遍一遍地看输出，试图找出到底是谁调用了它。如果你项目里有二十个脚本都可能调用这个方法，那你就得一个一个查过去。这种体验，写过大项目的人应该都有共鸣。

更糟糕的是，自动加载脚本是有生命周期的。它的生命周期跟场景树绑定，但它本身不会随着某个关卡的结束而销毁。所以，你在关卡里创建的数据，如果忘了清理，就会一直残留到下一关。比如你有一个 EnemyManager，在某个副本里生成了特殊的怪物，副本结束之后你忘了清空数组，结果这个怪物列表就一直存在，影响后续所有逻辑。

有一个典型例子：你做一个射击游戏，敌人掉落武器。你为了图省事，把当前武器放进了全局变量：

# autoload/PlayerData.gd
extends Node

var current_weapon_id := "pistol"

然后你在任何脚本里都能直接读写它。有一天，你加了一个“队友系统”，队友也会换武器。你猜怎么着？队友换武器的时候，如果他不小心把 PlayerData.current_weapon_id 改了，那玩家的武器就变了。这问题出在哪儿？出在你把 “玩家”这个本应独立的实体，变成了一个全局唯一的状态。可游戏里不只有一个实体啊。

三、替代方案之一：场景树中显式传递引用

面对上面的问题，最直接、最朴素的解决办法是：不要把所有东西都放在全局，而是把需要的数据通过场景树传递下去。Godot 的场景树本来就是一个层级结构，一个节点可以拥有子节点，子节点也可以获取父节点或者兄弟节点。

3.1 一个具体的例子

假设我们要做一个“暂停菜单”的功能。我们有一个主场景，结构大致是这样：

Main (Node2D)
 ├── Player (CharacterBody2D)
 ├── HUD (CanvasLayer)
 └── PauseMenu (CanvasLayer)

如果我们把所有状态放在自动加载里，那么 PauseMenu 检测到玩家按了暂停键，就直接把全局的 is_paused 改成 true，然后 Player 每帧去读这个全局变量决定要不要动。这个逻辑本身没问题，但会让 Player 和 PauseMenu 之间产生一种隐式耦合。它们彼此都不知道对方存在，却通过一个公共的瓶子来互相影响。

更好的做法是：让 Main 来协调这两个节点。

# Main.gd
extends Node2D

@onready var player: CharacterBody2D = $Player
@onready var hud: CanvasLayer = $HUD
@onready var pause_menu: CanvasLayer = $PauseMenu

func _ready() -> void:
    # 把各个子节点互相引用的关系，在父级统一设置好
    pause_menu.setup(player, hud)

然后在 PauseMenu 里：

# PauseMenu.gd
extends CanvasLayer

var player_node: Node
var hud_node: CanvasLayer

func setup(new_player: Node, new_hud: CanvasLayer) -> void:
    player_node = new_player
    hud_node = new_hud

func _input(event: InputEvent) -> void:
    if event.is_action_pressed("pause"):
        # 通过持有的引用去控制玩家，而不是改全局变量
        player_node.set_physics_process(false)
        hud_node.visible = false

再比如，玩家吃金币加分的那个场景。金币对象不需要知道 GameState 是谁，它只需要在收集的时候发送一个信号，让场景里的某个管理者来负责处理得分。

# Coin.gd
extends Area2D

signal coin_collected(value: int)

func _on_body_entered(body: Node2D) -> void:
    if body.name == "Player":
        coin_collected.emit(50)
        queue_free()

然后在关卡脚本里：

# Level1.gd
extends Node2D

@onready var score_label: Label = $HUD/ScoreLabel
var score := 0

func _ready() -> void:
    for coin in get_tree().get_nodes_in_group("coins"):
        coin.coin_collected.connect(_on_coin_collected)

func _on_coin_collected(value: int) -> void:
    score += value
    score_label.text = "分数：" + str(score)

你看，这样一来，金币不用知道有什么全局变量，它只负责发出“我被人捡了”的信号。至于谁接这个信号、接完之后干什么，那是关卡脚本的事情。我们把状态移动到了更合理的层级——每个关卡有一个自己的 score，而不是一个全局的 score。

3.2 优缺点

这种方式的优点非常明显：依赖关系显式化了。你能从代码里直接看出 PauseMenu 需要 player 和 hud，它能修改谁、不能修改谁，一目了然。而且每个关卡的数据互相隔离，不会出现上一关的残留数据污染下一关的情况。

缺点呢？就是写起来会稍微麻烦一点。你需要在父级手动传递引用，或者用 export 变量在编辑器里拖拽赋值。如果项目的节点层级特别深，你可能会写出很长的 $ 路径来访问一个远处的节点，这又会带来新的耦合。比如：

get_node("../../../../HUD/ScoreLabel")

这种字符串路径，一旦布局调整就得跟着改，特别容易坏。所以这种方式适合节点层级比较稳定、调用关系不复杂的场景。

四、替代方案之二：依赖注入与构造器模式

有些情况下，你的对象不需要一直存在于场景树里，它可能在运行时才被创建，比如一个动态生成的敌人，一个自定义的弹窗。这时候，你想给它传递依赖，就需要在创建它的时候把东西给进去。

这种方式叫做依赖注入，听着很学术，其实很简单，就是“你需要的引你直接拿着，不需要去找别人要”。

4.1 一个弹窗管理器的例子

比如你要做一个成就系统，当玩家达成某个条件时，屏幕右下角弹出一个成就提示。这个提示是一个独立的小场景，它需要知道成就名称和图标。你不必做一个“成就管理器”的全局单例，你可以在需要弹成就的地方，直接实例化这个提示场景，然后把需要的数据传进去。

# AchievementToast.gd
extends PanelContainer

var achievement_name: String
var icon: Texture2D

func setup(new_name: String, new_icon: Texture2D) -> void:
    achievement_name = new_name
    icon = new_icon
    # 拿到数据之后再去初始化界面，不要用全局变量来传递
    $NameLabel.text = achievement_name
    $Icon.texture = icon

然后在某个需要触发成就的脚本里：

# IceEnemy.gd
extends Enemy

# 敌人被玩家用冰属性技能杀死，触发冰系成就
func _on_died() -> void:
    # 直接创建一个弹出提示的实例
    var toast := preload("res://ui/achievement_toast.tscn").instantiate()
    toast.setup("冰霜之心", preload("res://icon/ice.png"))
    # 把它挂到 HUD 或者 CanvasLayer 下面
    get_tree().get_first_node_in_group("hud").add_child(toast)

这里没有用到任何自动加载，整个流程是：创建对象 → 调用 setup 方法传入数据 → 添加到场景树。这个 toast 跟其他脚本没有任何全局耦合，它自己知道自己的数据，生命周期也完全由调用方控制。

4.2 构造器模式的 GDScript 实现

我们还可以把这种思路再进一步，使用静态工厂方法来创建对象，同时把依赖打包传进去。

# WeaponFactory.gd
extends RefCounted

# 假设我们的武器需要一个伤害对象和一个特效播放器
static func create_weapon(weapon_id: String, damage_source: Node, effect_player: Node) -> Node2D:
    var weapon := Node2D.new()
    weapon.set_script(preload("res://weapons/sword.gd"))
    weapon.damage_source = damage_source
    weapon.effect_player = effect_player
    weapon.configure(weapon_id)
    return weapon

这样一来，武器不再需要去全局查找什么“特效管理器”，它只知道自己应该把特效播放在 effect_player 上。当初把它造出来的人，就是它的“知情人”。

4.3 优缺点

依赖注入的优点非常实在：可测试性变强了。你可以单独把一个武器拖到一个测试场景里，给它假的伤害对象和特效播放器，然后验证它的行为。这比依赖全局的自动加载要容易太多，因为你不需要先挂载整个 Global 脚本才能跑一个单元测试。

缺点是，如果你的游戏里到处都是长长的构造链，什么 A 需要 B，B 需要 C，C 需要 D，那你在创建 A 的时候，得先把 D、C、B 都准备好，代码会变得有点臃肿。所以这种方式更适合用于“中等复杂度的、单个对象依赖集中”的场景，而不是用来把所有状态都扔进一个巨型工厂。

五、替代方案之三：信号总线与事件驱动

上帝说，要有光，于是有了信号。Godot 的信号机制非常强大，但很多人只把它挂在按钮点击和碰撞检测上。其实，我们可以把信号当作一种完全的事件总线，用来解耦说话方和听话方。

5.1 什么是信号总线

信号总线，简单说就是：创建一个专门的对象，它自己不干活，只负责中转消息。其他脚本可以在上面订阅自己感兴趣的事件，也可以往上面发事件。这样做的好处是，生产者不知道消费者是谁，消费者也不知道生产者是谁，双方只认识一个中间的“频道”。

5.2 一个例子

我们还是用之前的得分系统。假设我们的游戏里有多个系统需要关注得分变化：HUD 要刷新得分显示，任务系统要检测得分目标，音效系统想听到得分的声音。如果用自动加载，你可能会这样写：

# autoload/GameManager.gd，所有人都依赖它
extends Node

var score := 0

func add_score(value: int):
    score += value
    HUD.update_score(score)
    QuestSystem.check_quest(score)
    AudioManager.play_sfx("score")

这个写法的问题在于，GameManager 知道太多。每增加一个新的需要对得分响应的系统，你都得到 GameManager 里加一行代码。这违反了开闭原则，更麻烦的是，如果 HUD 不存在了，GameManager 里直接调用 HUD.update_score 就会报错。

如果改用信号总线：

# events/EventBus.gd
extends Node

signal score_changed(new_score: int)
signal player_died()
signal game_paused(is_paused: bool)

你可以把它设置为自动加载，但是它不保存任何游戏状态，只负责广播信号。或者你也可以把它作为普通节点，挂到场景树某处，然后通过引用传递。

接下来，得分管理器（普通的 Node）负责维护分数：

# gameplay/ScoreManager.gd
extends Node

var score := 0

func add_score(value: int) -> void:
    score += value
    # 广播事件，谁需要谁自己接
    EventBus.score_changed.emit(score)

HUD 脚本只需要订阅这个信号：

# ui/HUD.gd
extends CanvasLayer

func _ready() -> void:
    EventBus.score_changed.connect(_on_score_changed)

func _on_score_changed(new_score: int) -> void:
    $ScoreLabel.text = "分数：" + str(new_score)

任务系统也订阅同一个信号：

# quests/QuestSystem.gd
extends Node

var target_score := 500

func _ready() -> void:
    EventBus.score_changed.connect(_check_quest_progress)

func _check_quest_progress(new_score: int) -> void:
    if new_score >= target_score and not completed:
        print("成就达成：得分500！")
        completed = true

你看，ScoreManager 根本不认识 HUD，也不认识 QuestSystem。它只负责发一个信号。以后你再加一个什么东西，比如连杀奖励系统，只需要在它的 _ready 里连接 score_changed 信号即可，不需要改动 ScoreManager 的任何代码。

5.3 信号总线本身的“坑”

有人可能会说：你这不还是一个全局的单例吗？确实，如果你把 EventBus 设置成自动加载，它在技术上仍然是一个全局对象。但关键在于，它的作用是“通信”，而不是“状态存储”。它里面只有信号，没有可变的业务数据。所以不会出现一个脚本把 EventBus.score 改成乱七八糟的值的风险。信号是只读的——只能发，不能改。

不过，信号总线也有自己的问题。如果事件定义得太多太碎，你会看到几百个信号堆在一个文件里，找起来也很痛苦。而且，过度使用信号会让程序的控制流难以跟踪。比如你点了一个按钮，它正常情况应该直接调用一个方法，但如果你改成发信号，那么可能有三四个地方同时响应，并且响应顺序不好控制。所以要克制，只在“一对多”或“跨模块”的时候用信号总线。

六、替代方案之四：资源对象与数据共享

最后一个方案可能很多人没意识到：Godot 的资源(Resource)也可以作为数据容器共享。你不需要自动加载，也可以让多个节点引用同一个资源文件。当你修改资源的属性时，所有引用它的节点都会看到更新后的值。

6.1 资源作为共享状态

举个例子。我们要做一个“游戏设置”面板，里面有音量大小、是否开启震动这些选项。你不需要一个全局 Settings 单例，你只需要创建一个设置资源：

# data/GameSettings.gd
extends Resource
class_name GameSettings

@export var master_volume: float = 1.0
@export var music_volume: float = 0.8
@export var sfx_volume: float = 0.9
@export var is_vibration_enabled: bool = true

然后你在文件系统里创建一份 .tres 资源文件（或者通过代码创建）。在任何一个脚本里，你都可以通过 load("res://data/game_settings.tres") 拿到这个资源，并读写它的属性。当你修改音量时，其他读取同一份资源的节点自然就会拿到新值。

6.2 结合编辑器使用

在 Godot 编辑器里，你可以直接创建一个 GameSettings 资源文件，然后在多个节点的 Inspector 面板里拖进去。比如你的 AudioManager 持有一个 settings 资源，你的 SettingsUI 也持有同一个资源。当 UI 修改 settings.music_volume 时，AudioManager 在每帧检查或者响应信号，音量就变了。

# audio/AudioManager.gd
extends Node

@export var settings: GameSettings

func _process(_delta: float) -> void:
    # 持续把音量应用到音乐播放器上
    $MusicPlayer.volume_db = linear_to_db(settings.music_volume)

6.3 优缺点

资源的优点在于，它天然支持序列化和持久化。你把配置保存为一个 .tres 文件，它就是一个数据文件。你甚至可以直接在编辑器里修改它，不需要写任何加载或保存逻辑。

缺点呢？资源是共享引用，所以也有全局可变状态的影子。如果你在运行时恶意修改资源属性，其他引用它的节点也会受影响。不过你可以把资源设计成只读的，或者每次修改后发送通知信号。总之，资源适合保存“全局配置”这类变化频率低、影响范围大的数据，而不适合保存玩家血量、武器弹药这类高频变化的临时状态。

七、应用场景总结：什么时候用哪种

既然列出了这么多方案，我们来整理一下，到底在什么场景下该选哪一种。

7.1 适合用自动加载的场景

自动加载并不是不能用，而是要用得克制。它更适合作“基础设施”，比如：

• 一个纯粹的日志记录器，只负责输出调试信息，不保存游戏状态。
• 一个事件总线，里面只放信号，没有业务变量。
• 一个资源缓存管理器，负责加载和复用纹理、音频等资源。
• 一个保存系统，你在存档时调用 SaveSystem.save_game()，它内部只做 IO，不参与具体游戏逻辑。

这些场景的共同点是：它们不承载“可变业务状态”，或者它们本身就是无状态的工具。你不用担心某个脚本会乱改它们。

7.2 适合用显式传递的场景

当你需要临时控制某个节点的行为，或者节点之间的关系只在特定布局下成立时，用显式传递最好。比如：

• 主场景控制暂停菜单和玩家。
• 一个关卡脚本控制该关卡内的敌人刷新和得分统计。
• 战斗场景中的技能对象需要引用施法者和目标。

7.3 适合用依赖注入的场景

当你需要动态创建对象，且这些对象依赖特定的外部服务时，用依赖注入。比如：

• 生成敌人时，把玩家节点和掉落管理器传进去。
• 创建自定义弹窗时，传入回调函数或目标节点。
• 测试某个模块时，传入假的依赖。

7.4 适合用信号总线的场景

当你碰到“一个事件触发多个系统响应”的情况时，使用事件总线。比如：

• 玩家死亡，HUD 需要显示，任务需要重置，音效需要播放，关卡可能需要重新加载。
• 得分变化，UI、任务、连击系统、动画系统都要知道。
• 游戏暂停，所有控制器都要停止，但不同系统处理方式不同。

7.5 适合用资源共享的场景

当你需要跨模块访问同一个配置数据，或者想要一个数据在多个节点之间同步变化时，资源好物上场。比如：

• 游戏音量设置。
• 画面质量设置。
• 玩家手头的收藏品列表（这个也可以用资源保存，前提是列表不是高频变化的）。

八、技术优缺点再深入一下

了解了场景，我们再从“可维护性”“性能”“调试”三个角度来对比这些方案。

8.1 可维护性

从长期维护的角度来看，自动加载的评分是最低的。为什么呢？因为它在代码里注入了一个隐式的全局依赖。你只有打开项目设置才能知道存在一个 GameManager，而代码里写 GameManager.player_hp = 5 的地方，从字面上根本看不出这个 GameManager 是从哪儿来的。一旦项目大起来，你审代码的时候就得经常切到自动加载列表去确认。

显式传递和依赖注入的可维护性最好。每个接口都告诉你它需要什么，你拿到一个代码文件就能看懂它的依赖关系。信号总线在“解耦”这个层面的可维护性也很高，但要注意不要过度使用。

8.2 性能

自动加载在性能上没有什么特别大的优势。它就是一个单例，访问它的字典或变量，跟访问普通对象没有区别。真正的性能问题来源于全局状态的“脏读”，你没法确定某个状态是不是最新的，有时候不得不每帧去轮询它，那才叫浪费。

信号总线的性能取决于事件频率。如果你每帧发送几百个事件，那可能会有些开销，但一般游戏里的系统事件不会有那么高频。资源共享的性能也不错，毕竟只是引用同一个对象。

8.3 调试

调试体验最差的就是自动加载。你不知道谁修改了状态，只能打日志，然后猜。显式传递和依赖注入在做单元测试的时候非常舒服——你可以构造一个测试环境，传一个 mock 对象进去。信号总线差点意思，因为信号的发出点容易藏起来。当你在代码里搜索某个信号的发出位置，可能一下子找不到，因为 emit 和 connect 是分开的。所以信号总线的调试是有一点成本的，你需要有一个全局的事件注册列表，或者用 debug 工具。

九、实际演进中的注意事项

我知道很多项目一开始都是自动加载起家的，然后在某个大型需求完成后开始重构。这里给你几条实操建议。

9.1 不要一刀切立刻删掉所有自动加载

如果你现在有一个项目已经用了很多自动加载，你千万别想着一个晚上全部干掉。那样你会陷入无尽的编译错误。更好的做法是，先一个一个来。

把自动加载里的数据按“可变状态”和“不可变状态”分开。不可变状态的可以保留在自动加载里当全局工具；可变状态的一步步挪到场景中或者用信号传递。

9.2 给自动加载脚本加访问控制

如果你暂时不能改掉自动加载，你可以在脚本里加一些约束，比如把变量设为私有、限制修改入口、只允许通过方法修改，并加日志。

# autoload/PlayerData.gd
extends Node

var score: int = 0 :
    set(value):
        # 不管谁改，都打一条日志
        print("score 被修改为：", value, " 调用栈：", get_stack())
        score = value

get_stack() 可以帮你看调用来源，不过注意它只在调试构建里可用。

9.3 优先抽象行为，再考虑数据

如果你在写一个新系统，先想清楚这个系统需要哪些操作，而不是需要哪些状态。比如“排行榜”系统，不一定需要一个全局的高分变量，它只需要一个“提交分数”的方法。把方法定义好，内部存储用什么方案你随便换。这样你以后想从自动加载改成信号总线，只需要改方法内部的实现，不需要改调用方。

9.4 使用组(group)来替代部分全局引用

Godot 里的组是个被低估的工具。当你不想用一个全局单例，但又不想手动传递引用时，你可以把某些节点加到同一组里，然后用 get_tree().get_first_node_in_group("player") 去查找。

# 在 Player 的 _ready 里
add_to_group("player")

# 在敌人的脚本里
func _on_died() -> void:
    var player = get_tree().get_first_node_in_group("player")
    if player:
        player.add_score(100)

这种做法比自动加载好一点，因为组是临时性的，节点退出场景树后会从所有组里移除。它的耦合度也低一些，因为你没有直接引用全局脚本的类型，只是通过字符串标签查找。但这仍然是一种隐式依赖，用的时候要慎重，别每个地方都 get_first_node_in_group("xxx")，否则很难追踪。

9.5 让全局状态只有一个所有者

如果你实在需要一个全局比分，比如一个跨关卡的累计分数，那请确保这个分数只有一个脚本能写。其他脚本只能通过接口来请求修改。例如：

# autoload/GameSession.gd
extends Node

var _total_score: int = 0

func add_score(v: int) -> void:
    _total_score += v
    get_tree().call_group("hud", "update_score", _total_score)

外部不能直接访问 _total_score，只能调用 add_score。这样你至少能比较清晰地知道：分数只有这一个入口会变，排查问题就简单多了。

十、文章总结

我们绕了一大圈，其实核心就一句话：全局状态是有用的，但你得小心它被滥用。

Godot 的自动加载是一个强大的工具，它适合做基础设施和纯工具，不适合做存放可变游戏状态的仓库。当你发现自己的自动加载脚本里堆满了变量，并且这些变量在各个角落被随手修改的时候，你其实已经踩进了全局状态污染的泥潭。

替代它的方案并不神秘，无非是：

• 在场景树里显式地传递引用，让依赖关系看得见。
• 用依赖注入的方式在创建对象时塞入它需要的一切。
• 用信号事件来解耦多系统响应，让消息在节点之间飞来飞去。
• 用资源对象来共享一些低频配置数据。

我个人建议你根据功能的性质来组合使用，而不是死守某一个模式。比如，全局事件总线配合局部显式传递，是在中小型项目里非常好用的一套组合。你可以在关键系统之间用信号，在单次调用链上直接传引用，这样既保证解耦又没有太多隐式依赖。

最后，当你开始重构自动加载脚本时，请保持耐心。先让一个新的独立节点继承你原来的功能，然后在新的脚本里逐步把依赖从全局变量改成局部变量，每改一步就运行一次游戏，确认没有破坏任何功能。代码是你的游戏的地基，地基歪了，后面再怎么盖楼都会摇摇欲坠。与其在崩溃的边缘抓耳挠腮，不如试着把那些全局状态一个个放进应该属于它们的盒子里去。毕竟，写代码和过日子一样，清清爽爽的才舒服。