Python json.loads 解析超大整数时如何限制输入风险

处理外部 JSON 时，别把“JSON 文档有多大”和“某个整数有多少位”混成一个限制。json.loads() 负责语法解析，Python 3.11 起默认的 parse_int=int 会受解释器整数字符串长度限制；但一旦传入自定义 parse_int，业务代码就应该自己检查数字 token。更稳妥的做法是：入口先限制请求体或文件大小，再用 parse_int 限制单个整数的十进制位数。

先分开文档大小和整数位数

一个 200 KB 的 JSON 可能包含很多正常数字，也可能只含一个几千位的整数。前者主要消耗请求读取和对象构造资源，后者会进入十进制整数转换。因此建议先把边界写成两个名字清楚的配置：MAX_JSON_BYTES 控制原始输入，MAX_INT_DIGITS 控制单个整数。

为什么只调解释器限制还不够

Python 文档说明，json.loads 的 parse_int 默认等价于 int(num_str)。从 Python 3.11 开始，这个默认转换会使用解释器的整数字符串长度限制，默认值通常是 4300 位，具体应以当前解释器的 sys.int_info 为准。它解决的是十进制整数转换的通用成本问题，不会限制整个请求体，也不会替你制定业务字段的更小上限。

更容易漏掉的是自定义解析器：如果直接写成 parse_int=lambda value: int(value)，你就重新接管了这条路径；如果换成字符串或其他数值类型，也不能假设默认 int 限制仍然存在。解释器级配置适合统一约束进程，接口级规则仍要在输入入口明确表达。

用 parse_int 建立业务级数字边界

下面的解析器把负号排除在位数统计之外，再调用 int(token) 完成真正转换。ValueError 不是模糊的“解析失败”，而是可以在接口层映射为“整数过长”的输入错误。示例没有把上限调成 0，也没有为了兼容超大 ID 把所有数字转换成浮点数；ID 是否应该用字符串，应由接口协议决定。

import json

MAX_JSON_BYTES = 1_000_000
MAX_INT_DIGITS = 100

def bounded_int(token: str) -> int:
    # 负号不是数字位，按绝对值的十进制位数判断。
    digits = token[1:] if token.startswith("-") else token
    if len(digits) > MAX_INT_DIGITS:
        # 在创建大整数前拒绝，避免把策略交给默认配置。
        raise ValueError("integer literal is too long")
    # 合法的小整数仍保持 Python int，方便后续业务计算。
    return int(token)

def loads_safely(body: bytes):
    # 请求体大小和单个整数大小是两条独立边界。
    if len(body) > MAX_JSON_BYTES:
        raise ValueError("JSON document is too large")
    # parse_int 会接收每个 JSON 整数字面量的字符串。
    return json.loads(body, parse_int=bounded_int)

这里的关键顺序不是“先把数字转出来再检查”，而是把位数判断放在 int(token) 之前。对一个正常请求，payload 中的普通整数仍是 int；对超限请求，异常在解析边界处结束，不会继续进入业务层。

把限制放到输入入口并检查异常

HTTP 框架通常还应在 Web 服务器或中间件设置请求体上限；函数内的 len(body) 是最后一道清晰的应用边界，不是替代网络层限流的方案。对文件输入也一样，尽量先取得受控的 bytes，再传给解析器。

import json

def decode_payload(body: bytes):
    # 先区分请求体过大，再进入 JSON 语法与数字策略。
    try:
        return loads_safely(body)
    except ValueError as exc:
        # 统一处理整数过长、文档过大等业务输入边界。
        raise ValueError(f"JSON input rejected: {exc}") from exc
    except json.JSONDecodeError as exc:
        # 语法错误单独保留，便于返回 400 或记录字段位置。
        raise ValueError(f"invalid JSON at position {exc.pos}") from exc

如果需要更严格的 API 错误码，可以把两个 ValueError 换成自定义异常，例如 PayloadTooLarge 和 IntegerTooLong。这样监控能区分客户端发送了过大文档，还是某个字段的数字超出协议约定。

解释器级配置应该放在哪里

sys.get_int_max_str_digits() 可以查看当前进程的解释器级限制，sys.set_int_max_str_digits() 可以调整它。这个设置影响进程中的通用整数字符串转换，过低还可能影响包含超长十进制整数字面量的源码导入，所以不建议为了一个接口在任意业务函数里全局修改。

如果确实需要统一策略，把设置放在明确的启动入口，并在测试环境覆盖边界值。对单个 JSON 字段，优先使用 bounded_int 这样的局部规则；对请求体大小，则由网关、框架和应用三层协同限制。这样既能保留 Python 默认保护，也不会把业务协议写成一个隐含的全局副作用。

相关问题

Python 3.10 能直接依赖默认的 json.loads 限制吗？

不能把跨版本行为当成业务规则。若要兼容旧版本，使用显式的 parse_int 位数检查，并在部署矩阵中测试超限输入。

把 parse_int 改成 decimal.Decimal 能解决风险吗？

它改变的是数值类型，不等于限制输入长度。仍应在自定义解析函数中先检查 token，另外为小数和指数形式定义单独策略。

把超大 ID 全部改成字符串可以吗？

可以，但要让接口协议、序列化格式和数据库字段保持一致。字符串化是语义选择，不应作为无条件绕过输入边界的办法。