面向失败的设计需预判故障点并确保系统可恢复，而非仅用try/except掩盖错误；每个except必须记录日志、告警或降级，区分i/o异常类型，http失败时优先缓存或切备用接口，非法输入应抛具体异常而非返回none，测试须覆盖失败路径。
为什么 try/except 不该只包住 print()
面向失败的设计，不是“加个异常捕获就完事”，而是预判哪里会崩、崩了之后系统还能不能继续干活。很多人写 try/except 只为了不让程序退出，结果把错误吞掉、不记录、不重试、不降级，等于给故障埋雷。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 每个
except块必须做明确的事：记录日志（用logging.error()，别用print()）、触发告警、返回兜底值或调用降级逻辑 - 避免裸
except:—— 至少写成except Exception:，否则连KeyboardInterrupt都被拦住，本地调试都 Ctrl+C 不了 - 对 I/O 类操作（如
requests.get()、open()），要区分网络超时、连接拒绝、解析失败等不同异常，各自处理，而不是全塞进一个except
requests 调用失败后，怎么才算“系统还在活”
HTTP 请求失败是常态，但“失败”不等于“不可用”。关键看下游挂了，上游是否还能响应、是否能缓存旧数据、是否能切到备用接口。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 设置合理超时：
requests.get(url, timeout=(3, 7))——第一个数是连接超时，第二个是读取超时；不设 timeout，默认可能卡死几十秒 - 用
session复用连接，配合urllib3.Retry控制重试逻辑，但注意：幂等性没保障的请求（如 POST）不能盲目重试 - 失败时优先返回缓存（哪怕过期几秒），比直接抛
502更友好；缓存策略建议用functools.lru_cache或diskcache，别手写全局 dict
函数返回 None 还是抛 ValueError？这是设计分水岭
返回 None 看似简单，但调用方很容易忽略检查，导致后续出现 AttributeError: 'NoneType' object has no attribute 'xxx'，错误位置和根源脱节。
mallcloud商城基于SpringBoot2.x、SpringCloud和SpringCloudAlibaba并采用前后端分离vue的企业级微服务敏捷开发系统架构。并引入组件化的思想实现高内聚低耦合，项目代码简洁注释丰富上手容易，适合学习和企业中使用。真正实现了基于RBAC、jwt和oauth2的无状态统一权限认证的解决方案，面向互联网设计同时适合B端和C端用户，支持CI/CD多环境部署，并提
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 输入非法时，立刻抛出具体异常（如
ValueError、TypeError），而不是返回None让调用方猜 - 查询类函数（如
get_user_by_id()）找不到数据时，按场景选：内部服务间调用建议抛NotFound自定义异常；对外 API 则返回None或空对象，避免暴露内部错误结构 - 如果真要返回
None，函数名里就得体现不确定性，比如叫find_user()而不是get_user()，这是契约信号
测试“失败路径”比测“成功流程”更花时间，但不能跳
单元测试只跑 assert func(1, 2) == 3 是自欺欺人。真正压垮系统的，永远是 func(None, [])、磁盘满、数据库连不上、第三方返回乱码这些 case。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 用
pytest.raises()显式断言异常类型，例如with pytest.raises(ValueError): func(-1) - 模拟失败依赖：用
unittest.mock.patch拦截open()或requests.post()，让它抛ConnectionError，再验证你的降级逻辑是否触发 - 在 CI 中加入故障注入：比如用
tox+pytest-timeout强制超时，或临时删掉配置文件，确认程序不会 panic
真正的面向失败，不是堆防御代码，而是让每次失败都变成一次可观察、可恢复、可推演的行为。最常被忽略的，是没给失败留“出口”——比如重试三次后既不告警也不通知，只是默默返回默认值，那问题就从“偶发”变成了“静默腐烂”。
