Unity正式包防调试代码混入：条件编译与日志治理实战

先问一个很现实的问题：你上一次在 Unity 的正式包里发现 Debug.Log 刷屏、调试图标乱入、甚至按住屏幕某个角落就能呼出作弊菜单，是什么时候？

如果你心想"啊，还好没人发现"，那这篇就是给你写的。

调试代码混进正式包这事儿，说实话，几乎是每个 Unity 开发团队都会经历一遍的"成长痛"。它不一定是能力问题，更多是流程问题。因为 Unity 编辑器环境和最终构建出来的玩家版本，本质上就是两个世界。编辑器里有 Console 窗口、有 Gizmos、有各种 Inspector 上天入地的调试按钮，这些东西在编辑器里是生产力，但原封不动跟着 Player 构建出去，轻则被玩家截图嘲讽，重则被竞品直接逆向抄走逻辑，还不小心把自己的内部接口全暴露了。

这篇文章我打算分几个部分讲，从最基础的预处理指令，到日志系统怎么设计，再到构建后的排查手段，全部基于我这几年在多个项目里踩过的坑。不怕基础，只讲能落地的做法。

1. 调试代码为什么会混进正式包

1.1 这不是懒，是机制上的天然漏洞

很多人觉得调试代码漏进正式包是程序员偷懒，我不完全同意。Unity 编辑器给人的工作流暗示太强了：你在脚本里写一句 Debug.Log，编辑器 Console 立刻就有输出；你挂一个调试组件，Scene 视图里立刻就能看到效果。这个过程非常丝滑，丝滑到你根本意识不到"这段代码在打包时会一起编译进去"。

Unity 默认的编译方式是"把所有 C# 脚本全量编译，然后打进程序集"。你在任意脚本里写的任何一行代码，只要没被预处理指令包起来，哪怕它只在一个编辑器菜单里被调用，它都会进入最终的游戏程序集。这就是问题根源：编辑器环境下的"可见性"和"运行时机"，掩盖了代码"是否会被打包"这个问题。

另一个客观原因是，国内团队普遍迭代节奏快——版本排期压得紧，上午改完 bug 没来得及验证、下午就要出包，调试开关来不及关，或者压根就没设计开关。等到包发出去，才发现某个调试快捷键还能用。

1.2 如果这些代码真的发布出去了，会发生什么

我说几个真实案例，都是我自己或同行身上发生过的：

• 某个手游项目的正式包，玩家在设置界面连点版本号十次，弹出了完整的 Debug Console，能看到所有玩家本地的报错堆栈。这还不算最糟的，最糟的是 Console 里把服务端接口地址、参数格式全打出来了。
• 某个单机项目上线后，玩家反馈游戏会卡顿，查了半天发现是一个 Debug 更新器每帧在 Update 里打印一条冗长的 Profiler 数据到文件。
• 另一个团队把作弊热键留在了正式包里，输入特定组合键可以直接调用内部测试指令，跳过战斗、直接发奖。

这些问题的共同点：都不是"技术上做不到移除"，而是"根本没想过要主动移除"。防范的思路不能停留在"记得删"，而是要利用 Unity 的编译机制，让调试代码在正式包里"根本不存在"。

2. 条件编译：Unity 给我们的第一道闸门

2.1 认识预处理指令：从最简单的 #if 开始

条件编译是 C# 从语言层面提供的机制，Unity 的编译器原生支持。简单说，就是用预处理指令把某段代码框起来，让编译器在特定符号开启时才编译这段代码，否则整段代码直接当不存在处理。

最基本的写法：

#if UNITY_EDITOR // 只有编辑器环境才会编译这里 Debug.Log("我在编辑器里才会出现"); #endif

UNITY_EDITOR这个符号是 Unity 自动定义的，只在编辑器中生效。也就是说，这段代码在打包时不会被编译进程序集，连残留的字符串常量都不会有。这是最基础、也最不容易出错的一种方式。

但这里有一个细节很多人会忽略：UNITY_EDITOR代表的是"代码运行在 Unity 编辑器中"，它不代表"这是调试代码"。你在编辑器里写的很多逻辑，比如自定义 Inspector、编辑器扩展工具、Scene 视图渲染辅助，这些本来就该属于编辑器功能，用UNITY_EDITOR包没问题。但如果你有一份"只在开发期需要、但运行时逻辑也得能跑"的代码，仅仅用UNITY_EDITOR就不够了。

