企业官网建设流程全解析

1. 项目概述：为什么我们要告别拖拽连线？

如果你在Godot 4里用过C#，大概率经历过这样的场景：想给一个按钮的Pressed信号连个处理函数，或者让一个计时器Timeout时触发点啥，第一反应就是切回编辑器，在场景树里找到节点，在检查器里找到信号列表，然后拖一根线到脚本里，选择或创建一个方法。这个过程直观吗？直观。高效吗？对于简单原型或者一次性连接，还行。但当你项目规模稍微大一点，节点结构复杂一点，或者需要动态创建节点并连接信号时，这种“可视化拖拽”的局限性就暴露无遗了。

想象一下，你动态生成了一排敌人，每个敌人被击中时都需要播放音效、更新UI分数、并可能触发一个全局事件。用拖拽连线？你需要在编辑器里预先放置好这些敌人作为场景实例，然后手动一个个去连——这几乎不可能，也不符合程序化生成的需求。再比如，你有一个复杂的UI系统，很多控件和逻辑是在运行时根据数据动态创建的，它们的交互逻辑（信号连接）也必须动态建立。这时候，代码连接信号就成了唯一且更优的选择。

用C#代码连接信号，不仅仅是“可以这么做”，它带来的好处是实实在在的：可维护性、动态性和类型安全。你的所有逻辑都集中在代码里，版本控制时清晰明了，重构时IDE的“查找所有引用”能准确定位到每一个连接点，而不是散落在看不见的.tscn文件资源链接里。动态创建节点时，信号连接可以紧随其后，逻辑自包含。而C#的事件语法（+=）和Lambda表达式，让这种连接变得异常简洁和强大。

所以，今天我们就彻底告别那个有时显得笨拙的拖拽连线，深入Godot 4的C#信号系统，看看如何用代码玩转它，特别是结合Lambda表达式，写出既清晰又强大的动态逻辑。

2. 核心概念：Godot信号与C#事件的桥梁

在深入代码之前，我们必须理解Godot的信号系统在C#中是如何映射的。这不仅仅是语法转换，更是两种设计模式的融合。

2.1 Godot信号的本质

在Godot中，信号（Signal）是节点间通信的基石，是一种观察者模式的实现。一个节点（发射器）可以“发射”（Emit）一个信号，而其他任意数量的节点（接收器）可以“连接”（Connect）到这个信号上，指定当信号发射时要调用的函数（回调）。这种松耦合的设计让游戏对象之间的交互变得非常灵活。

在GDScript中，你使用connect(signal_name, callable)，在C#中，Godot通过自动生成的代码，将每个信号都包装成了一个标准的C#事件（Event）。这意味着你可以像处理Button.Click事件一样，使用+=和-=运算符来添加和移除事件处理器。

2.2 C#中的信号：事件与委托

当你创建一个继承自GodotObject（比如Node）的C#脚本，并在其中使用[Signal]特性声明一个委托时，Godot的构建系统会在后台为你做一件重要的事：生成一个同名（去掉EventHandler后缀）的C#事件，以及一个用于发射信号的EmitSignal方法调用封装。

// 在你的C#脚本中声明 [Signal] public delegate void HealthDepletedEventHandler(); [Signal] public delegate void DamageTakenEventHandler(int amount, Node source);

构建项目后，你就可以像使用内置信号一样使用它们：

// 连接信号 HealthDepleted += OnPlayerDied; DamageTaken += (amount, source) => GD.Print($"Took {amount} damage from {source.Name}"); // 发射信号 EmitSignal(SignalName.HealthDepleted); EmitSignal(SignalName.DamageTaken, 10, someEnemyNode);

这里的SignalName是一个自动生成的嵌套类，包含了所有信号名称的字符串常量，用于在EmitSignal等方法中引用，提供了编译时的名称检查，避免拼写错误。

2.3 动态连接与静态连接的选择

你可能会问，既然有+=这么好用的语法，为什么Godot还保留了旧的Connect/DisconnectAPI？主要有两个原因：

1. 连接标志（ConnectFlags）：Connect方法允许你传递额外的标志，例如ConnectFlags.OneShot（单次连接，触发后自动断开）或ConnectFlags.Deferred（延迟到下一帧处理）。这在某些特定场景下非常有用。
2. 连接GDScript或其他语言定义的信号：虽然C#事件是首选，但当你需要连接一个由GDScript脚本定义并发射的信号时，使用Connect并传递一个Callable对象是更通用的方式。

