Python 系统稳定性建设的方法论

必须设 restart=always 才能兜底重启崩溃的 python 进程，配合 restartsec=5 和 startlimitintervalsec=0 防高频重启与永久禁用；日志需用 streamhandler(sys.stderr) 并显式设 handler 级别；慎用 del 避免内存泄漏；依赖升级须用 –no-deps 与 –force-reinstall 确保纯净。

Python 进程崩溃后不重启？用 systemd 管理服务时必须设 Restart=always

很多 Python 后端或定时任务跑在 linux 上，一崩就停，没人拉起来。根本原因不是代码写得差，而是没让系统知道“这玩意儿该一直活着”。systemd 默认不重启失败服务，得显式配置。

• Restart=no（默认）：崩了就躺平，日志里只留 Failed with result 'exit-code'
• Restart=always 才真能兜底，但要配合 RestartSec=5 避免高频重启打满 CPU
• 别信 Restart=on-failure —— Python 里 sys.exit(0) 是成功退出，非零才算失败；而有些框架（如 fastapi 的 uvicorn）异常退出码不固定，实际表现和 always 差不多，但语义模糊、难排查
• 记得加 StartLimitIntervalSec=0，否则 systemd 默认 10 秒内崩 5 次就 permanently disable 服务

日志刷屏却找不到报错源头？Logging.basicConfig 默认不输出到 stderr

本地调试看着好好的，上生产后 print() 全消失、logging.info() 也不见踪影——大概率是没把日志导向正确位置。systemd 服务默认只捕获进程的 stdout 和 stderr，而 Python logging 默认只写文件或控制台，不自动连过去。

• 直接删掉所有 FileHandler，改用 StreamHandler(sys.stderr)，再传给 basicConfig(handlers=[...])
• 别依赖 level 参数隐式生效：basicConfig(level=logging.INFO) 只设置 root logger 的 level，但 handler 自己也有 level，默认是 WARNING，结果 INFO 日志全被拦在 handler 外面
• 如果用了 structlog 或 loguru，确认它们是否已接管 root logger；否则两套日志系统打架，systemd 里只能看到一半

内存缓慢上涨、GC 不顶用？检查 __del__ 和循环引用是否绕过垃圾回收

Python 的 GC 能处理大部分循环引用，但一旦对象带 __del__ 方法，整个引用环就进不了 generational GC 的清理范围——它会被标记为 “uncollectable”，长期驻留内存。这种问题上线后几小时才暴露，监控看是 RSS 持续涨，gc.collect() 手动调也没用。

• 用 gc.get_objects(generation=2) 抓出老年代对象，再筛出疑似泄漏类的实例，比盲猜快得多
• 避免在类里写 __del__，尤其不要在里面做网络请求、发日志、关文件——这些操作可能触发新对象创建，进一步锁死引用链
• 真需要资源清理，优先用 contextlib.closing 或 with + __enter__/__exit__，它们不参与 GC 判定逻辑
• 异步场景更危险：async def __aexit__ 是安全的，但 __del__ 在 async context 下行为不可控，有些对象甚至不会被调用

依赖升级后行为突变？pip install 缺少 --no-deps 和 --force-reinstall 组合

线上环境 pip 升级某个包，结果另一个看似无关的模块开始抛 AttributeError: module 'xxx' has no attribute 'yyy'。不是代码改错了，是旧版依赖缓存没清干净，或者新版本悄悄改了公共接口的返回类型（比如把 list 改成 generator）。

立即学习“Python免费学习笔记（深入）”；

• CI/CD 中执行升级命令时，务必加 --no-deps：防止顺手把上游依赖也升了，引发连锁变更
• 单测通过 ≠ 行为兼容，用 pip install --force-reinstall --no-deps package_name==x.y.z 确保安装的是干净、精确的版本
• 别信 requirements.txt 里的 == 就万事大吉——如果它被其他包间接依赖，且没锁 transitive deps，照样会中招
• 生产部署前跑一次 pip check，它能发现版本冲突，但检不出 API 行为变化，这点得靠回归测试覆盖

稳定不是靠写得“没 bug”，是靠对进程生命周期、日志流向、内存归还路径、依赖加载顺序这些底层事实的持续校准。漏掉其中任意一环，压测时都可能突然掉链子。