Python自动化脚本卡死主因是subprocess未设超时或未及时读取I/O；schedule调度不可靠，应换APScheduler并配置持久化；pydantic v2配置类需显式设extra="allow"和frozen=False；CI失败多因PYTHONPATH未正确设置。
Python 自动化脚本跑着跑着就卡死？先查 subprocess 的阻塞模式
很多自动化任务用 subprocess.run() 或 subprocess.Popen() 调外部命令，但没设超时或没读 stdout/stderr，一遇到交互式程序或输出量大的命令（比如 ffmpeg、rsync -v），进程就挂住不动——不是代码崩了，是卡在 I/O 缓冲区满了。
实操建议：
立即学习“Python免费学习笔记（深入）”；
-
subprocess.run()必须加timeout=30，否则默认无限等待 - 如果要实时捕获输出（比如日志流），别用
stdout=subprocess.PIPE+.communicate()，改用.stdout.readline()循环读，否则大输出直接内存爆掉 - Windows 下注意
shell=True会多一层 cmd.exe，容易让Ctrl+C失效；Linux 下则要小心shell=False时路径含空格会报FileNotFoundError
定时任务从 schedule 换到 APScheduler 的真实理由
schedule 看似简单，但实际部署后常出问题：进程重启后任务丢失、多个实例重复触发、没法动态增删任务。它只是个“轮询器”，不是调度服务。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 单机长期运行选
APScheduler的BackgroundScheduler，配SQLAlchemyJobStore可持久化任务状态 - 若用
asyncio写主逻辑，必须用AsyncIOScheduler，否则混用线程/协程会锁死事件循环 - 避免把数据库连接、文件句柄等资源写在 job 函数里——APScheduler 默认每个 job 新起线程，资源不自动继承，容易报
sqlite3.ProgrammingError: Cannot operate on a closed database
为什么 pydantic v2 的 BaseModel 不能直接当配置类用了？
v2 默认禁用 extra="allow"，且字段赋值后不可变（frozen=True 默认生效）。你读 YAML 配置进 BaseModel 实例，再想动态加字段（比如根据环境 patch 一个 api_url），会直接抛 TypeError: object is not subscriptable 或 ValidationError。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 配置类务必显式声明
model_config = {"extra": "allow", "frozen": False} - 别用
model_dump()后手动改 dict 再转回 model——字段校验逻辑会丢；该用model_copy(update={...}) - 如果配置来源混合（env + file + CLI args），优先用
pydantic-settings，它内置了层级覆盖逻辑，比手撸BaseModel更稳
CI/CD 里 Python 自动化脚本总失败？检查 PYTHONPATH 和 sys.path 的隐式污染
本地能跑的脚本，一上 GitHub Actions 或 GitLab CI 就报 ModuleNotFoundError，常见原因是：你在本地开发时靠 IDE 自动把项目根目录加进了 sys.path，但 CI 环境干净，pip install -e . 没执行，或 setup.py 里漏写了 packages。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- CI 脚本开头加一句
python -c "import sys; print(sys.path)"，确认项目路径真在其中 - 不用
os.chdir()切工作目录来“解决导入”——这会让相对路径行为不一致，尤其涉及open("config.yaml")时 - 依赖包版本锁死用
pip-compile生成requirements.txt，别只靠poetry export或pip freeze，后者会带进 dev-only 包（比如mypy）导致线上环境臃肿
自动化体系不是堆工具，而是控制变量：每个 subprocess 要有超时，每个调度器要有状态存储，每个模型要明确生命周期，每个 CI 步骤要隔离环境。漏掉其中一环，半年后你会在凌晨三点翻旧日志找那个没设 timeout 的 subprocess 调用。