2.2 DEVELOPMENT_BUILD 和 UNITY_EDITOR 的实际区别

Unity 还提供了一个专门的符号：DEVELOPMENT_BUILD。它只在勾选了"Development Build"选项的打包中才会被定义。看名字也能猜出来，它专门为"带有开发性质的构建版本"服务。

两者的区别用一张表来看最直观：

实际项目里的正确做法是配合使用：

#if UNITY_EDITOR // 纯编辑器功能：自定义 Inspector、编辑器菜单 [MenuItem("Tools/打开调试面板")] static void OpenDebugPanel() { // ... } #endif #if UNITY_EDITOR || DEVELOPMENT_BUILD // 既能编辑器调试，也能在开发构建包上使用的运行时调试逻辑 void UpdateDebugInfo() { // ... } #endif

把"编辑器专用"和"开发期运行时代码"分开控制，比一杆子全用UNITY_EDITOR灵活得多。

2.3 自定义编译符号：多环境、多渠道的精细控制

Unity 支持你在 Player Settings 里自定义编译符号（Scripting Define Symbols），多个符号用分号隔开。

我一般建议在工程项目里设计一套自己的宏体系，类似下面这种：

// 自定义符号命名规则（供参考） // MYGAME_DEBUG : 项目自定义的调试总开关 // MYGAME_DEBUG_MENU : 调试菜单 // MYGAME_DEBUG_LOG : 详细日志输出 // MYGAME_DEBUG_CHEAT : 作弊指令（测试用）

然后在代码里：

#if MYGAME_DEBUG_CHEAT if (Input.GetKeyDown(KeyCode.F1)) { player.AddGold(999999); } #endif

自定义符号的核心价值在于：你不需要每一次打包前手动去删代码，只需要通过不同的构建配置（Build Profile）来控制哪些宏开、哪些宏关。比如持续集成（CI/本地自动化构建）时，每次提交代码后自动打包测试包，就把MYGAME_DEBUG之类的宏带上；打包正式包时，不定义任何自定义调试宏即可。

3. Debug.Log 和日志的全面处理

3.1 Debug.Log 在正式包里的行为，你真的清楚吗

Debug.Log 这个问题，表面看是"忘删了"，实际上有一个被很多人低估的性能坑。

Debug.Log 有三个层面的影响：

1. 调用本身有 CPU 开销。字符串拼接（尤其涉及堆分配）是开销大头。
2. 日志会写入设备的控制台缓冲区，尤其移动端，长时间大量输出会占用内存，并拖慢 GC。
3. 日志会通过 profiler 导出、DevConsole 等机制额外消耗 IO 资源。

你可能会说，App 发布后再也没有 Console 窗口了，日志去哪了？在移动平台上，Debug.Log 的默认行为会把日志输出到系统的日志流（Logcat / Console.app），长此以往，这个 IO 写入消耗在低端机上会肉眼可见地影响帧率。

说实话，Debug.Log 卸载不干净，还有一层隐藏风险：日志内容本身就是信息泄露。如果日志里打印了请求地址、业务字段、甚至玩家 ID，等于是把接口结构免费送给了逆向的人。

3.2 从源头做日志系统，而不是事后禁止 Debug.Log

正确思路不是"发布前全局搜索删 Debug.Log"，而是从项目开始就设计一个日志门面类。我用一个非常实际的例子说明：

public static class DebugEx { public enum LogLevel { Verbose = 0, Info = 1, Warning = 2, Error = 3 } public static bool enableVerbose = false; public static bool enableInfo = true; public static bool enableWarning = true; public static bool enableError = true; [System.Diagnostics.Conditional("ENABLE_VERBOSE_LOG")] public static void LogVerbose(string message) { if (!enableVerbose) return; Debug.Log("[Verbose] " + message); } public static void LogInfo(string message) { if (!enableInfo) return; Debug.Log("[Info] " + message); } public static void LogWarning(string message) { if (!enableWarning) return; Debug.LogWarning("[Warning] " + message); } public static void LogError(string message) { if (!enableError) return; Debug.LogError("[Error] " + message); } }

代码里所有地方都走 DebugEx，业务代码中禁止直接用 Debug.Log。

这里最巧妙的是[Conditional]特性。它解决的是一个关键痛点：大部分日志方法都有参数计算的开销，即使方法内部不打印，参数的字符串拼接也已经发生了。而[Conditional]配合编译符号，可以让调用点本身在编译器层面消失，连参数计算都不执行。

