Unity 游戏开发中的防御性编程与空值处理实践

在 Unity 游戏开发中，我们经常需要从服务器获取玩家的详细信息。在这过程中，如果没有做好防御性编程，就可能会遇到因为数据缺失或格式问题导致的 UI 异常。本文将分享一个实际案例，解释如何通过空值处理和防御性编程避免这些问题。

问题描述

背景

在开发中，我们经常需要处理服务器返回的各种数据。

服务器返回的数据格式通常是预先定义好的，比如服务器返回的 PlayerContribution 消息结构：

protobuf 复制代码

message PlayerContribution {
  string OpenId       = 1; // 玩家OpenId
  string Nickname     = 2; // 玩家昵称
  string Avatar       = 3; // 玩家头像
  ......
}

问题是------服务器并不总是靠谱.

有时候，服务器返回的昵称（Nickname）或头像（Avatar）可能是空的。如果我们没有做空值判断，程序就会抛出异常，导致 UI 显示出错。

另一个例子:

有一次我在调试玩家详情页，调用 AllPlayerInfoItem.SetWing、SetFashion、SetAttr 等方法时，某些字段（像 info 或它的子字段）是 null。结果没有判空，代码中断了，UI 没更新，也没有红色错误日志，看起来就像"程序突然不工作了"。

这其实就是典型的服务端缺数据 + 客户端没防御导致的问题。

虽然"空是服务器的锅" (朋友说的,但是我觉得两方都应当做防御)，但不做防御，崩的是客户端。

没有明显的错误日志，可能的原因有几个：

异常被捕获并吞掉 ：可能代码中有 try-catch 语句捕获了异常，但没有进行适当的日志记录。这样，异常不会显现为红色错误，可能只是默默地被处理了。

异步回调或事件链 ：如果是异步操作（如 Unity 的 Coroutine 或其他事件回调机制），异常可能会在某个异步操作中抛出，而这个操作的异常没有直接反映到主线程的控制台中，导致没有看到明显的日志。

日志级别设置：Unity 的日志系统允许设置不同的日志级别。如果日志级别设置不当，某些错误可能不会被输出，尤其是在开发环境中设置了过滤日志输出的情况下。

问题现象

没有明显的崩溃日志，UI 却不再刷新。
某些模型或文本数据没显示，看起来"卡死"或"卡界面"。
异常可能被吞掉或延迟处理，难以快速定位问题。

根因分析

在 UI 数据填充时（如 AllPlayerInfoItem.SetWing、SetAttr 方法），没有做足够的空值判断。
异步回调中抛出的异常没有被捕获，导致方法执行中断。
异常抛出后，后续的逻辑未能执行，造成了 UI 数据缺失 和 角色模型不显示 的问题。

问题解决

修复方案

捕获异常，确保逻辑不被中断在执行 SetData 或创建玩家模型时，使用 try-catch
语句，确保即使出现错误，后续的逻辑还能继续执行。
空值判断与异常捕获在处理数据时，对可能为 null 的字段进行空值判断，避免抛出异常。同时，在回调函数中捕获异常，防止单个错误影响整个流程。

csharp 复制代码

// 代码简化版
try
{
    if (info?.WingInfo == null) return;
    // 其他逻辑...
}
catch (Exception e)
{
    Tools.Log($"SetWing 异常：{e.Message}", GlobalEnum.DebugColor.Red);
}

使用安全访问符处理数据对可能为 null 的数据使用 ?. 和 ?? 来进行安全访问和空值处理，确保程序不会因为缺少数据而崩溃。

csharp 复制代码

var skinName = info?.SkinInfo?.Name ?? "暂无时装";

这样即使 info 为空，也不会报错，还能显示默认值。

最佳实践

参数校验：入口方法先判空，防止上游数据异常直接炸。
异步回调捕获 ：在异步回调内，使用 try-catch 保护，防止异常中断整个链路。
闭包保护 ：回调中使用循环索引时，记得通过局部副本保护闭包问题（int idx = i;）。
安全访问符 ：对服务器数据使用 ?. 和 ?? 处理缺省值，避免空引用。
顶层保护 ：在关键流程（如模型创建、数据填充）外围加一层 try-catch，确保错误不会导致逻辑中断。
单元测试：添加单元/集成测试，覆盖常见的空值场景，避免上线后问题频发。

总结

这次的小插曲让我们意识到：
防御性编程不是多余的谨慎，而是必要的保险。

即使服务器"理论上"会返回完整数据，现实往往没那么理想。只要客户端多判一次空、多加一个默认值，就能让程序更稳定，也能避免"游戏突然卡死"这种让人一头雾水的问题。

毕竟

"空是服务器的问题，但崩的是客户端。"

------ 所以我们要做的，就是让客户端永远不被它拖下水。