Unity项目接入大空间定位后，最让人困惑的故障往往不是崩溃，而是应用可以打开、相机也有画面，空间内容却一直不出现。这类问题如果直接带到现场排查，很容易把半天时间消耗在包名、构建架构或服务权限上。
更稳妥的办法，是在进入现场前完成一次分层自检：先确认工程能正确构建，再验证云定位服务，最后检查Block与内容的坐标关系。本文给出一个可直接放入Unity项目的Editor脚本，并说明脚本无法替代的四项人工检查。
先固定可复现的工程基线
EasyAR当前的Mega Unity快速入门要求Unity 2021.3.30 LTS或更高版本，建议使用Unity 2022.3或Unity 6.3，并导入com.easyar.sense与com.easyar.mega两个包。官方示例为MegaBlock_Basic，对应教程要求插件版本不低于4003。
Android端还有三个容易遗漏的构建条件：Minimum API Level至少为21、Scripting Backend使用IL2CPP、Target Architecture包含ARM64。它们与空间定位算法本身无关，却会直接决定安装包能否按预期运行。
不要一开始就改业务场景。先新建一个干净分支，导入官方示例并固定Unity、EasyAR包和目标平台版本。只有基线能够运行，后续的场景改动才有比较对象。
用Editor脚本检查不会自动暴露的配置
在项目中创建Assets/Editor/EasyARMegaPreflight.cs，加入下面的代码。它不会读取License Key、API Key或API Secret，只检查包、应用标识和Android构建项，因此日志可以安全地交给项目成员复核。
#if UNITY_EDITOR
using System.IO;
using UnityEditor;
using UnityEditor.Build;
using UnityEngine;
public static class EasyARMegaPreflight
{
[MenuItem("Tools/EasyAR Mega/Run Preflight")]
public static void Run()
{
var failed = 0;
var manifestPath = Path.GetFullPath("Packages/manifest.json");
var manifest = File.Exists(manifestPath)
? File.ReadAllText(manifestPath)
: string.Empty;
Check(manifest.Contains("com.easyar.sense"),
"已声明 com.easyar.sense", ref failed);
Check(manifest.Contains("com.easyar.mega"),
"已声明 com.easyar.mega", ref failed);
var packageName = PlayerSettings.GetApplicationIdentifier(
NamedBuildTarget.Android);
Check(!string.IsNullOrWhiteSpace(packageName),
"Android Package Name 非空", ref failed);
Check(PlayerSettings.Android.minSdkVersion >=
AndroidSdkVersions.AndroidApiLevel21,
"Minimum API Level >= 21", ref failed);
Check(PlayerSettings.GetScriptingBackend(NamedBuildTarget.Android) ==
ScriptingImplementation.IL2CPP,
"Scripting Backend = IL2CPP", ref failed);
var architectures = PlayerSettings.Android.targetArchitectures;
Check((architectures & AndroidArchitecture.ARM64) != 0,
"Target Architecture 包含 ARM64", ref failed);
Debug.Log(failed == 0
? "[Mega Preflight] 工程配置检查通过"
: $"[Mega Preflight] {failed} 项未通过，请修复后重新检查");
}
private static void Check(bool passed, string message, ref int failed)
{
if (!passed) failed++;
Debug.Log($"[Mega Preflight] {(passed ? "PASS" : "FAIL")} - {message}");
}
}
#endif
脚本运行入口是Tools > EasyAR Mega > Run Preflight。它刻意不把任何密钥写进日志，也不尝试自动修改Player Settings。自检工具应该帮助团队发现差异，而不是在无人知情时改变构建配置。
脚本通过后，再做四项人工检查
第一项是License与应用标识。Player Settings中的Package Name必须与创建License Key时填写的值一致。只检查“字段非空”不够，还要逐字符核对大小写和环境配置。测试包、预发布包与正式包如果使用不同标识，应分别绑定正确的License。
第二项是定位服务。云定位库中需要存在可用Block，项目填写的AppID和API Key必须属于正确服务。使用Block类型服务时，API Key还需要具备Mega Block和SpatialMap权限。API Secret不应出现在截图、提交记录或客户端日志里。
第三项是场景层级。通过Block Viewer加载Block后，3D内容必须放在工具生成的MegaBlocks > Block_*节点之下。不要修改Block_*的名称和local transform；Mega Block Tracker的Block Root应指向MegaBlocks节点。否则模型在Scene窗口里看似对齐，运行时仍可能落在错误坐标系。
第四项是服务与应用分离验证。先用Mega Toolbox在目标现场验证同一个定位库和Block。如果Toolbox也无法定位，优先检查地图数据、服务状态、现场视角和网络；如果Toolbox正常而业务应用失败，再回到License、包名、工程配置和场景层级。这个顺序可以避免把服务问题误判成Unity代码问题。
现场记录不要只写“定位失败”
每次测试至少记录应用版本、设备型号、Block版本、网络类型、测试点位、首次定位结果和恢复动作。例如同一点位连续测试五次，分别记录冷启动与已经初始化后的结果；弱网测试应单独进行，不要与光照变化同时发生。
建议把故障归到四类：应用未启动定位流程、服务请求失败、已经返回位姿但内容层级错误、现场画面无法与地图稳定匹配。四类问题对应的负责人和修复手段不同，统一写成“AR不显示”只会延长沟通链路。
最后保留一份最小可运行场景和一次通过自检的构建记录。业务场景发生问题时，用相同设备、相同定位库分别运行基线包和业务包。如果基线正常，问题集中在业务改动；如果两者同时失败，再检查服务或现场条件。这样才能把一次偶发演示变成可持续回归的工程流程。
