最近刷技术社区，"别再用Airflow了"几乎成了一种流量密码。有人说DAG堆到800多个之后每天早上调度延迟半小时，有人吐槽排查一个失败任务要翻三层日志，还有人说两三个人的小团队花两周搭Airflow集群，大半时间耗在调Celery Worker配置上，业务代码一行没写。知乎
这些吐槽是不是真的？大概率是真的。但就在劝退帖刷屏的这两个月，Airflow自己干了两件事：7月6日发了3.3.0，8月12日又补了3.3.1。GitHub我把官方release notes和社区里最有代表性的几条吐槽逐条对了一遍，发现事情比"老工具该退休了"要有意思得多。
先说结论：Airflow的毛病是真的，但它正在以一种劝退者们没预料到的速度补短板。现在做"去还是留"的决定，值得先看完3.3到底改了什么。
社区吐槽最狠的三条，3.3回应了几条
吐槽一：任务思维管不了数据，血缘、资产、重算全靠手工。
这是Dagster阵营攻击Airflow最核心的点：你编排的是"任务跑没跑完"，不是"数据是不是新的、从哪来的、上游变了要不要重算"。
3.3的回应相当直接——资产分区（Asset Partitioning）大扩展。这个能力3.2开始引入，3.3加上了RollupMapper（多对一汇总）、FanOutMapper（一对多分发）、固定键映射加时间窗口（天/周/月/季/年），还能用wait_policy控制分区下游什么时候触发。GitHub翻译成人话：上游一个数据事件，可以按分区自动扇出成一堆下游DAG运行，也能把多个分区卷起来算汇总，而且窗口可以向前或向后扇出。再加上PartitionedAtRuntime这种"跑起来再定分区键"的调度模式，Airflow在资产编排这块，已经从"没有"变成了"能正经用"。
吐槽二：排查问题翻三层日志，状态全靠猜。
3.3引入了任务与资产状态存储（AIP-103），任务可以往里塞任意键值状态，跨重试、跨运行都保留，资产也能挂自己的状态。GitHub这意味着任务失败后不用只靠日志考古，状态本身就是可查询的现场。配合另一个新特性——可插拔重试策略（AIP-105），重试不再是写死一个次数，而是可以按异常类型、按自定义逻辑决定要不要重试、隔多久重试。这两条加一起，是在正面回应"运维黑盒"的批评。
吐槽三：只有Python能写，多语言团队难受。
3.3加了语言Task SDK的Coordinator层（AIP-108），DAG和调度还留在Python里，但单个任务可以用别的语言写，目前官方以实验性支持Java和Go。知乎Java SDK的1.0.0-beta1已经在7月13日单独发布。GitHub注意官方明确标注了"实验性"，现在冲进去当小白鼠还早，但方向本身值得记一笔：那个"Airflow=纯Python"的标签，正在被撕掉。
还有一个容易被忽略但很关键的信号：版本节奏。3.0是2025年4月发的，到3.1隔了5个月，3.1到3.2隔了6个月，而3.2到3.3只隔了3个月。一个"该退休的老工具"不会把minor版本越跑越快。
那劝退帖说得全错吗？也不是
有些吐槽，3.3并没有解决，而且短期内也解决不了。
第一，架构重量没变。Scheduler、DAG Processor、API Server、元数据库、Worker，五个组件还是五个组件。知乎社区里那句"小团队能用cron加Python脚本解决的，就别上Airflow"，到3.3依然成立。如果你是五人以下的团队、从零开始选型，Airflow大概率不是最优解——这不是情怀问题，是运维成本问题。
第二，大规模调度的性能账，官方不会替你算。800个DAG延迟半小时那种案例，和部署形态、数据库、Executor配置都有关，3.3没有承诺"调度性能翻倍"这种话。已经踩坑的团队，升级3.3不等于自动解药。
第三，资产能力的成熟度差距还在。Airflow的资产模型是3.x才开始认真做的，Dagster从2019年就围着软件定义资产转。知乎能用和好用之间，隔着生态、工具链和最佳实践的积累。
所以去还是留？给你一棵决策树
已经跑着Airflow、痛感不强的大中型团队：留着，把升级3.3排进计划。资产分区和状态存储值得拿一条真实管道试点。这时候迁移的机会成本大于收益。
正在被调度延迟、日志排查折磨的团队：先升级3.3，用状态存储和重试策略把运维体验改善一轮，再评估要不要迁移。社区里从Airflow迁到Dagster的经验是，代码迁移不是大头，思维方式重构才是，通常要2到4周。知乎而且Dagster有兼容层可以直接导入Airflow的DAG过渡。没被3.3改善到的痛点，才是你迁移的正当理由。
还没上编排工具的小团队：别从Airflow入门，这条社区共识很清晰。Prefect安装零摩擦适合快速跑起来，Dagster适合把数据资产当核心资产的团队。不过这里有个变量：社区文章提到2026年7月Prefect收购了Dagster Labs，两家现代编排器合并后产品线怎么整合还不明朗，目前还是单源消息，重仓之前建议再观望一下。知乎
用Java或Go写核心业务、只有调度层需要Python的团队：可以开始盯Task SDK的进展，等它从实验性转正，多语言团队的适配成本会明显下降。
顺带一提，3.3连backfill历史回填这种细节也动了：重跑、补数时可以选用最新代码版本，也可以锁定回原始版本，试点新管道时回滚空间更大。GitHub
接下来值得盯的三个信号
一是Prefect和Dagster合并的后续。如果整合顺利，"迁移目标"会变成一家公司的两条产品线，路线图变化直接影响迁移决策。二是Java/Go Task SDK什么时候摘掉实验性标签。三是pg_durable这类新物种——微软6月开源的PostgreSQL扩展，号称把持久化执行直接塞进数据库，如果这条路走通，编排工具的形态可能整个变掉。<#&!53#&!>知乎
一句话总结：劝退Airflow的声音是真的，但Airflow 3.3的回应也是真的。2026年这个问题的答案不是"跑或留"，而是"先升级，再看痛点还剩多少"。