[System.Diagnostics.Conditional("MYGAME_VERBOSE_LOG")] public static void LogVerbose(string message) { // ... }

LogVerbose这个方法在编译时，如果MYGAME_VERBOSE_LOG没有被定义，那么所有调用这个方法的调用点都会被"抹掉"。参数自然不会被计算。这是性能上的关键优化。

注意：[Conditional]只能修饰返回 void 的方法，且不能用于泛型方法。这是限制，也是设计。Debug 类本身就完美符合这个约束。

3.3 运行时日志输出的兜底方案

有人会问：如果某个第三方插件内部直接用 Debug.Log 刷屏怎么办？

常见插件（比如某些 SDK）内部大量使用 Debug.Log，你是没法用预处理指令帮它去掉的。这时候我一般提供三个方案，按推荐程度排序：

1. 如果插件源码可用，直接改造成上面的日志门面模式，或者用条件编译包一圈。这是最干净的方案。
2. 如果插件是 DLL 形式、无法改源码，就在 Player Settings 的 Scripting Define Symbols 中自定义一个全局开关，比如SUPPRESS_PLUGIN_LOGS。然后在启动代码里通过反射或Application.logMessageReceived事件把日志拦截掉。
3. 如果只是想压降 IO，也可以用一个专门的日志重定向脚本，在正式包中把Debug.logger.logEnabled设置成 false，让所有日志静默。

但方案 3 有个副作用：logEnabled = false会同时吞掉 Error 和异常日志。对线上问题追踪很不友好。我的建议是，正式包里保留 Error 级别的原始日志，只关闭 Info 和 Warning 级别。

void ConfigureLogger() { #if !UNITY_EDITOR && !DEVELOPMENT_BUILD var debugSettings = Debug.unityLogger.filterLogType; // 正式包里只保留 Error 和 Assert，屏蔽 Info/Warning 的刷屏输出 Debug.unityLogger.filterLogType = LogType.Error | LogType.Assert; #endif }

这个做法不会彻底移除日志代码，但至少能保住系统稳定性和 IO。

4. 调试对象、调试组件和编辑器工具的处理

4.1 挂在场景里的调试组件，比代码更难清

代码可以用条件编译控制，最难搞的是那些"躺在场景里"的调试对象。比如你为了方便测试，在场景里挂了一个 DebugHUD 组件，它上面有几十个公参引用。打包的时候，如果这个组件没有被显式隐藏或移除，它就会被序列化到场景里、直接进入正式包。

我见过最典型的翻车现场：场景里放了一个"某 SDK 调试面板"，正式包发出去，玩家在特定条件下激活了它，瞬间看到了完整的设备信息、账号 token、服务端地址等敏感信息。

解决方案其实不难，但需要在组件挂载前就设计好。我推荐三种做法：

做法一：调试组件不放进正式场景

如果你只是临时想看一下数值，建一个专门的场景叫 DebugScene，在里面挂调试组件，开发和测试时就进这个场景。正式发布时，确保打包场景列表里只有正式场景，DebugScene 不在其中。

这个方案简单有效，但坑在于场景列表被人手动多勾一个，立刻前功尽弃。所以真正的大型项目通常不靠人肉保证，而是在构建脚本中加了自动校验（后面讲构建脚本的时候细说）。

做法二：运行时动态创建，而不是在编辑器中手动挂好

不要在编辑器中手动挂调试组件，而是让一个调试管理器在#if UNITY_EDITOR || DEVELOPMENT_BUILD的代码块中"按需动态创建"。这样组件实例只存在于运行时，不会因为场景序列化被带进正式包。

#if UNITY_EDITOR || DEVELOPMENT_BUILD [RuntimeInitializeOnLoadMethod(RuntimeInitializeLoadType.AfterSceneLoad)] static void CreateDebugHUD() { if (DebugConfig.EnableDebugHUD) { var go = new GameObject("DebugHUD"); go.AddComponent<DebugHUD>(); GameObject.DontDestroyOnLoad(go); } } #endif

做法三：用自定义字段 + Inspector 控制是否序列化

如果你不得不把调试组件挂在正式场景里（比如某些调试数据需要美术放到场景里），可以在序列化字段上做手脚。通过[SerializeField, HideInInspector]或自定义的ISerializationCallbackReceiver来控制正式包中的数据保留。

说实话，前两种已经能覆盖 95% 的需求。做法一适合临时调试，做法二适合常驻调试体系。真正到了正式包，任何一个调试对象都不应该被序列化进场景。

4.2 OnDrawGizmos 和 OnGUI 调试面板：编辑器工具别当运行时功能

有些团队会在 MonoBehaviour 里写 OnDrawGizmos，用来在 Scene 视图画辅助线。这种代码本身是无害的，因为在编辑器里面，Gizmos 渲染走的是 EditorApplication 的路径，打包后不会被触发。但是，如果你不小心把 OnGUI 当成调试输出工具，并且没加条件编译，那它就真的会出现在正式包里了。

OnGUI 是运行时事件，它每一帧都会被调用。你原本只是想在编辑器里看个按钮，用 OnGUI 画了几个测试按钮，忘了包条件编译，于是正式包里就有了几个隐形按钮——玩家虽然不知道按哪里，但代码里确实有。更严重的是 OnGUI 有自己的性能开销，它会触发 GUI 系统的重建。如果里面还画了大量控件，每帧都有几十上百次 GUI 调用，低端机直接掉帧。

正确做法：

• 编辑器场景的可视化辅助（Scene 辅助线、手柄标签）统一用OnDrawGizmos/OnDrawGizmosSelected，Unity 打包时会自动忽略，无需额外宏。
• 调试 HUD 的 UI，使用 uGUI 或者手动创建 Canvas 时，必须放在#if UNITY_EDITOR || DEVELOPMENT_BUILD保护之下。
• 如果在编辑器里需要一套"可操作的调试面板"，优先选择[CustomEditor]配合一个纯编辑器脚本实现，不要写进 MonoBehaviour 的运行时方法。

// 错误示范：OnGUI 不加宏保护 private void OnGUI() { if (GUILayout.Button("加 10000 金币")) { player.AddGold(10000); } } // 正确示范：OnGUI 只在编辑器或开发构建中编译 #if UNITY_EDITOR || DEVELOPMENT_BUILD private void OnGUI() { if (GUILayout.Button("加 10000 金币")) { player.AddGold(10000); } } #endif

虽然我平时更推荐用 uGUI 来做调试面板（可控性好、支持复杂数据查看），但如果你已经写习惯了 OnGUI，那至少保证它被宏包住，这一点没有商量余地。

4.3 那些躺在 Resources 或 StreamingAssets 里的调试资源

调试这回事，不仅代码，资源也一样会漏出去。比如你为了方便，把一份 JSON 配置放在 StreamingAssets 里，内容是服务器地址、热更开关、内测名单。打包时 StreamingAssets 是原样拷贝的，不做任何剔除。

这个问题我要单独拉出来说，因为很多人注意不到。代码层面的条件编译很显眼，但资源是静态文件，Unity 不会因为你加了编译宏就帮你过滤资源。而且，如果用了 Addressables 或 AssetBundle 构建，每个 Bundle 里可能混入了编辑器专用资源。

我的做法：

1. 调试配置全部放在 Assets 根目录的一个_DebugConfig文件夹里，文件名统一带_debug后缀。
2. 构建脚本里加一个检查项，遍历所有将被打包的资源路径，发现路径中包含_debug、debug、Test等关键词则直接报错。
3. 使用 Addressables 时，调试资源单独打一个 Group，并且不参与任何正式构建的 Bundle 构建。

原理很简单，把调试资源统一编排在一个固定的、可被程序化扫描的区域，然后用脚本保证"正式构建时这个区域整体被排除"。手动排查总有漏网之鱼，脚本扫描是最后的兜底。

5. 构建后的收尾与验证：不只是在编辑器里点个 Build

5.1 构建脚本中自动剔除调试内容

大型项目一般不会让人手动去 Player Settings 点构建了，都是走 CLI 或 Jenkins/GitHub Actions 之类的自动化流程。在构建脚本里做几件事可以大幅减少调试内容混入正式包的概率。

我推荐在构建前执行一个静态检查脚本，步骤大致如下：

1. 扫描所有将参与打包的场景，检查场景中是否存在标记了[DebugOnly]特性的组件（或挂在特定 Layer 上的调试对象），有则报错，并打印具体场景路径、组件路径，中断构建。
2. 扫描ProjectSettings中的 Scripting Define Symbols，确认正式包构建时不包含任何自定义调试宏。
3. 验证PlayerSettings.development为 false，关掉"Development Build"选项。
4. 检查Application.logMessageReceived注册的日志系统，在正式包里面确实切到了线上模式。

下面是一个很简化的伪代码思路，实际项目可在构建时集成。

using UnityEditor; using UnityEngine; using UnityEditor.Build; using UnityEditor.Build.Reporting; public class ReleaseBuildValidator : IPreprocessBuildWithReport { public int callbackOrder => 0; public void OnPreprocessBuild(BuildReport report) { if (report.summary.options.HasFlag(BuildOptions.Development)) { Debug.LogError("正式包不允许勾选 Development Build！"); throw new BuildFailedException("正式构建已拦截：Development Build 被勾选"); } // 自定义宏检查：正式包不允许出现 MYGAME_DEBUG var symbols = PlayerSettings.GetScriptingDefineSymbolsForGroup( BuildTargetGroup.Android); if (symbols.Contains("MYGAME_DEBUG")) { throw new BuildFailedException("正式构建包含调试宏，已拦截"); } // 场景对象检查逻辑略，可借助 EditorSceneManager 遍历每个场景的根节点 } }

这套校验的价值是：把"人肉记忆"变成了"机器强制"。只要构建链路上有这个校验器，任何人想偷懒打个"带调试信息的测试包当正式包"发出去，都会被直接拦截。

5.2 从最终包体里反向检查调试残留

构建完成后，还要主动检查打出来的包体。官方有提供工具吗？Unity 没有直接提供一个"一键列出所有调试字符串"的按钮，但我们可以自己写一个后处理检查。

常用的手段有几个：

检查 APK/AAB 中的字符串常量

对 Android 包，可以直接用apkanalyzer或解包后搜索字符串。重点搜这几类关键词：

• Debug.Log方法名（IL2CPP 编译后字符串常量通常在global-metadata.dat中）
• 项目特有的调试前缀，比如[Debug]、[Cheat]、[Test]等
• 服务器内网地址、测试环境域名（这个不要搜 Metaspace 的东西，直接搜libil2cpp.so中的字符串）

对 iOS 包，可以用strings命令搜Mach-O二进制里的字符串：

strings Payload/YourApp.app/YourApp | grep -i "debug\|test\|cheat"

注意：IL2CPP 编译后，不是所有 C# 字符串常量都能直接搜到，但绝大多数常量字符串都会以 UTF-8 或以 metadata 形式存在于二进制或global-metadata.dat文件中。这个方法不能保证 100% 搜索完整，但搜到任何异常都值得警惕。

检查场景序列化数据

把 AssetBundle 或场景资源反序列化后遍历，适合有条件做专项检查的团队。资金宽裕的团队通常会写一个 Editor 工具，把构建出来的 AssetBundle 加载到一个临时工程，遍历每个资源，检查是否包含调试信息。

5.3 配合代码剥离（Managed Stripping Level）

Unity 的 Managed Stripping Level 是 IL2CPP 托管代码剥离等级，可以在一定程度上移除未使用的代码。但它不是为"移除调试代码"设计的，它移除的是"未被引用的托管类型/方法"。

也就是说，如果你的调试方法被某个事件或者反射引用，剥离器不会删它。不要指望 Strip Engine Code 或 Managed Stripping 能帮你做这件事。真正稳妥的路径，仍然是前文说的一套：条件编译 + 资源过滤 + 构建校验。

这里多提一句，高剥离等级可能会给你带来意外的"惊喜"，比如某个你本来在用的类被误删了，导致运行时才出现MissingMethodException或TypeLoadException。因此剥离等级的配置，最好按发布节奏做渐进式验证，不要上来直接 Highest。

6. 宏的工程化：一个可落地的调试开关配置方案

6.1 将调试宏纳入版本控制系统

现在大多数团队都用 Git，代码合并、分支管理都很成熟。但宏配置这块，往往会因为不同人手动切换 Editor 里的 Define Symbols 而导致冲突。

我的做法是把宏配置的基准放到一个文件里，比如用PlayerSettings脚本一次性设置，而不是让每个人在编辑器里手动改。这样做的好处：

• 宏配置跟着代码走，什么分支对应什么宏是确定的。
• 切换分支时，宏自动同步，不会出现"我这个分支没作弊宏，合过来就有了"的尴尬。

可以用一个菜单命令来做：

public static class DebugMacroSetup { [MenuItem("Tools/宏配置/开发包宏")] public static void ApplyDevMacros() { PlayerSettings.SetScriptingDefineSymbolsForGroup( BuildTargetGroup.Standalone, "MYGAME_DEBUG;MYGAME_DEBUG_LOG;MYGAME_DEBUG_MENU;MYGAME_DEBUG_CHEAT" ); PlayerSettings.SetScriptingDefineSymbolsForGroup( BuildTargetGroup.Android, "MYGAME_DEBUG;MYGAME_DEBUG_LOG;MYGAME_DEBUG_MENU;MYGAME_DEBUG_CHEAT" ); // ... } [MenuItem("Tools/宏配置/正式包宏")] public static void ApplyReleaseMacros() { PlayerSettings.SetScriptingDefineSymbolsForGroup( BuildTargetGroup.Standalone, "" ); PlayerSettings.SetScriptingDefineSymbolsForGroup( BuildTargetGroup.Android, "" ); // ... } }

配合 Git 分支策略，开发分支在切换到出包分支前执行一次"正式包宏"，从根上防止作弊代码被编译进去。

6.2 多团队协作时的宏规范

如果你在一个超过五个开发者的团队里，调试宏光靠个人自觉是不够的。我建议在项目规范里明确这几条：

• 任何新增调试代码必须带宏保护，不允许裸写 Debug.Log。
• 调试宏的命名统一加项目前缀（如MYGAME_），避免和 Unity 内置宏、插件宏冲突。
• 调试相关的菜单、快捷键、参数，必须放在#if UNITY_EDITOR || DEVELOPMENT_BUILD内。
• 正式包构建前必须跑一遍上文的"构建校验脚本"，但不允许有人手动跳过。

6.3 从环境变量注入宏，适配 CI

自动化构建时，我们经常从命令行传递参数给 Unity。这时可以通过-executeMethod或环境变量控制宏配置，例如：

unity -batchmode -quit -projectPath YourProject \ -executeMethod BuildScript.PerformReleaseBuild \ -buildTarget Android \ -logFile build.log

在 BuildScript 内部，通过环境变量或者布尔参数判断本次是开发包还是正式包，再配置对应的宏。这比每次在命令行手写一长串 Define Symbols 更可靠。

public static void PerformReleaseBuild() { var args = System.Environment.GetCommandLineArgs(); bool isRelease = false; for (int i = 0; i < args.Length; i++) { if (args[i] == "-isRelease") { isRelease = true; break; } } if (isRelease) { ApplyReleaseMacros(); // 执行构建 } else { ApplyDevMacros(); // 执行构建 } }

这样，开发包和正式包使用同一个构建入口，差异只在参数上。

7. 摸过不少坑之后的经验

这篇文章写到这里，核心内容基本都覆盖了。最后聊一点我个人在实际项目中的体会。

我第一次做 Unity 项目的时候，也曾经天真地以为"不勾 Development Build 就是正式包"。实际上完全不是——不勾选开发模式只是 Unity 自带的开发者开关被关闭了，你自己代码里的调试逻辑如果不做编译期剔除，还是会一个不落地跑起来。后来我意识到，Count on the compiler, not on yourself，也就是"把希望寄托在编译器上，不要寄托在自己的记忆力上"。从那以后，我在项目里推行的每一件事，最终都指向同一个目标：用机制代替记忆。

具体来说，有这么几个值得坚持的习惯：

1. 调试代码必须从编译期隔离，而不是运行时隐藏。运行时隐藏只是"看不见"，编译期剔除才是真的没有。
2. 构建校验脚本不要让人能轻易跳过，最好作为构建链路中一个不可绕过的步骤。如果团队里存在"临时跳过校验出包"的风气，那这个流程迟早会形同虚设。
3. 日志是服务线上问题的，不是服务开发期的。设计好日志的分级和开关，开发期尽情打，正式包只留 Error，对线上问题定位有着不可替代的作用。
4. 正式包构建完成后，最好抽几分钟用字符串搜一下包体，这习惯能救回很多低级失误。我搜出过自己留下的"测试金币按钮"文本，也搜出过同事留在代码里的内网数据库连接字符串——那种冷汗直冒的感觉，经历过一次就不想再有了。

还有一个小技巧：给所有调试相关类加一个统一的命名空间后缀，比如MyGame.DebugTools，这样在构建校验脚本里可以直接通过程序集扫描找到所有调试工具类，统一禁用或剔除。这个方法比盯着场景找组件要省力得多，尤其是项目大了以后。

调试代码本身没有错，错的是它出现在了不该出现的版本里。把这些内容从正式包里抠出去的过程，本质上就是在帮你梳理项目的工程化程度。希望你读完这篇文章，不用再跟我一样，靠发出去的正式包出丑来长记性。