先限制读取字节，再解析 JSON：离线工具的输入边界

摘要：一个 JSON 文件能够解析，并不意味着它适合交给业务逻辑。本文结合离线流水核对工具，说明大小预检、有限读取、UTF-8 解码、类型检查及结果序列化各自负责什么，并用合成样例解释边界为何需要分层。

处理本地文件时，很容易认为“先看大小，再调用 JSON 解析器”就足够了。但文件会变化，编码可能错误，合法 JSON 也可能包含业务不接受的值。每一步都需要自己的失败出口。

预检只是提前拒绝，读取仍须有限

工具把输入上限设为 1MiB，即 1,048,576 字节。先用 getsize() 拒绝明显过大的文件，可以减少无效读取；但这个数字描述的是检查时的状态，不能保证随后读取的内容仍一样大。

实际读取因此采用二进制模式，并只读取上限加一字节。核心步骤可简写为：

limit = 1024 * 1024
with open(path, "rb") as stream:
    raw = stream.read(limit + 1)
if len(raw) > limit:
    return input_too_large()

这段是流程示意，错误函数名并非工具接口。为什么多读一个字节？按合成边界手算，读到 1,048,576 字节仍未超限；若多出第 1,048,577 字节，就已有足够依据拒绝，无须读完整个文件。只读上限长度，会把“恰好到边界”和“后面还有内容”混在一起。

这里限制的是原始字节。UTF-8 中的“中”占三个字节，不能用字符串字符数代替文件字节数。通过大小检查，也不代表文件内容有效。

解码、解析和业务类型分开判断

代码先把原始字节按 UTF-8 解码，再交给 json.loads()。无效编码与 JSON 语法错误应分别报告，否则用户可能修改标点，却始终修不好编码问题。

接下来仍要校验字段结构和类型。例如合成输入 {"opening_balance":true,"closing_balance":0,"ledger":[]} 本身符合 JSON 语法，但余额要求整数。Python 中 bool 是 int 的子类，因此实现除了检查 isinstance(value, int)，还明确排除 bool；浮点数同样不能冒充整数。

小文件也可能嵌套很深，或包含很长的十进制整数。实现捕获解析阶段的 ValueError、RecursionError，返回结构化错误。这是在处理运行时限制，并没有另设固定的 JSON 嵌套层数或整数位数标准；不能把某次测试环境的限制写成跨版本保证。

输入通过后，结果仍可能无法输出

整数能够读入，不代表派生结果一定能够转成文本。以十进制手算为例，连续四个 9 加 1 会从四位变成五位；同样的进位现象可能让边界附近的整数计算结果超过运行时的转换限制。

工具在核对计算之后，先完成整个结果的 JSON 序列化，并捕获相关异常，再处理请求的报告输出。标准输出使用 ensure_ascii=True，让中文或表情表示为 JSON 转义序列，降低旧版 Windows 输出编码带来的问题；接收方解析 JSON 后仍能恢复相应字符。

证据能支持到哪一步

2026 年 10 月 25 日的历史回归记录包含：把大小预检替换为较小数值后，实际超限文件仍被拒绝；深层 JSON、超长整数和派生总额转换失败返回 JSON 错误；表情经 GBK 标准输出后可解析还原。最终日志记录整个套件 53 项通过，覆盖范围超出本文主题。本文分析阶段只核对源码、测试与既有记录，未为本文重新运行测试；上述合成数字用于手算说明。

有限读取只约束本次取得的原始数据量。解码字符串、解析后的对象和输出文本仍占内存，这不是流式解析器，也没有据此证明总内存上限。字段通过校验同样不证明文件来源真实。把每层成功的含义写清楚，才能让调用者判断结果究竟可用到哪里。