游戏配置补默认值：缺字段和null不是一回事

大家好我是 SiKi老师。关卡配置里没写speed与写了speed: null应该怎样补默认速度这个选择需要配置协议来决定。只靠“读到空值就填3”很容易把原本有效的0也改掉。本文在 Windows、Python 3.12.14 中运行自拟 JSON 字符串不读取或覆盖真实游戏配置。例子采用“只有缺字段才提供默认值”的规则没有验证 Unity、Godot 的加载器也不替项目决定空值是否合法。一 先确认字段有没有出现先解析两份最小数据importjson missingjson.loads({})explicit_nulljson.loads({speed: null})print(speedinmissing,speedinexplicit_null)print(missing.get(speed),explicit_null.get(speed))本机执行得到第一行False True第二行None None。不带默认参数的get在这两份数据里返回相同结果如果只保留这个返回值就丢掉了字段是否出现的信息。Python 3.12 JSON 文档 对应的转换表将 JSONnull解析成 PythonNone。这不是解析器帮你删掉字段。键仍然存在值只是明确写成了空值。在我为这份例子写的协议里缺字段表示沿用工具提供的默认值显式空值先保留交给后续校验判断。真实项目也可以规定空值等于清除设置但必须明确写下来不能把这套例子直接当成项目标准。二 给get传默认值只处理缺键Python 字典 get 文档 说明键存在时返回其值键不存在才返回默认值。print(missing.get(speed,3))print(explicit_null.get(speed,3))实际分别得到3和None。如果目标就是保留已有值这已经是简短的读取方法。它不会自动将显式None改成3也不会把新字段写进原字典。这一步只是决定读取时的候选值。速度字段要求数字、是否允许0、是否必须大于0属于另一层业务校验。返回了一个值不等于可以直接交给角色移动代码。如果你看到工具突然采用默认速度先保存字段存在性和原值再调查是哪一步补了默认。只打印最终数字往往看不到变化发生在读取还是校验阶段。三 不要把真假判断当成缺字段判断容易写错的是下面这种写法valueconfig.get(speed)or3这里or检查的是左边的真假值不是键是否存在。Python 真假值文档 将None、False、数值0和空字符串列为假值。我实际测试了缺键、null、0、false、空字符串五种 JSON 输入。上面的表达式五次都得到3。它没有只替换缺字段还替换了四种明确提供的值。0在某个项目里可能代表停止移动也可能被协议禁止。无论哪种都应该根据字段规则判断而不是先用or悄悄换掉。False与0比较可能相等测试时还需要核对类型避免把布尔值当成有效数字。四 把规则写成可以断言的函数下面故意使用键存在性方便读者看清分支defmissing_only(config):returnconfig[speed]ifspeedinconfigelse3assertmissing_only({})3assertmissing_only({speed:None})isNoneassertmissing_only({speed:0})0assertmissing_only({speed:False})isFalseassertmissing_only({speed:})这五项在隔离测试里都通过。我同时保存输入字典的副本核对调用后没有修改原输入对每项结果分别核对类型和具体值。本函数只是读取不生成新配置也没有进行递归合并。另一个办法是将自建的object()当作唯一缺失标记通过is比较get的返回值。它适合后续步骤需要继续携带“缺字段”状态的场景。不要拿None当这个唯一标记否则又会与显式空值混在一起。五 补默认值前还要检查输入结构合法 JSON 可以是顶层null。本机json.loads(null)得到None直接交给上面的函数实际抛出TypeError因为函数按字典协议检查成员。解析成功并不保证顶层是配置对象。如果工具只接收对象先检查解析结果是否为dict再检查字段。对显式空值、字符串或布尔值的处理可以返回带字段名的校验错误不要为了“让游戏启动”就吞掉这些错误并覆盖原文件。本文验证了自拟输入、缺键默认、显式空值保留、0与布尔值区分以及顶层空值失败。没有测试重复键、继承配置、嵌套对象、数值范围或引擎运行。你的配置协议中null表示允许为空、清除已有设置还是应当报错先回答这个问题再选择补默认值的分支。