Unity中如何正确使用-diag-temp-memory-leak-validation参数排查内存泄漏

一、-diag-temp-memory-leak-validation参数的正确用法 #

你之前加错地方了——这个参数是Unity编辑器的启动参数，不是C#编译器参数，所以不能放在Project Settings/Player/Additional Compiler Arguments里，那会被当成C#编译选项，自然报CS2007/CS2001错误。正确添加方式分三种：

• Windows：右键Unity快捷方式→属性→目标栏，在Unity.exe路径末尾加空格，再追加-diag-temp-memory-leak-validation
• Mac：打开终端，用命令行启动Unity，示例：/Applications/Unity/Hub/Editor/[你的Unity版本号]/Unity.app/Contents/MacOS/Unity -projectPath "/你的项目绝对路径" -diag-temp-memory-leak-validation
• Unity Hub：找到你的项目，点击右侧三个点→Add Argument，输入该参数后启动项目

启动后，Unity会在编辑器日志里输出临时内存泄漏的调用栈，直接去Window > General > Console里查看即可。

二、快速排查[ExecuteAlways]标记脚本 #

既然怀疑是这类代码，直接按以下步骤定位：

• 在Project窗口搜索框输入ExecuteAlways，找出所有带该标记的脚本（Top Down Engine自带不少编辑器工具类脚本会用这个）
• 逐个临时注释掉[ExecuteAlways]标记，每次注释后刷新编辑器，观察Memory Profiler里的GC Allocated In Frame数值变化，找到导致激增的可疑脚本
• 对可疑脚本重点检查：Update/OnGUI/OnDrawGizmos等生命周期方法里，有没有每帧创建新对象的操作——比如每次new集合、字符串拼接、临时数组、匿名委托，这些都是编辑模式下GC暴增的常见原因
• 注意：ExecuteAlways标记的脚本在编辑模式下会每帧运行，哪怕没进入Play模式，微小的分配都会快速累积成明显的GC异常

三、用Memory Profiler深层定位 #

如果上面的方法没找到根源，用内存分析器精准定位：

• 打开Window > Analysis > Memory Profiler
• 在编辑模式下，先点击Take Snapshot，等待5-10秒后再拍一次快照
• 切换到Comparison视图，对比两个快照的对象差异，找出新增数量最多的对象类型
• 点击该对象类型，查看Call Stack面板，直接跳转到创建该对象的代码位置
• 优先排查临时对象（比如字符串、List/Array、输入系统的临时回调对象），这类是最容易引发GC骤增的源头

四、Top Down Engine与Input System的常见兼容坑 #

• 部分旧版Top Down Engine和新版Input System存在兼容性问题，比如输入回调里频繁创建临时动作引用或匿名委托
• 一些带ExecuteAlways的编辑器脚本没做编辑模式判断，比如在Update里反复调用InputAction.ReadValue()，每次都会生成临时对象
• 可以尝试把Top Down Engine更新到最新兼容版本，或者暂时回退到Input System的稳定旧版（如果项目允许）

内容的提问来源于stack exchange，提问作者Gregory Fenn