不过，对于绝大多数由C#定义和消费的信号，强烈建议使用+=和-=运算符。它们更符合C#开发者的习惯，提供了更好的类型安全性和IDE支持（如智能提示、重命名重构）。

3. 实战演练：从基础连接到Lambda高级用法

理论说再多不如动手试。我们来构建几个典型的游戏场景，看看如何用代码优雅地处理信号。

3.1 基础连接：UI按钮与计时器

这是最常见的场景。假设我们有一个简单的UI，包含一个按钮和一个标签。点击按钮后，启动一个2秒的计时器，计时结束后更新标签文本。

首先，在场景中放置好Button、Timer和Label节点，并将它们拖拽到C#脚本的导出属性中。

using Godot; using System; public partial class MyUIController : Control { [Export] private Button _startButton; [Export] private Timer _countdownTimer; [Export] private Label _statusLabel; public override void _Ready() { // 基础连接：使用命名方法 _startButton.Pressed += OnStartButtonPressed; _countdownTimer.Timeout += OnCountdownTimerTimeout; } private void OnStartButtonPressed() { _statusLabel.Text = “计时开始...”; _countdownTimer.Start(2.0); _startButton.Disabled = true; // 防止重复点击 } private void OnCountdownTimerTimeout() { _statusLabel.Text = “时间到！”; _startButton.Disabled = false; } }

这很直观。_Ready中建立了连接，当信号发射时，对应的命名方法被调用。但这里有个小问题：OnCountdownTimerTimeout方法只做了一件事，就是更新标签和按钮状态。对于这种简单的回调，我们可以让它更简洁。

3.2 引入Lambda表达式：让代码更紧凑

Lambda表达式本质上是一个匿名函数。它允许我们直接在连接信号的地方定义要执行的操作，无需单独声明一个方法。

public override void _Ready() { _startButton.Pressed += OnStartButtonPressed; // 保留一个命名方法，如果逻辑复杂 // 使用Lambda表达式连接Timer.Timeout _countdownTimer.Timeout += () => { _statusLabel.Text = “时间到！”; _startButton.Disabled = false; }; }

看，OnCountdownTimerTimeout方法消失了，逻辑被内联了。对于简单的、一次性（或作用域明确）的回调，Lambda极大地减少了代码跳转，让相关逻辑聚集在一起，提高了可读性。

注意：过度使用Lambda，尤其是在它们捕获（Capture）了外部变量且生命周期管理不当时，可能导致难以察觉的内存泄漏或ObjectDisposedException。我们稍后会详细讨论。

3.3 捕获外部变量：实现动态行为

Lambda表达式的强大之处在于它能“捕获”定义它的作用域内的变量。这使得我们可以创建高度动态和上下文相关的回调。

假设我们有一个敌人生成器，每波生成多个敌人，每个敌人都有一个独立的血量。当敌人死亡时，我们需要更新当前波的剩余敌人数。

public partial class EnemySpawner : Node2D { [Export] private PackedScene _enemyScene; private int _enemiesRemainingInWave; public void SpawnWave(int waveNumber, int enemyCount) { _enemiesRemainingInWave = enemyCount; GD.Print($"第 {waveNumber} 波开始，敌人数量：{enemyCount}"); for (int i = 0; i < enemyCount; i++) { var enemyInstance = _enemyScene.Instantiate<Enemy>(); AddChild(enemyInstance); enemyInstance.GlobalPosition = GetRandomSpawnPosition(); // Lambda捕获了当前波的剩余敌人数 `_enemiesRemainingInWave` // 也捕获了循环变量 `i`（注意闭包问题！） int enemyIndex = i; // 关键步骤：创建局部副本 enemyInstance.Died += () => OnEnemyDied(enemyIndex); } } private void OnEnemyDied(int index) { _enemiesRemainingInWave--; GD.Print($"敌人 {index} 被击败。剩余敌人：{_enemiesRemainingInWave}"); if (_enemiesRemainingInWave <= 0) { GD.Print(“当前波次清理完毕！”); } } }

这里有两个关键点：

1. 捕获成员变量：Lambda内部使用了_enemiesRemainingInWave，它属于EnemySpawner实例。这没问题，Lambda会持有对该实例中间接引用。
2. 捕获循环变量：直接捕获循环变量i是一个经典的C#闭包陷阱。因为i在循环中是被重用的，所有Lambda捕获的都是同一个变量i，最终所有回调看到的i值都是循环结束后的值（enemyCount）。解决方法：在循环内创建一个局部变量（如enemyIndex）来存储当前迭代的值，然后捕获这个局部变量。这样每个Lambda都捕获了自己独立的副本。

3.4 带参数的信号与Lambda

Godot信号可以携带参数，这些参数在C#事件中会对应到委托的参数。在Lambda中，你可以直接使用这些参数。

public partial class HealthComponent : Node { [Signal] public delegate void HealthChangedEventHandler(float oldHealth, float newHealth); [Signal] public delegate void DeathEventHandler(Node attacker); private float _currentHealth = 100.0f; public void TakeDamage(float amount, Node attacker) { float oldHealth = _currentHealth; _currentHealth = Mathf.Max(_currentHealth - amount, 0); EmitSignal(SignalName.HealthChanged, oldHealth, _currentHealth); if (_currentHealth <= 0) { EmitSignal(SignalName.Death, attacker); } } } // 在另一个脚本中连接 public override void _Ready() { var healthComp = GetNode<HealthComponent>("../HealthComponent"); // Lambda接收信号参数 healthComp.HealthChanged += (oldHp, newHp) => { float damageTaken = oldHp - newHp; _damagePopup.ShowDamage(damageTaken); _healthBar.Value = newHp; }; healthComp.Death += (killer) => { GD.Print($"{Name} 被 {killer?.Name ?? \"未知来源\"} 击败了！"); QueueFree(); // 销毁自身 }; }

通过Lambda的参数列表(oldHp, newHp)和(killer)，我们可以直接处理信号传递过来的数据，代码非常紧凑。

4. 进阶技巧与避坑指南

掌握了基础用法，我们来看看一些更高级的场景和必须警惕的“坑”。

4.1 动态连接与断开：管理生命周期

对于动态创建的节点（如子弹、特效、临时UI），务必管理好其信号连接的生命周期。最安全的模式是：谁连接，谁负责断开。

推荐模式：在节点的_Ready或创建后立即连接，在_ExitTree、TreeExiting信号或Dispose（对于RefCounted）时断开。

public partial class Projectile : Area2D { [Signal] public delegate void CollidedEventHandler(Node body); private Area2D _detectionArea; private IDisposable _collisionSubscription; // 用于保存连接引用 public override void _Ready() { _detectionArea = GetNode<Area2D>("DetectionArea"); // 连接信号，并保存返回的“可断开连接”对象（这是一个简化示例，实际需适配） // 注意：Godot C# 事件 (`+=`) 返回 void，不能直接保存。 // 对于需要显式管理的情况，可以考虑使用一个Action成员变量。 _onBodyEnteredAction = (Node body) => OnBodyEntered(body); _detectionArea.BodyEntered += _onBodyEnteredAction; } // 定义一个委托实例成员，用于后续断开 private Action<Node> _onBodyEnteredAction; private void OnBodyEntered(Node body) { EmitSignal(SignalName.Collided, body); // ... 处理碰撞逻辑 } public override void _ExitTree() { // 在节点离开场景树时断开连接，防止内存泄漏 if (_detectionArea != null && _onBodyEnteredAction != null) { _detectionArea.BodyEntered -= _onBodyEnteredAction; } base._ExitTree(); } }

对于使用+=连接的内置信号或自定义信号事件，你需要自己保存一个对委托（如Action或EventHandler）的引用，以便在-=时使用。对于Lambda表达式，这意味着你需要将它赋值给一个成员变量。

更简洁的做法（适用于许多情况）：如果接收方（连接信号的对象）的生命周期短于或等于发射方，并且你使用的是非捕获外部变量的Lambda连接内置信号，那么Godot通常能在接收方被释放时自动清理连接。但依赖这种行为需要谨慎，明确的生命周期管理是更稳健的做法。

4.2 使用Connect与Callable进行更灵活的控制

当你需要OneShot（单次）连接，或者需要连接一个来自GDScript等其他语言脚本的信号时，就需要用到Connect方法。

// 单次连接：这个信号只处理一次，之后自动断开 someButton.Connect(Button.SignalName.Pressed, Callable.From(() => GD.Print("Button pressed once!")), (uint)GodotObject.ConnectFlags.OneShot); // 连接一个GDScript节点发射的信号 // 假设 `gdScriptNode` 有一个名为 `custom_signal` 的信号 gdScriptNode.Connect("custom_signal", Callable.From((string data) => { GD.Print($"Received from GDScript: {data}"); }));

Callable.From是一个非常重要的工具，它可以将C#的方法（包括Lambda）转换为Godot引擎能理解的Callable对象。这在需要与引擎底层API或非C#脚本交互时是必需的。

4.3 Lambda捕获与内存泄漏的陷阱

这是C# Godot开发中最容易踩的坑之一。回顾一下官方文档的警告：当信号连接到一个捕获了外部变量的Lambda表达式，且接收器被释放而发射器仍存活时，自动断开连接可能不会发生。

看一个危险示例：

public partial class Trap : Area2D { private Timer _activationTimer; public override void _Ready() { _activationTimer = GetNode<Timer>("ActivationTimer"); int triggerCount = 0; // 局部变量 // Lambda 捕获了局部变量 triggerCount 和 `this` (Trap实例) _activationTimer.Timeout += () => { triggerCount++; GD.Print($"陷阱 {Name} 第 {triggerCount} 次触发"); if (triggerCount > 3) { GD.Print("陷阱失效"); QueueFree(); // 销毁陷阱自身 } }; _activationTimer.Start(1.0); } }

这里发生了什么？Timeout事件的Lambda捕获了局部变量triggerCount和this（即Trap实例）。当QueueFree()被调用，Trap节点开始销毁。但是，Timer节点（_activationTimer）可能还活着（比如它是场景中的另一个独立节点）。Lambda因为捕获了triggerCount，其生成的闭包对象可能并不直接被Trap实例所“拥有”，导致Godot的自动断开机制失效。Timer仍然持有着对那个Lambda委托的引用，而该委托间接引用着已被销毁的Trap实例的部分状态（理论上triggerCount已不存在），这可能导致访问违例或内存无法回收。

解决方案：

1. 手动管理：像之前一样，将Lambda保存为成员变量，在_ExitTree中手动断开。

   private Action _timeoutAction; public override void _Ready() { _activationTimer = GetNode<Timer>("ActivationTimer"); int triggerCount = 0; _timeoutAction = () => { /* ... */ }; _activationTimer.Timeout += _timeoutAction; } public override void _ExitTree() { if (_activationTimer != null && _timeoutAction != null) { _activationTimer.Timeout -= _timeoutAction; } base._ExitTree(); }

2. 避免在长生命周期对象上捕获易变局部变量：考虑将triggerCount提升为成员变量，这样Lambda捕获的是this，Godot在Trap释放时更容易正确断开（尽管对于自定义信号+捕获变量的情况，文档仍提示可能有问题，但作为成员变量逻辑更清晰）。
3. 使用WeakReference（弱引用）：如果回调中只需要“知道”某个对象是否存在，而不需要调用其方法，可以考虑使用WeakReference。但这在Godot中并不常用，因为节点管理通常更直接。

经验法则：对于动态创建、生命周期较短的节点，或者连接到生命周期更长的节点（如全局的Autoload单例）的信号，总是考虑在接收方被销毁时显式断开连接。

4.4 性能考量：Lambda vs 命名方法

从性能角度看，对于只创建少数几次的简单Lambda，其开销可以忽略不计。但是，如果你在每帧都创建大量新的Lambda（例如在_Process中连接又断开），这会产生垃圾回收（GC）压力。对于高频触发的信号，使用预定义的命名方法效率更高，因为委托实例可以被重用。

不过，在绝大多数游戏逻辑中，信号的连接发生在初始化阶段（_Ready），其性能差异微乎其微。可读性和维护性应该是首要考虑因素。对于简单的、内联的逻辑，使用Lambda；对于复杂的、多行的、或被多个地方共享的逻辑，使用命名方法。

5. 综合案例：构建一个可重用的弹窗系统

让我们把这些知识融会贯通，设计一个用代码管理信号的小型弹窗系统。这个系统支持显示消息，并在玩家点击“确认”或“取消”时触发不同的事件。

// PopupDialog.cs using Godot; using System; public partial class PopupDialog : Control { [Signal] public delegate void ConfirmedEventHandler(); [Signal] public delegate void CancelledEventHandler(); [Export] private Label _messageLabel; [Export] private Button _confirmButton; [Export] private Button _cancelButton; [Export] private AnimationPlayer _animPlayer; // 用于保存连接，以便在隐藏时断开，防止重复触发 private Action _onConfirmAction; private Action _onCancelAction; public void ShowDialog(string message, Action onConfirm = null, Action onCancel = null) { _messageLabel.Text = message; Visible = true; _animPlayer.Play("show"); // 清理之前的连接 if (_onConfirmAction != null) _confirmButton.Pressed -= _onConfirmAction; if (_onCancelAction != null) _cancelButton.Pressed -= _onCancelAction; // 设置新的回调 _onConfirmAction = () => { onConfirm?.Invoke(); EmitSignal(SignalName.Confirmed); HideDialog(); }; _onCancelAction = () => { onCancel?.Invoke(); EmitSignal(SignalName.Cancelled); HideDialog(); }; // 连接信号 _confirmButton.Pressed += _onConfirmAction; _cancelButton.Pressed += _onCancelAction; } private void HideDialog() { _animPlayer.PlayBackwards("show"); // 动画结束后隐藏的逻辑可以在动画轨道中调用一个方法 // 这里简单处理 Visible = false; // 对话框隐藏后，断开按钮连接，避免在不可见时误触发 // 注意：如果对话框会被复用，断开是必要的。如果每次ShowDialog都新建，则不需要。 if (_onConfirmAction != null) { _confirmButton.Pressed -= _onConfirmAction; _onConfirmAction = null; } if (_onCancelAction != null) { _cancelButton.Pressed -= _onCancelAction; _onCancelAction = null; } } // 提供一个静态工具方法，方便快速创建和显示弹窗 public static PopupDialog Show(SceneTree tree, string message, Action onConfirm = null, Action onCancel = null) { var dialogScene = GD.Load<PackedScene>("res://ui/popup_dialog.tscn"); var dialogInstance = dialogScene.Instantiate<PopupDialog>(); tree.Root.AddChild(dialogInstance); dialogInstance.ShowDialog(message, onConfirm, onCancel); return dialogInstance; } }

使用示例：

// 在某个游戏管理器或UI控制器中 public void OnPlayerTriedToQuit() { PopupDialog.Show(GetTree(), “确定要退出游戏吗？所有未保存的进度将会丢失。”, onConfirm: () => GetTree().Quit(), onCancel: () => GD.Print(“玩家选择继续游戏”) ); // 或者连接其信号 // var dialog = PopupDialog.Show(...); // dialog.Confirmed += () => GetTree().Quit(); // dialog.Cancelled += () => GD.Print("Cancelled"); }

这个案例展示了：

1. 自定义信号：Confirmed和Cancelled。
2. Lambda表达式：在ShowDialog方法内联定义了按钮的回调逻辑，并捕获了传入的onConfirm和onCancel委托。
3. 生命周期管理：在ShowDialog中先断开旧连接（防止重复绑定），在HideDialog中断开当前连接，确保回调不会在对话框隐藏后意外执行。
4. 静态工具方法：提供了便捷的创建和显示入口，调用者可以用Lambda快速定义行为。

6. 常见问题与排查技巧实录

在实际开发中，你肯定会遇到一些关于信号的问题。这里记录了一些典型场景和解决方法。

6.1 信号连接了，但为什么不触发？

1. 检查发射方和接收方的生命周期：确保发射信号的节点在发射时处于场景树中且未被暂停（ProcessMode不是Disabled）。确保接收方节点也处于活动状态。
2. 检查连接时机：如果你在_Ready中连接信号，但信号在_Ready被调用之前就可能被发射（例如，在_Init或构造函数中），那么连接会错过。确保连接发生在可能发射之前。
3. 自定义信号需要构建项目：如果你在C#中声明了[Signal]，但在编辑器的信号列表里看不到它，无法拖拽连接，必须重新构建（Build）C#项目。点击Godot编辑器右上角的“构建”按钮（锤子图标）。
4. 拼写错误：使用EmitSignal(SignalName.MySignal)而不是字符串字面量，可以利用编译时检查。
5. 参数不匹配：发射信号时提供的参数数量、类型必须与信号声明一致。

6.2 遇到ObjectDisposedException怎么办？

这通常是因为一个已被释放（QueueFree()或Dispose()）的节点，其方法仍被某个信号回调尝试调用。

• 首要怀疑对象：捕获了外部变量的Lambda表达式连接到了长生命周期对象（如全局计时器、游戏管理器）。当Lambda所属的节点被销毁，但连接未断开，下一次信号触发就会导致此异常。
• 排查步骤：
  1. 审查所有使用Lambda进行信号连接的代码。
  2. 确认Lambda是否捕获了任何局部变量或this。
  3. 如果是，确保在接收方节点（即定义Lambda的脚本所属的节点）的_ExitTree或合适的销毁时机，使用保存的委托引用进行手动断开（-=）。
  4. 对于自定义信号，即使使用命名方法连接，如果接收方先于发射方被释放，也可能需要手动断开。保险起见，在_ExitTree中遍历并断开所有连接到外部对象的自定义信号是一个好习惯。

6.3 如何调试信号连接？

• 打印日志：在连接和断开时，以及信号处理函数开头添加GD.Print，观察执行顺序。
• 使用GetSignalConnectionList：这是一个很有用的调试方法，可以获取连接到某个信号的所有Callable信息。你可以在控制台打印出来查看。

  foreach (var conn in someNode.GetSignalConnectionList("my_signal")) { GD.Print($"连接到: {conn["target"]} 的方法: {conn["method"]}"); }

  （注意：这个方法返回的是Godot.Collections.Array<Godot.Collections.Dictionary>，信息可能不如C#事件直观，但对调试底层连接有帮助。）
• IDE调试器：在信号处理函数中设置断点，是最直接的查看调用栈和状态的方法。

6.4 性能敏感场景下的优化

• 避免在热路径（如_Process、_PhysicsProcess）中频繁连接/断开信号：这会产生大量的委托分配和垃圾回收。尽量在初始化阶段（_Ready）建立稳定的连接。
• 对于大量同类对象：考虑使用对象池。当从池中取用对象时，在其“激活”方法中连接信号；当放回池中时，在其“重置”或“禁用”方法中断开所有信号。这能有效复用委托，减少GC。
• 谨慎使用匿名Lambda捕获大型对象：如果Lambda捕获了一个很大的对象图（例如，通过this捕获了整个父节点层级），即使你的节点被释放，只要Lambda还被引用，这些被捕获的对象就无法被GC回收。尽量让Lambda只捕获它真正需要的最小数据集。

7. 总结与最佳实践建议

告别拖拽连线，拥抱代码化信号连接，是迈向更高级、更可控的Godot C#开发的关键一步。我们来总结一下核心要点和最佳实践：

1. 首选C#事件语法（+=/-=）：对于C#脚本之间，尤其是自定义信号，这是最类型安全、最符合语言习惯的方式。
2. 善用Lambda表达式简化代码：对于简单的、内联的回调逻辑，Lambda能让代码更紧凑、更聚焦。但要警惕其捕获变量带来的生命周期问题。
3. 明确生命周期，手动管理连接：对于动态创建的对象、或连接到长生命周期对象的信号，务必在接收方被销毁时（_ExitTree）显式断开连接。不要完全依赖Godot的自动清理，特别是在使用捕获变量的Lambda或自定义信号时。
4. 复杂逻辑使用命名方法：如果回调逻辑超过3-5行，或者该逻辑被多个信号共享，将其提取为命名方法。这提高了可测试性和代码复用性。
5. 利用Callable.From进行桥接：当你需要与ConnectAPI、OneShot标志或非C#脚本交互时，Callable.From是你的好帮手。
6. 构建项目以更新自定义信号：在编辑器中添加或修改[Signal]声明后，记得构建C#项目，否则编辑器无法识别。
7. 调试是朋友：遇到信号不触发或对象已释放异常时，善用GD.Print和GetSignalConnectionList进行调试。

最后，我个人在实际项目中的体会是：将信号连接视为对象关系的一部分。在节点的_Ready方法中建立连接，在_ExitTree中清理连接，这种模式就像C#中的IDisposable模式一样，能建立起清晰的对象生命周期契约，极大地减少了难以追踪的bug。一开始多花一点时间思考信号的管理策略，会在项目后期为你省下大量的调试时间。现在，就去你的Godot 4 C#项目里，把那些拖拽的连线用优雅的代码替换掉吧！