企业官网建设流程全解析

大家好，我是 SiKi老师。小工具读取settings.json后报JSONDecodeError，很多人会立刻把异常吞掉，再写一份默认配置。这样做有个隐患：原文件可能只是空了、写到一半，或者字段格式不对。先记录错误位置和文件状态，通常更容易找到真正的问题。

本文在 Windows、Python 3.12.14 中完成独立文件实验，不涉及游戏项目的真实配置。Python 的json.load()和json.loads()在输入不是有效 JSON 文档时会抛出JSONDecodeError，接口说明见 Python 3.12 json 文档。

一 三份文件，不要混成同一种失败

我在临时目录中准备了三份 UTF-8 文件：一份空文件、一份缺少值的 JSON，以及一份合法对象。

错误同为JSONDecodeError，位置却不同。空文件说明解析器一开始就没有读到 JSON；第二种至少读到了键名和冒号。位置不是修复方案，但它能缩小检查范围。

二 先读取，再给出可用的错误信息

下面的示例只读取一份指定文件。它不会自动覆盖原文件。

importjsonfrompathlibimportPath path=Path('settings.json')text=path.read_text(encoding='utf-8')try:settings=json.loads(text)exceptjson.JSONDecodeErrorasexc:raiseRuntimeError(f'配置不是有效 JSON：{path}，第{exc.lineno}行第{exc.colno}列')fromexc

如果文件不存在，read_text()会先产生FileNotFoundError；这和 JSON 格式错误是两条不同的分支。上一轮文章已经讨论过相对路径的起点，这里假设你已经确认path指向正确文件。

三 默认值应该由谁决定

默认值适合在“用户没有提供配置”的明确产品约定下使用，不适合悄悄盖住损坏文件。比如首次运行时，程序可以在用户确认的目录创建示例配置；但运行中读到一个存在却无效的文件，更稳妥的动作通常是保留原件、提示位置，再由用户决定是否修复。

如果程序确实需要恢复流程，先把备份策略、写入时机和失败结果写清楚。不要在异常处理里直接写回同一个路径，然后声称原来的设置仍然存在。

四 检查解析成功后的形状

json.loads()成功也不代表配置可用。JSON 的顶层可以是列表、字符串、数字或null。如果工具需要对象和volume字段，继续做明确检查。

ifnotisinstance(settings,dict):raiseTypeError('配置顶层应为对象')volume=settings.get('volume')iftype(volume)isnotint:raiseTypeError('volume 应为整数')

这里用精确类型检查，是因为 Python 中bool也是int的子类；JSON 的true不应在这个例子里被当作整数音量接受。这段没有规定音量的允许范围。范围、单位和缺省规则应按自己的项目约定实现，不能从这段练习代码推导出来。

五 把失败留在可定位的位置

我会在日志中记录文件名、错误行列和异常类型，不打印完整配置。配置可能包含账号、地址或内部参数，公开贴出全文反而会引入新问题。

本文没有验证多人同时写入、断电恢复、加密配置或网络文件系统。它只给出一个顺序：先确认文件内容是否可解析，再验证字段形状，最后才讨论是否需要默认值或恢复流程。

你遇到的报错位置是第 1 行第 1 列，还是某个具体字段附近？两种情况的排查起点不同。