验证形状和允许的范围
定义关卡结构及其必填字段，例如 id、width、height、tiles、spawn、exits 和 entities。检查尺寸是否为游戏支持范围内的正整数，tiles 数组是否恰好包含 width × height 个元素，以及每个 tile 是否使用已知类型。根据网格验证实体坐标，并要求门、钥匙、开关和目标具有唯一 ID。仅检查值是否为数字并不足够；应明确拒绝类似 NaN 或超出范围的值。
将可选字段与必填字段分开。省略的装饰调色板可以使用默认值；但如果补出缺失的出生点或出口会改变谜题，就不要默默补造。返回错误时附上 levels[2].entities[4].x 这样的路径，方便内容作者快速定位有问题的字段。
检查关系和可玩的不变量
结构验证后，检查跨域规则。每扇锁着的门都应该引用现有的钥匙；每把强制钥匙都应在门前够得着；出口不应位于实心瓷砖内。从生成点运行路径搜索，并确认可以根据游戏的移动规则达到所需的目标。如果敌人或移动平台影响访问，请使用更具体的验证器或通关测试，而不是声称简单的网格路径证明整个关卡是可解决的。
安全失败并测试验证器本身
MDN 指出，JSON 无效时 JSON.parse 会抛出 SyntaxError，因此应将解析失败与架构校验失败分开处理。开发时，报告具体文件和未通过的规则。在面向玩家的版本中，应加载已知的备用关卡，或明确显示关卡不可用，而不是用不完整的数据启动。保留覆盖字段缺失、引用错误、路径受阻以及一个有效小关卡的测试用例；有效用例可以防止验证器错误地拒绝所有关卡。
关于游戏级数据验证的常见问题
成功调用 JSON.parse 就足以信任关卡文件吗？
不。解析只能确认语法，不能确认游戏特定的结构、范围、引用关系或可解性规则。在将关卡交给游戏代码之前，请逐项验证。
游戏应该自动修复无效关卡吗？
仅用于安全、明确的默认值。如果修复丢失的目标或路线改变了设计，请拒绝该关卡并使用已知的后备方案，而不是隐藏缺陷。
延伸阅读
发现信息过时了？ 报告需要更正的内容