应避免使用 try: ... except: pass，因其会掩盖错误、干扰调试、导致资源泄漏；须捕获具体异常类型、记录日志，并仅在业务可接受时忽略异常。
为什么 try: ... except: pass 是危险的默认选择
它不只掩盖错误，还会让问题在下游爆发得更难排查。比如网络请求失败后静默跳过，后续代码用到未初始化的变量，报错位置和真实原因完全脱节。
- 异常类型太宽泛：
except:捕获所有异常，包括KeyboardInterrupt和SystemExit，可能打断正常退出流程 - 丢失上下文：没打印或记录异常信息，下次遇到同样问题时毫无线索
- 掩盖逻辑缺陷：本该校验输入却靠“忽略”来绕过，导致脏数据流入数据库或 API
应该捕获具体异常，而不是所有异常
Python 的异常体系很细，IOError、ValueError、KeyError 各自代表不同语义。盲目用通用 except Exception: 会模糊问题边界。
- 优先写明异常类型：
except FileNotFoundError:而不是except: - 多个预期异常可分层处理：
except (ConnectionError, TimeoutError): - 不确定时宁可不捕获，让程序崩在明确位置，也比静默失效强
忽略异常前必须回答三个问题
每次写 pass 或空 except 块，都等于主动放弃调试线索。先确认：
- 这个异常是否真的属于“业务上可接受的偶然情况”？比如临时网络抖动 vs 配置文件彻底缺失
- 有没有替代方案？例如用
dict.get(key, default)替代try/except KeyError - 如果必须忽略，是否至少加了日志？
logging.warning("忽略 %s", e)比什么都没有强十倍
生产环境里最常被忽略的副作用
异常被吞掉后，资源泄漏和状态不一致比报错更难发现。比如文件没关、连接没释放、缓存没更新，这些问题往往隔几小时甚至几天才暴露。
立即学习“Python免费学习笔记（深入）”；
-
with语句不能替代异常处理逻辑，它只保证退出时执行清理，不解决“中间出错怎么响应” - 异步任务中忽略异常会导致任务静默终止，监控系统收不到失败信号
- 单元测试里用
assertRaises验证异常是否被抛出，但没人测“异常是否被意外吞掉”
真正麻烦的不是报错，而是你以为它没事，其实它已经在后台悄悄腐烂。留个日志，比什么都实在。
