周恰恰这种脚本接口一旦上线，往往要支撑大面积流量和长周期运行，平时看似正常的代码，在某次特殊输入、上游抖动或资源耗尽时，才会暴露出真实成色。你会发现，很多程序不是被多么复杂的逻辑打败的，而是被一个空指针、一段异常格式的数据、一个忘了释放的连接、一次没有超时保护的外部调用慢慢拖垮。这类问题，本质上不是"功能有没有实现"的问题，而是"代码健不健壮"的问题。这也是我写这篇理论篇第二篇的原因：把"健壮性"这件事从定义到做法拆开讲清楚，让处于从"能跑"到"可靠"阶段的开发者，能有一套可复用的检查思路。
1. 先从"健壮性"的定义下手：它比"不报错"复杂得多
1.1 一个反直觉的事实：代码不报错不代表健壮
很多人对健壮性有个误解，觉得"程序没崩溃、没抛异常，就是健壮"。这个理解非常危险。一个程序正常运行，可能只是因为当前输入恰好都在预期范围内，并没有经历过真正的考验。
举个例子。你写了一个函数，从订单金额中计算折扣：
python复制def calc_discount(amount):
return amount * 0.9
输入 100 返回 90.0，测试也过了，看起来一切正常。但如果传入的是 None、字符串 'abc'、负数 -50，甚至是一个超大的浮点数 1e308，这个函数会怎样？有的语言直接抛异常，有的语言会返回一个荒谬的结果，还有的会因为参与运算的类型不对，直接把整个进程拖入状态错乱。代码"不报错"，很可能只是因为还没碰到让它出错的数据。
真正的健壮性，要能在"输入不符合预期、外部依赖出问题、运行环境产生变化"时，依然保持可控、可恢复、可诊断。它不是你写了几百行防御代码就一定算好，而是要在"防崩溃、能兜底、能自愈"三个层次上都站得住。
1.2 健壮性的三个层次：防崩溃、能兜底、能自愈
我习惯把健壮性拆成三层来看，每一层的目标和检查方法都不一样。
第一层是防崩溃。程序遇到非法输入、空值、资源不足、并发竞争时，不会发生进程级崩溃、死锁或者永久性卡死。这里的核心是边界控制——把所有可能"越界"的地方都拦截下来。比如数组下标访问前判断长度、除法运算前判断分母、解析字符串前判断格式。
第二层是能兜底。即使某个环节确实出错了，系统也要能给用户一个合理的结果，而不是直接白屏、报错或者返回一堆乱码。最常见的兜底手段是降级策略：接口超时了返回缓存数据，库存服务挂了直接提示"稍后重试"而不是把整个下单流程卡死。这里的核心不是"不能出错"，而是"出错后依然可用"。
第三层是能自愈。错误发生后，系统能通过重试、回滚、补偿任务等方式自行恢复到正常状态，而不是留下一个永远处于中间态的数据，或者需要人工半夜爬起来重启。比如数据库写入失败时，事务能回滚；消息队列消费失败时，能自动重新入队；调用第三方服务超时后，能有一个后台任务做对账补偿。
用一个生活化的类比来理解：一辆车性能好，是指在平坦路面上能加速快、操控好；而一辆车健壮，是指在烂路上不散架、爆胎后还能靠备胎开去维修站。编程领域也一样，功能需求解决的是"在正常情况下把事做对"，健壮性解决的是"在异常情况下不把事情搞砸"。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 输入防线：把"脏数据"拦在第一道门外
2.1 永远不要信任任何输入来源
大部分健壮性问题，根源都是"过度信任"。你信任用户会填合法格式，信任上游接口会返回契约字段，信任配置文件里不会出现空值，信任数据库不会返回脏数据。现实是，这些信任几乎都会被打破。
我做系统时有一条原则：外部输入不可信，内部代码可置信。所谓外部输入，包括所有跨越模块边界的数据，不只是用户通过表单提交的内容，上游服务返回的 JSON、消息队列里收到的消息、配置中心的参数、数据库表里被另一个团队写入的值，全都算。只要不是当前进程内部自己生成并严格校验过的数据，就默认它可能是脏的。
这条原则在工程上表现为两个动作：入口统一校验，出口统一兜底。在请求进入核心业务逻辑之前，先做一次完整的合法性检查，不合法就直接拒绝，或者转换成一个安全的默认值。在下游依赖返回数据之后，也要校验一遍，不能拿到就用。
2.2 类型、范围、格式：三个必查维度
具体校验哪些东西？我总结了三个必查维度：类型、范围、格式。
类型检查，是看数据确实是你预期的类型，而不是一个 None、一个空字符串、一个意外的对象。Python 里经常遇到 NoneType 导致的各种异常，Java 里则是 NullPointerException 重灾区。一个健壮的接口，在第一步就会把这类问题拦掉。
范围检查，是看数据是否落在业务允许的取值区间。年龄不可能是负数，库存不可能是负数，页码不能是 0 或者 -1，单次查询条数不能超过 1000。很多业务事故不是逻辑写错了，而是数据超了边界之后，后续代码基于错误值继续计算，最终产生了荒谬的订单金额、重复的转账、错乱的排名。
格式检查，是看数据是否符合业务约定的格式规范。是邮箱就得像邮箱，是手机号就得是合法的号段，是日期就得是 YYYY-MM-DD，是 JSON 就得能被正常解析。格式错乱的数据，往往会让后续的序列化、反序列化、字符串拼接直接崩掉。
下面这段代码展示了在接口入口处做三层校验的常见姿势：
python复制def register_user(name, age, email):
# 类型检查：None 直接拒绝
if name is None or not isinstance(name, str):
raise ValueError("name must be a non-empty string")
# 范围检查