Godot C#开发实战：从环境配置到性能优化的完整避坑指南

1. 项目概述与核心痛点最近用 Godot 3.5.3 搭配 C# 完整地做了一款 2D 游戏从零开始一路踩坑也一路填坑。如果你也打算用这个技术栈入门或者正在其中挣扎这篇分享或许能帮你省下不少折腾的时间。Godot 本身是个非常优秀的开源引擎轻量、高效节点化设计思路清晰。但当你选择 C# 作为脚本语言时情况会变得有些微妙——官方文档和社区资源大多围绕 GDScript 展开C# 相关的“最佳实践”和“避坑指南”散落在各处很多问题需要你亲自撞了南墙才能找到答案。我这次的项目是一个 2D 平台动作游戏涉及角色控制、物理交互、动画状态机、UI 管理以及简单的敌人 AI。整个过程下来最大的感受是Godot 的 C# 支持已经足够强大到可以用于生产但它的工作流、性能特性和一些细节处理与纯 GDScript 开发有显著不同。你不仅要熟悉 Godot 的引擎逻辑还得处理好 .NET 环境、IDE 集成、构建过程以及两者之间微妙的交互方式。下面我就把这些踩过的“坑”和总结出的高效技巧毫无保留地分享出来。2. 环境搭建与项目初始化的那些“坑”万事开头难Godot C# 的环境配置就是第一个拦路虎。虽然官方提供了 .NET 版本的编辑器但直接上手还是会遇到不少预料之外的问题。2.1 运行时与 SDK 的版本迷宫第一个大坑就是 .NET 运行时和 SDK 的版本选择。Godot 3.5.x 官方支持的是 .NET Framework 4.7.2/4.8 或者 .NET Core 3.1 / .NET 5/6。听起来选择很多对吧但坑就在这里。我踩过的坑一开始我图新直接装了最新的 .NET 8 SDK。创建项目后编译一切正常但在编辑器里运行游戏时时不时会出现诡异的“脚本编译成功但节点属性不更新”或者“热重载失效”的情况。调试信息极其模糊只提示“模块加载错误”。解决方案与原理经过排查问题出在 Godot 编辑器自带的 Mono 运行时用于执行 C# 脚本与系统安装的 SDK 版本不匹配上。Godot 3.5.3 的 Mono 版本相对较旧对最新版 .NET 的某些特性或程序集加载逻辑支持可能不完善。正确的姿势统一版本最稳妥的方案是使用与 Godot 官方构建版本匹配的 .NET SDK。对于 Godot 3.5.3我强烈推荐安装.NET 6.0 SDK。这是经过广泛测试的版本兼容性最好。你可以在微软官网或使用 Visual Studio Installer 安装。检查环境变量安装后确保在命令行输入dotnet --info能正确显示 .NET 6 的运行时信息。Godot 会优先使用系统环境变量中找到的 SDK。项目配置在 Godot 编辑器中进入项目 - 项目设置 - 常规 - Mono确保“构建配置”设置为Debug开发时或Release并且“目标框架”明确选择为net6.0。不要依赖“自动检测”。实操步骤卸载其他可能冲突的 .NET SDK 版本特别是预览版。安装 .NET 6.0 SDK。在 Godot 中新建项目时直接选择.NET作为脚本语言模板。打开项目设置手动将目标框架锁定为net6.0。2.2 IDE 集成Visual Studio Code 还是 Visual StudioGodot 官方对 Visual Studio Code 和 Visual Studio 2019/2022 都有不错的支持。但两者体验差异很大。我踩过的坑最初我选择了 VS Code因为轻量。Godot 官方提供了godot-csharp-vscode插件用于生成.csproj文件和提供智能感知。然而在实际使用中我发现 VS Code 的 C# 插件OmniSharp对 Godot API 的补全经常抽风尤其是对于像GetNodeT()这种泛型方法提示时有时无。而且项目文件 (csproj) 一旦由 Godot 自动更新比如你重命名了脚本文件VS Code 需要手动重启 OmniSharp 服务器才能重新加载引用非常打断思路。解决方案与高效技巧对于 Windows 用户我最终转向了 Visual Studio 2022 Community Edition免费体验提升巨大。为什么选 VS项目管理更稳定Visual Studio 直接打开.sln解决方案文件对.csproj的变更感知更及时、准确。调试体验无缝在 VS 中可以直接附加到 Godot 编辑器进程进行调试断点、变量监视、调用栈一应俱全和调试普通 .NET 应用无异。Godot 插件安装名为Godot Tools for Visual Studio的扩展在 VS 的扩展管理中搜索。这个插件由 Godot 社区维护提供了创建 Godot C# 脚本模板、一键启动调试等功能集成度非常高。VS Code 用户的优化方案如果你坚持使用 VS Code确保做到以下几点安装godot-csharp-vscode插件和ms-dotnettools.csharp插件。在 VS Code 设置中为 Godot 项目文件夹单独配置 OmniSharp 路径或者使用.omnisharp.json文件来指定使用net6.0的 MSBuild。最重要的一步在 Godot 编辑器的编辑器设置 - 文本编辑器 - 外部编辑器中配置 VS Code 为外部脚本编辑器。这样在 Godot 中双击 C# 脚本就会在 VS Code 中打开并且 Godot 会自动生成正确的项目文件。个人心得对于中型及以上规模的 C# 项目Visual Studio 2022 带来的开发效率增益远超过其启动速度和内存占用带来的微小成本。它的调试器是真正的“生产力神器”。3. C# 脚本编写中的核心差异与高效模式从 GDScript 切换到 C#不仅仅是语法变了整个编程思维和与引擎交互的方式都需要调整。3.1 节点引用获取GetNodeT()与[Export]属性在 GDScript 里你可能会用onready var sprite $Sprite2D。在 C# 里有更类型安全的方式。常见坑点在_Ready()方法里直接使用GetNode(“NodePath”)如果路径写错或者节点尚未就绪会返回null导致后续的代码抛出NullReferenceException。而且这种字符串路径硬编码的方式难以重构和维护。高效技巧使用[Export]属性结合编辑器赋值或者使用GetNodeT()泛型方法。// 方法一使用 [Export] 属性在编辑器中拖拽赋值最推荐 [Export] private Sprite2D _playerSprite; // 直接在编辑器 Inspector 面板拖入节点 // 方法二在 _Ready 中使用 GetNodeT类型安全且可读性好 private Sprite2D _playerSprite; public override void _Ready() { // 使用相对路径基于当前脚本所在节点 _playerSprite GetNodeSprite2D(Sprite2D); // 或者使用绝对路径不推荐耦合度高 // _playerSprite GetNodeSprite2D(/root/Main/Player/Sprite2D); } // 方法三使用 Unique Name场景唯一节点 // 先在编辑器中给节点设置“唯一名称”然后通过 % 前缀获取 private Sprite2D _playerSprite; public override void _Ready() { _playerSprite GetNodeSprite2D(%UniqueSpriteName); }为什么推荐[Export]解耦脚本不关心节点在场景树中的具体路径只声明需要一个Sprite2D类型的引用。路径绑定工作交给编辑器和场景设计者。安全如果编辑器里忘记赋值Godot 会在运行前给出明确的警告一个黄色的三角感叹号而不是在运行时崩溃。灵活可以轻松地在不同场景或预制件PackedScene中复用同一个脚本而无需修改代码中的路径字符串。3.2 信号Signals连接从 GDScript 的connect到 C# 的事件Godot 的信号系统是其核心优势之一。C# 下的信号连接语法更接近 .NET 的事件但有些细节需要注意。我踩过的坑在 C# 中连接信号后如果包含目标方法的节点被释放如 queue_free()而信号发射者还在再次发射信号会导致引擎尝试调用一个已释放对象的方法从而引发错误。在 GDScript 中引擎有时会自动处理这种断开连接但在 C# 中需要更手动。高效且安全的信号连接模式public class Player : Area2D { [Signal] public delegate void HealthDepletedEventHandler(); // 1. 声明信号 private Timer _hurtTimer; public override void _Ready() { _hurtTimer GetNodeTimer(HurtTimer); // 2. 连接信号使用 操作符方法名不需要引号 _hurtTimer.Timeout OnHurtTimerTimeout; // 连接到自身或其他节点的信号 this.HealthDepleted OnPlayerDied; // 连接到自己的信号 } private void OnHurtTimerTimeout() { // 处理计时器到期的逻辑 TakeDamage(1); } private void OnPlayerDied() { // 处理玩家死亡的逻辑 QueueFree(); } // 3. 重要在节点退出树时断开连接 public override void _ExitTree() { // 断开所有连接避免悬空引用 _hurtTimer.Timeout - OnHurtTimerTimeout; this.HealthDepleted - OnPlayerDied; base._ExitTree(); } public void TakeDamage(int amount) { // ... 扣血逻辑 if (currentHealth 0) { EmitSignal(nameof(HealthDepleted)); // 4. 发射信号 } } }关键点解析和-这是 C# 的标准事件订阅/取消订阅语法比 GDScript 的connect和disconnect更符合 .NET 开发者的习惯。_ExitTree中断开连接这是防止内存泄漏和运行时错误的关键。当节点被移除出场景树时_ExitTree会被调用这是断开所有外部信号连接的理想位置。使用nameof操作符在EmitSignal时使用nameof(HealthDepleted)而不是字符串HealthDepleted。这样可以在重命名信号时由编译器帮你检查避免运行时因字符串拼写错误导致的信号发射失败。3.3 处理物理与输入_Processvs_PhysicsProcess在 2D 游戏中处理玩家输入和物理运动是核心。Godot 提供了两个主要循环_Process(float delta)和_PhysicsProcess(float delta)。核心区别_Process:每帧调用一次调用频率取决于显示器的刷新率如 60Hz 就是每秒60次。delta是上一帧到这一帧的实际时间间隔。适用于与画面渲染紧密相关、但对物理模拟精度要求不高的逻辑比如 UI 动画、粒子效果、非物理驱动的角色状态切换。_PhysicsProcess:以固定的时间步长调用默认为每秒60次可在项目设置中调整。delta通常是固定的如 1/60 秒。所有与物理引擎相关的操作如移动CharacterBody2D、检测碰撞、应用力等都必须放在这里。这样才能保证物理模拟的稳定性和可重复性避免因帧率波动导致物体“穿墙”或抖动。我踩过的坑早期我把所有的移动逻辑都写在_Process里使用delta乘以速度来位移。在大多数电脑上运行正常但在一些性能较差的设备上帧率下降时角色移动会变慢更严重的是由于物理检测 (move_and_slide) 的调用频率不稳定角色有时会卡进墙里。高效的正确做法public class Player : CharacterBody2D { [Export] public float Speed 300.0f; [Export] public float JumpVelocity -400.0f; // 获取重力值这样修改项目物理设置时无需改代码 public float gravity ProjectSettings.GetSetting(physics/2d/default_gravity).AsSingle(); public override void _PhysicsProcess(double delta) { Vector2 velocity Velocity; // 1. 应用重力物理相关 if (!IsOnFloor()) velocity.Y gravity * (float)delta; // 2. 处理输入输入检测通常也放在这里以确保响应及时 Vector2 direction Input.GetVector(ui_left, ui_right, ui_up, ui_down); if (direction ! Vector2.Zero) { velocity.X direction.X * Speed; } else { velocity.X Mathf.MoveToward(Velocity.X, 0, Speed); // 平滑停止 } // 3. 处理跳跃输入检测 if (Input.IsActionJustPressed(ui_accept) IsOnFloor()) velocity.Y JumpVelocity; // 4. 执行物理移动和碰撞检测 Velocity velocity; MoveAndSlide(); // 这是关键必须在 _PhysicsProcess 中调用 } // _Process 可以用来处理与物理无关的视觉反馈 public override void _Process(double delta) { // 例如根据速度播放不同的跑步动画混合 // 或者更新血条UI的位置跟随角色 // 这里的逻辑即使帧率波动也只是视觉上不流畅不会影响游戏逻辑 } }经验之谈一个简单的判断原则只要代码里调用了MoveAndSlide(),MoveAndCollide(), 或者直接修改了RigidBody2D的LinearVelocity这段代码就必须放在_PhysicsProcess中。输入检测虽然可以放在_Process但为了确保按键响应能及时作用于同一物理帧的计算通常也一并放在_PhysicsProcess里。4. 性能优化与内存管理实战Godot 的 C# 脚本运行在 Mono/.NET 环境下虽然性能不错但不当的使用仍会导致卡顿和内存泄漏尤其是在移动平台或低配设备上。4.1 避免每帧new对象对象池与缓存在_Process或_PhysicsProcess中频繁创建新的对象如Vector2,Array,Dictionary会迅速增加垃圾回收GC的压力导致间歇性卡顿。我踩过的坑在子弹发射逻辑中每发射一颗子弹就new Bullet()并AddChild()。当敌人众多、弹幕密集时游戏会出现明显的周期性卡顿Profiler 显示 GC 活动频繁。高效技巧使用对象池Object Pooling。// 一个简单的子弹对象池示例 public class BulletPool { private PackedScene _bulletScene; private QueueBullet _availableBullets new QueueBullet(); public void Initialize(PackedScene bulletScene, int prewarmCount, Node parentNode) { _bulletScene bulletScene; for (int i 0; i prewarmCount; i) { Bullet bullet _bulletScene.InstantiateBullet(); parentNode.AddChild(bullet); bullet.Visible false; bullet.SetProcess(false); // 禁用处理节省CPU bullet.SetPhysicsProcess(false); _availableBullets.Enqueue(bullet); } } public Bullet GetBullet(Vector2 position, Vector2 direction) { Bullet bullet; if (_availableBullets.Count 0) { bullet _availableBullets.Dequeue(); } else { // 池子空了动态创建一个应尽量避免走到这里 bullet _bulletScene.InstantiateBullet(); GetParent().AddChild(bullet); } bullet.GlobalPosition position; bullet.Direction direction; bullet.Visible true; bullet.SetProcess(true); bullet.SetPhysicsProcess(true); bullet.OnFired(); // 重置子弹状态 return bullet; } public void ReturnBullet(Bullet bullet) { bullet.Visible false; bullet.SetProcess(false); bullet.SetPhysicsProcess(false); _availableBullets.Enqueue(bullet); } } // 在 Bullet 脚本中 public partial class Bullet : Area2D { [Export] public float Speed 500f; public Vector2 Direction { get; set; } Vector2.Right; public override void _PhysicsProcess(double delta) { Position Direction * Speed * (float)delta; if (Position.X 1000) // 飞出屏幕 { // 通知对象池回收自己而不是 QueueFree() GetNodeBulletPool(/root/BulletPool).ReturnBullet(this); } } public void OnFired() { // 重置子弹的碰撞检测等状态 Monitoring true; Monitorable true; } }原理对象池在游戏初始化时预先创建一定数量的对象并禁用。需要时从池中取出并激活用完后不销毁而是放回池中并禁用。这完全避免了运行时动态内存分配和垃圾回收对于子弹、敌人、特效等需要频繁创建销毁的对象性能提升是立竿见影的。4.2 谨慎使用 LINQ 和 Lambda 表达式LINQ 和 Lambda 是 C# 的语法糖能让代码更简洁。但在 Godot 的每帧更新循环中使用它们可能会产生大量的临时迭代器对象和闭包加重 GC 负担。对比示例// 不推荐在 _Process 中频繁使用 LINQ public override void _Process(double delta) { // 假设 enemies 是一个 ListEnemy var aliveEnemies enemies.Where(e e.IsAlive).ToList(); // 每次调用都生成新列表和迭代器 // ... 使用 aliveEnemies } // 推荐手动循环复用集合 private ListEnemy _aliveEnemiesCache new ListEnemy(); // 缓存列表 public override void _Process(double delta) { _aliveEnemiesCache.Clear(); foreach (var enemy in enemies) { if (enemy.IsAlive) { _aliveEnemiesCache.Add(enemy); } } // ... 使用 _aliveEnemiesCache }建议在性能关键的循环如_Process,_PhysicsProcess或每帧执行的大规模 AI 计算中避免使用 LINQ。在加载时、初始化时或触发频率很低的事件中可以放心使用 LINQ 来保持代码清晰。4.3 理解 Godot 与 .NET 的垃圾回收协作Godot 节点有自己基于引用计数的内存管理继承自GodotObject。C# 的Node子类同时受 Godot 和 .NET CLR 管理。这可能导致一种复杂情况一个节点在 Godot 场景树中被移除了QueueFree()但 C# 代码中仍持有对它的强引用导致它无法被 .NET GC 回收。最佳实践及时置空引用在_ExitTree()或OnDestroy回调中不仅断开信号还要将持有的其他节点引用设为null。private Sprite2D _cachedSprite; public override void _ExitTree() { _cachedSprite null; // 帮助 GC base._ExitTree(); }使用WeakReference对于一些非核心的、可能被销毁的节点引用可以考虑使用WeakReference这样即使对方被释放也不会阻止 GC。private WeakReferenceEnemy _targetEnemyRef; public void SetTarget(Enemy enemy) { _targetEnemyRef new WeakReferenceEnemy(enemy); } public void TryAttack() { if (_targetEnemyRef?.TryGetTarget(out var enemy) true enemy.IsAlive) { // 攻击目标 } else { // 目标已失效寻找新目标 } }善用 Godot 的GodotObject.IsInstanceValid()方法在访问一个可能已被释放的 Godot 对象前用此方法检查。if (GodotObject.IsInstanceValid(_someNode)) { _someNode.Call(some_method); }5. 调试与问题排查的独家工具箱开发过程中BUG 如影随形。掌握高效的调试技巧能极大缩短“找虫”时间。5.1 利用 Visual Studio 的混合调试这是使用 C# 开发 Godot 游戏的最大优势之一。你可以在 Visual Studio 中设置断点、单步执行、查看调用堆栈、监视变量和表达式。设置步骤在 Visual Studio 中打开你的 Godot C# 项目解决方案 (.sln)。确保编译配置为Debug。在 VS 菜单栏选择调试 - 附加到进程。在进程列表中找到并选择正在运行的Godot_v3.5.3-stable_mono.exe或你的 Godot 编辑器名称。点击“附加”。现在你在 C# 脚本中设置的断点就会被命中。技巧你可以在 Godot 编辑器中运行游戏然后在 VS 中附加。也可以配置 VS 的启动项让它自动启动 Godot 并打开你的项目。在Godot Tools for Visual Studio插件中通常有“启动调试”的按钮一键完成。5.2 Godot 内置的调试工具即使使用 C#Godot 编辑器自带的调试工具依然不可或缺。“远程”场景树在游戏运行时切换到“场景”停靠栏顶部下拉菜单选择“远程”。这里可以看到当前运行中游戏的场景树实时状态检查节点的属性、是否被正确添加/移除。这对于调试动态生成的节点如对象池产生的子弹特别有用。调试器面板“调试器”面板可以查看输出日志、错误和警告。C# 的GD.Print()、GD.PrintErr()等信息都会输出在这里。你还可以在这里查看性能分析器Profiler。性能分析器Profiler在“调试器”面板切换到“分析器”标签页。这里可以监控帧时间、物理步骤时间、脚本函数调用时间等。如果你发现游戏卡顿首先应该来这里看看是哪个环节耗时最多。特别注意_Process和_PhysicsProcess中你自己脚本函数的耗时。5.3 常见 C# 特有错误与排查“Missing [Export] or [Signal] attribute” 编译错误问题你声明了一个公共字段或事件希望它在编辑器中可见或作为信号但 Godot 的 C# 生成器没有识别。解决确保类继承自GodotObject如Node并且字段/事件声明为public。对于信号必须使用[Signal] public delegate ...格式。然后在 Godot 编辑器中点击“构建项目”Build Project按钮。C# 项目需要显式构建Godot 才会生成对应的 metadata使[Export]和[Signal]生效。仅仅保存脚本文件是不够的。“The method ‘XXX’ is not declared in type ‘YYY’” 或智能感知丢失问题VS Code 或 VS 的智能感知找不到 Godot 的 API比如GetNodeT()提示错误。解决首先在 Godot 编辑器中执行一次完整的构建项目 - 工具 - 构建。在 VS Code 中尝试重启 OmniSharp 服务器命令面板OmniSharp: Restart OmniSharp。在 Visual Studio 中尝试清理并重新构建解决方案。检查项目文件.csproj确保它正确引用了GodotSharp和GodotSharpEditor等程序集。这些引用通常由 Godot 自动管理但有时会损坏。可以尝试关闭 Godot 和 IDE删除项目根目录下的.mono/文件夹和obj/、bin/文件夹然后重新用 Godot 打开项目并构建。运行时出现NullReferenceException但编辑器里引用明明赋值了问题最常见的原因是脚本执行顺序问题。_Ready()中通过GetNode获取的引用可能在依赖的节点尚未完成_Ready()时就被访问了。排查使用GD.Print在_Ready中输出引用的值看是否为null。确保节点路径正确并且目标节点在场景树中确实存在检查大小写和路径符号。更稳健的做法将初始化逻辑分散。在_Ready中只获取必要的引用。将依赖于其他节点完全初始化的逻辑放在一个自定义方法中并通过信号或在下一次_Process中延迟调用。private bool _isInitialized false; private Sprite2D _sprite; public override void _Ready() { _sprite GetNodeSprite2D(Sprite2D); // 假设_sprite需要加载一个纹理这可能在它自己的_Ready中完成 // 我们无法保证此时纹理已加载好 CallDeferred(nameof(FinishInitialization)); // 延迟到下一帧执行 } private void FinishInitialization() { if (_sprite.Texture null) { GD.PrintErr(Sprite texture is not loaded yet!); // 可以在这里设置一个默认纹理或者等待一个加载完成的信号 return; } _isInitialized true; // 开始你的游戏逻辑 }6. 构建与部署最后的临门一脚游戏做完了打包发布又是另一个故事。Godot C# 的导出过程比纯 GDScript 项目多一些步骤。6.1 导出模板的准备Godot 的 C# 项目需要特定的“导出模板”才能构建出可执行文件。这些模板是包含 Mono 运行时的 Godot 引擎副本。操作步骤从 Godot 官网下载与你编辑器版本完全一致的Mono 版本导出模板例如Godot_v3.5.3-stable_mono_export_templates.tpz。在 Godot 编辑器中进入编辑器 - 编辑器设置 - 导出模板。点击“从文件安装”选择你下载的.tpz文件。安装成功后在项目 - 导出中你才能看到支持 .NET 的导出平台选项如 “Windows Desktop (.NET)”。6.2 导出配置与文件组织在“导出”对话框中你需要为每个目标平台Windows, Linux, macOS 等创建并配置一个“预设”。关键配置项“架构”根据目标系统选择 x86_64 (64位) 或 x86 (32位)。现在主流是 64位。“嵌入 .NET 运行时”强烈建议勾选。这会将 .NET 运行时打包进你的游戏可执行文件中。这样用户无需单独安装 .NET游戏可以开箱即用。代价是最终的游戏包体积会增大大约增加 30-60 MB。“导出模式”开发时选择Debug最终发布时选择Release。Release模式会进行代码优化体积更小运行更快。“包含的 .NET 程序集”这里会列出你项目引用的所有 .NET DLL。通常保持默认即可。如果你使用了第三方 NuGet 包需要确保它们也被包含进来。文件组织陷阱Godot 的 C# 项目编译后会在项目根目录/bin/(Debug|Release)/下生成.dll文件。当你导出项目时Godot 会将这些 DLL 和资源文件一起打包。我踩过的坑手动复制bin/下的 DLL 到项目根目录或者修改了 DLL 的生成路径导致导出时 Godot 找不到正确的程序集游戏启动崩溃。正确做法不要手动移动或修改bin/和obj/目录下的任何文件。让 Godot 的构建和导出系统全权管理。如果你需要清理在 Godot 编辑器中使用项目 - 工具 - 清理解决方案。6.3 针对目标平台的特别处理Windows相对简单。导出后你会得到一个.exe文件和一个{项目名}_Data文件夹或.pck文件。确保将它们放在一起分发。macOS导出的.app是一个包。你需要确保其内部结构正确。有时需要为.app签名和公证才能在较新版本的 macOS 上运行。Linux导出一个可执行文件。可能需要赋予执行权限 (chmod x)。同样如果嵌入了 .NET 运行时用户无需安装 Mono。Android/iOS移动平台的 C# 支持在 Godot 3.5 中相对成熟但配置更复杂。你需要安装对应的 SDK 和构建工具并在导出预设中正确配置包名、权限等。特别注意移动设备上性能要求更苛刻前面提到的对象池、避免每帧 GC 等优化措施尤为重要。最后的检查清单在导出前用Release配置在 Godot 编辑器中完整测试一遍游戏。导出后在没有安装 Godot 编辑器和**.NET SDK** 的干净环境中测试游戏。检查游戏启动速度、运行时内存占用以及是否存在内存泄漏可以长时间运行看内存是否持续增长。如果游戏崩溃查看 Godot 生成的错误日志通常在可执行文件同目录或用户目录下。对于 C# 错误日志中会包含 .NET 的堆栈跟踪信息这是定位问题的关键。