应避开Airflow当任务周期固定、依赖少、无跨系统搬运，或团队不熟悉DAG与executor配置；Prefect易因语义错误（如Task含副作用、Flow顶层调用未装饰函数）导致任务不被追踪；Luigi的requires()必须返回Task实例，否则依赖图解析失败；自研调度器仅适用于已有执行框架需轻量调度，或任务粒度达秒级。
什么时候该避开 airflow？
如果你的任务调度周期固定、依赖少、不涉及跨系统数据搬运，或者团队里没人愿意碰 DAG 定义和 airflow.cfg 里的 executor 配置，airflow 就是杀鸡用牛刀。它启动慢、Web UI 依赖完整服务栈、单机模式下连 LocalExecutor 都可能因并发数错配导致任务卡住。
- 典型踩坑：用
SequentialExecutor跑多任务，结果所有任务串行排队，以为“调度器坏了” - 真实场景：每天凌晨跑一次 ETL，源是 MySQL，目标是 CSV 归档 ——
schedule.every().day.at("02:00").do(...)+APScheduler更轻 - 兼容性注意：
airflow2.0+ 强制 Python 3.8+，且插件生态对 PyPy/conda 环境支持弱
prefect 的 Task 和 Flow 为什么容易写错？
不是语法错，是语义错：把本该是纯函数逻辑的 Task 写成带状态副作用的操作（比如在 Task 里直接改全局变量），或在 Flow 顶层调用未装饰的函数，导致调度时根本不会被追踪。
- 常见错误现象：
Flow运行后日志显示 “No tasks submitted”，实际代码已执行 —— 因为没用@task装饰器 - 参数差异：
@task(retries=3, retry_delay_seconds=10)是任务级重试；@flow(retry_policy=RetryPolicy(max_retries=1))是整个 Flow 失败后重跑，二者不叠加 - 性能影响：本地运行时默认用
ConcurrentTaskRunner，但若任务含大量 I/O（如频繁读文件），反而不如SequentialTaskRunner稳定
用 luigi 写依赖链，requires() 返回什么才安全？
必须返回 Task 实例，不能返回列表推导式结果、也不能返回未实例化的类（比如写成 requires(self): return [MyTask]）。否则调度器无法解析依赖图，会静默跳过下游任务。
- 典型错误：
requires()里用os.path.exists()做前置判断，结果路径不存在时返回空列表 ——luigi当作“无依赖”，直接执行当前任务，而非报错阻断 - 使用场景：ETL 流程中“清洗 → 校验 → 加载”，每个环节输出一个
Target（如LocalTarget("data/cleaned.parquet")），requires()就得对应返回生成该 Target 的 Task 实例 - 兼容性注意：
luigi不处理任务失败后的自动回滚，得自己在run()里写try/except清理中间文件
自研调度器真有必要吗？
只在两种情况下值得考虑：一是已有成熟任务执行框架（比如公司内部的 Python 批处理服务），只需加一层 cron+状态轮询；二是任务粒度极细（秒级触发、单次执行airflow 或 prefect 的调度开销（DB 查询、序列化、心跳）已占耗时 30% 以上。
立即学习“Python免费学习笔记（深入）”；
- 容易被忽略的复杂点：分布式锁。多个 worker 同时抢同一个任务时，靠文件或 DB 行锁很容易漏掉竞态，
redis.lock()是目前最稳的轻量方案 - 别低估的维护成本：一旦加了重试、超时、优先级、资源限制，代码量会快速逼近
celery的简化版，而你还没法复用它的监控和 CLI 工具 - 真实建议：先用
APScheduler+sqlite持久化撑三个月，等任务数破 50、失败率超 5%，再评估迁移
