1. 为什么我要做这次静态扫描横评工作流引擎这个赛道最近两年肉眼可见地热闹起来了。我最早接触的是 Airflow那会儿还在做数据仓库的 ETL 调度后来团队里有人开始用 n8n 做业务侧的自动化再后来 Prefect 2.0 出来我又花了两周时间把它接进了现有的数据管道里。三个引擎都用过一轮之后我脑子里一直有个模糊的感觉它们看起来都在做“编排”但骨子里的设计哲学完全不是一回事。真正让我下决心做这次横评的是一个很具体的场景。我们有个项目需要把一批定时任务从老系统迁移出来候选方案就是这三个。团队里有人主张用 Airflow理由是生态成熟有人推 n8n说拖拽就能搞定还有人觉得 Prefect 的 Python 原生写法更优雅。争论了两周没结论因为大家比的都是“我用得顺手”而不是“它到底是怎么设计的”。所以我换了个思路不看文档怎么写不看官网怎么吹直接对三个引擎的源码做静态扫描。静态扫描的好处是它不会骗人。文档可以美化Demo 可以精心设计但代码结构、依赖关系、模块划分这些东西是藏不住的。一个引擎的“架构基因”就写在这些静态特征里。这篇文章就是这次静态扫描的完整记录。我会从代码结构、依赖图谱、核心抽象、扩展机制几个维度把 Airflow、n8n、Prefect 拆开来看然后基于这些发现给出我自己的选型边界判断。如果你正在做工作流引擎的选型或者单纯想理解这三个东西到底有什么本质区别这篇应该能帮你省下不少翻源码的时间。需要提前说明的是这次扫描针对的是 Airflow 2.x、n8n 1.x、Prefect 2.x 这三个主要版本线。不同版本之间差异可能很大尤其是 Prefect 从 1.0 到 2.0 几乎算是重写了所以版本信息很重要。2. 静态扫描的方法论我到底在看什么2.1 扫描维度的选择逻辑做静态扫描最怕的就是漫无目的地翻代码翻到最后除了“代码写得挺整齐”之外什么结论都得不出。所以我先定了几个扫描维度每个维度都对应一个我想回答的问题。第一个维度是模块划分与目录结构。这个最直观一个项目的目录怎么组织直接反映了作者认为什么是重要的。比如 Airflow 的airflow/下面有models/、operators/、sensors/、hooks/这些目录一看就知道它是围绕“任务类型”来组织的。n8n 的packages/下面分core/、nodes-base/、editor-ui/明显是前后端分离的架构。Prefect 的src/prefect/下面有flows/、tasks/、states/、engine/核心抽象一目了然。第二个维度是核心抽象与继承关系。每个引擎都有自己的一套“世界观”Airflow 的世界里一切皆 Operatorn8n 的世界里一切皆 NodePrefect 的世界里一切皆 Flow 和 Task。这些抽象之间的继承关系、组合方式决定了你用起来顺不顺手也决定了它能做什么、不能做什么。第三个维度是依赖图谱与耦合度。这个稍微技术一点我会看模块之间的 import 关系看看哪些模块是核心、哪些是外围核心模块对外围模块的依赖有多深。耦合度高的引擎改一处动全身耦合度低的扩展起来更灵活。第四个维度是扩展机制的设计。工作流引擎不可能开箱即用满足所有需求扩展能力是刚需。我会看它们各自提供了什么样的扩展点是继承基类、注册插件、还是写配置文件这直接决定了二次开发的成本。第五个维度是配置与状态管理。工作流引擎本质上是个状态机任务的状态怎么存、怎么流转、怎么恢复这些逻辑藏在代码的哪个角落很大程度上决定了它的可靠性和可运维性。2.2 扫描工具与操作方式工具方面我没用什么特别 fancy 的东西主要是pydeps做 Python 项目的依赖图谱madge做 JavaScript/TypeScript 项目的依赖分析再加上cloc统计代码量分布以及大量的手动阅读。手动阅读这部分没法省工具只能告诉你“谁依赖谁”但“为什么依赖”和“这样依赖好不好”还是得靠人判断。具体操作上我先把三个项目的源码 clone 到本地然后分别跑了一遍依赖分析生成模块依赖图。接着按照上面说的五个维度逐个模块去读关键文件。重点看的是核心抽象的定义文件、引擎的调度逻辑、状态管理的实现、以及扩展点的接口设计。提示如果你也想自己做类似的扫描建议先看项目的setup.py或package.json从入口点开始追比漫无目的地翻目录效率高得多。2.3 扫描结果的呈现方式扫描结果我会按引擎逐个呈现每个引擎下面按五个维度展开。最后会有一个横向对比的章节把三个引擎放在一起看给出选型边界的判断。为了让对比更直观关键的地方我会用表格来呈现。需要说明的是静态扫描有它的局限性。它能看到结构但看不到运行时行为能看到设计意图但看不到实际性能。所以这篇文章的结论应该和动态测试结合起来看静态扫描负责回答“它是什么”动态测试负责回答“它跑起来怎么样”。3. Airflow 静态扫描调度器为中心的重量级选手3.1 模块划分围绕 Operator 的任务工厂Airflow 的源码目录结构非常能说明问题。airflow/下面最核心的几个目录是models/、operators/、sensors/、hooks/、executors/、scheduler/。这个划分方式透露了一个关键信息Airflow 的世界观是“任务类型驱动”的。operators/目录下有bash_operator.py、python_operator.py、http_operator.py等等每个文件对应一种任务类型。sensors/是特殊的 Operator用来等待某个条件满足。hooks/是 Operator 和外部系统交互的桥梁比如http_hook.py、postgres_hook.py。这种划分方式的好处是清晰你要做什么类型的任务就去找对应的 Operator。坏处是随着支持的集成越来越多这个目录会变得非常庞大。models/目录是 Airflow 的数据模型层里面有dag.py、taskinstance.py、dagrun.py、connection.py等等。这些模型定义了 Airflow 的核心数据结构也是它和数据库交互的接口。Airflow 的状态管理是强依赖数据库的这一点从models/的代码量就能看出来。executors/目录是执行器的实现有sequential_executor.py、local_executor.py、celery_executor.py、kubernetes_executor.py等等。执行器的选择决定了任务实际在哪里跑这是 Airflow 架构里非常关键的一层抽象。scheduler/目录是调度器的实现这是 Airflow 的心脏。调度器负责解析 DAG、生成 DagRun、创建 TaskInstance、然后交给 Executor 去执行。整个流程是高度中心化的调度器是绝对的核心。3.2 核心抽象DAG 与 Operator 的强绑定Airflow 的核心抽象是 DAG 和 Operator。DAG 是任务的有向无环图Operator 是图中的节点。这两个抽象之间的关系是强绑定的Operator 必须属于某个 DAGDAG 必须由 Operator 组成。从代码上看DAG类在models/dag.py里定义它持有一个tasks列表每个 task 是一个BaseOperator的实例。BaseOperator在models/baseoperator.py里定义它有一个dag属性指回所属的 DAG。这种双向引用意味着 DAG 和 Operator 是紧密耦合的。这种设计的好处是直观你定义一个 DAG然后在里面声明一堆 Operator它们之间的关系用或者set_downstream来指定代码读起来就像在画流程图。坏处是灵活性受限你很难在运行时动态地改变 DAG 的结构因为 DAG 在解析时就已经确定了。Airflow 的另一个核心抽象是TaskInstance它代表一个任务的一次具体执行。TaskInstance有状态属性比如queued、running、success、failed、retry等等。状态流转的逻辑在models/taskinstance.py里这是 Airflow 状态管理的核心。3.3 依赖图谱中心化的调度器依赖从依赖图谱上看Airflow 的模块依赖是相当中心化的。scheduler/依赖models/、executors/、dag_processing/等多个模块而models/又依赖utils/、configuration/等基础模块。整个依赖关系像一棵树调度器是树根其他模块是树枝。这种中心化依赖的好处是逻辑集中调度相关的代码都在scheduler/下面找起来方便。坏处是耦合度高改调度器的逻辑可能会影响到模型层改模型层又可能影响到执行器。我在阅读代码时发现models/taskinstance.py这个文件被大量模块引用它几乎成了整个系统的瓶颈。另一个值得注意的点是 Airflow 对数据库的依赖。models/下面的几乎所有类都是 SQLAlchemy 的模型这意味着 Airflow 的核心逻辑和数据库是深度绑定的。你没法在不启动数据库的情况下运行 Airflow这在一定程度上限制了它的部署灵活性。3.4 扩展机制继承 BaseOperator 是主要路径Airflow 的扩展机制主要是继承。你要自定义一个 Operator就继承BaseOperator然后实现execute方法。你要自定义一个 Sensor就继承BaseSensorOperator实现poke方法。你要自定义一个 Hook就继承BaseHook实现具体的外部系统交互逻辑。这种继承式的扩展机制很直观但也有一些限制。首先你必须要理解BaseOperator的整个生命周期包括pre_execute、execute、post_execute、on_success、on_failure这些钩子方法的调用顺序。其次你的自定义 Operator 必须和 Airflow 的版本保持兼容因为BaseOperator的接口在不同版本之间可能会有变化。Airflow 也支持插件机制通过plugins/目录或者airflow.plugins_manager来注册自定义的 Operator、Hook、Sensor 等。但插件机制本质上还是基于继承的只是多了一层注册的步骤。3.5 配置与状态管理数据库是唯一真相源Airflow 的状态管理是强依赖数据库的。DAG 的定义、TaskInstance 的状态、Connection 的配置、Variable 的值所有这些都存在数据库里。调度器通过轮询数据库来发现需要执行的任务执行器通过更新数据库来报告任务状态。这种设计的优点是状态持久化做得好Airflow 重启后状态不会丢而且可以通过数据库查询来监控任务执行情况。缺点是数据库成了单点数据库的性能直接影响整个系统的吞吐量。我在实际使用中遇到过数据库连接池被打满的情况整个调度器就卡住了。Airflow 的配置主要通过airflow.cfg文件和环境变量来管理。配置项非常多从数据库连接、执行器类型、到调度器的各种超时参数几乎每个行为都可以配置。这种灵活性是好事但也增加了运维的复杂度。4. n8n 静态扫描节点驱动的可视化编排引擎4.1 模块划分前后端分离的 Monorepo 结构n8n 的源码结构是典型的 Monorepopackages/下面分core/、nodes-base/、editor-ui/、workflow/、cli/等几个包。这个划分方式透露的信息和 Airflow 完全不同n8n 是一个前后端分离的应用可视化编辑器是它的核心组成部分。core/是后端核心里面有WorkflowExecute.ts、NodeExecuteFunctions.ts、WorkflowDataProxy.ts等文件。nodes-base/是内置节点的实现每个节点一个目录比如nodes/HttpRequest/、nodes/Set/、nodes/If/。editor-ui/是前端编辑器用 Vue 写的里面有画布、节点面板、属性面板等组件。这种划分方式的好处是职责清晰后端负责执行前端负责编辑节点实现独立成包。坏处是包之间的依赖关系比较复杂core/依赖workflow/nodes-base/依赖core/editor-ui/又依赖nodes-base/的类型定义。改一个地方可能要重新构建多个包。4.2 核心抽象Node 与 Workflow 的松耦合n8n 的核心抽象是 Node 和 Workflow。Node 是工作流中的一个步骤Workflow 是节点的集合以及它们之间的连接关系。和 Airflow 不同n8n 的 Node 和 Workflow 是松耦合的Node 定义在nodes-base/里Workflow 定义在workflow/里两者通过接口交互。从代码上看INodeType接口定义了节点的行为包括execute方法、description属性等。Workflow类在workflow/包里定义它持有一个nodes数组和一个connections对象。connections对象描述了节点之间的连接关系比如哪个节点的输出连到哪个节点的输入。这种松耦合的设计让 n8n 的节点可以独立开发和测试也方便社区贡献节点。你写一个自定义节点只需要实现INodeType接口然后注册到 n8n 里就行不需要修改核心代码。n8n 的另一个核心抽象是WorkflowExecute它负责执行工作流。WorkflowExecute接收一个Workflow对象和一个NodeExecuteFunctions对象然后按照连接关系依次执行节点。执行过程中数据以INodeExecutionData的形式在节点之间传递。4.3 依赖图谱包之间的分层依赖从依赖图谱上看n8n 的包依赖是分层的。workflow/是最底层的包它只依赖一些基础工具库。core/依赖workflow/提供了执行引擎和节点执行函数。nodes-base/依赖core/实现了具体的节点。editor-ui/依赖nodes-base/的类型定义实现了可视化编辑器。cli/依赖core/和nodes-base/提供了命令行入口。这种分层依赖的好处是每一层都可以独立测试和复用。比如workflow/包可以单独用来解析和验证工作流定义不需要启动整个 n8n。坏处是层与层之间的接口需要精心设计否则容易出现循环依赖。我在扫描时发现core/和nodes-base/之间的依赖比较紧密core/里有一些代码直接引用了nodes-base/里的节点类型。这种反向依赖在一定程度上破坏了分层的清晰性但考虑到 n8n 的节点数量庞大完全解耦可能也不太现实。4.4 扩展机制实现 INodeType 接口n8n 的扩展机制是实现接口。你要自定义一个节点就创建一个类实现INodeType接口然后在description属性里描述节点的输入输出、参数、图标等信息在execute方法里实现节点的具体逻辑。这种接口式的扩展机制比继承更灵活因为你可以完全控制节点的行为不需要理解一个庞大的基类。n8n 还提供了INodeTypeDescription接口来描述节点的元数据这些元数据会被前端编辑器读取用来渲染节点的属性面板。n8n 的节点可以用 JavaScript 或 TypeScript 写也可以用 Python 写通过n8n-nodes-python之类的桥接。这种多语言支持让不同背景的开发者都能贡献节点但也增加了运行时的复杂度。4.5 配置与状态管理执行数据在内存中流转n8n 的状态管理和 Airflow 完全不同。Airflow 把状态存在数据库里n8n 则把执行数据放在内存中。WorkflowExecute在执行过程中维护一个runExecutionData对象里面记录了每个节点的执行状态和输出数据。这种内存式的状态管理让 n8n 的执行速度很快因为没有数据库的 IO 开销。但缺点是状态不持久化如果 n8n 进程崩溃正在执行的工作流状态就丢了。n8n 也支持把执行记录保存到数据库但这是可选的而且主要是为了审计和调试不是执行的必要条件。n8n 的配置主要通过环境变量来管理比如N8N_PORT、N8N_DATABASE_TYPE、N8N_BASIC_AUTH_ACTIVE等等。配置项比 Airflow 少很多上手更简单但可定制性也相对有限。5. Prefect 静态扫描Python 原生的现代编排框架5.1 模块划分围绕 Flow 和 Task 的扁平结构Prefect 的源码结构是三个引擎里最扁平的。src/prefect/下面有flows.py、tasks.py、states.py、engine/、client/、deployments/、blocks/等。这个划分方式透露的信息是Prefect 的核心抽象很少而且定义得很清晰。flows.py和tasks.py是 Prefect 的两个核心模块分别定义了Flow和Task类。states.py定义了状态相关的类比如State、Completed、Failed、Running等等。engine/是执行引擎负责运行 Flow 和 Task。client/是和 Prefect 服务端交互的客户端。deployments/是部署相关的逻辑。blocks/是配置和凭证管理的抽象。这种扁平结构的好处是容易理解你不需要在复杂的目录层级里找东西。坏处是随着功能增加顶层模块会越来越多src/prefect/下面已经有几十个模块了。5.2 核心抽象Flow 与 Task 的装饰器模式Prefect 的核心抽象是 Flow 和 Task而且它们是通过装饰器来使用的。你写一个函数加上flow装饰器它就变成了一个 Flow加上task装饰器它就变成了一个 Task。这种设计让 Prefect 的代码读起来就像普通的 Python 代码没有 Airflow 那种“声明式”的感觉。从代码上看Flow类在flows.py里定义它持有一个fn属性指向被装饰的函数。Task类在tasks.py里定义结构类似。Flow和Task之间的关系是动态的一个 Flow 可以调用任意多个 TaskTask 之间也可以互相调用这种调用关系是在运行时确定的不需要提前声明。这种动态关系是 Prefect 和 Airflow 最大的区别之一。Airflow 的 DAG 是静态的你在解析时就要确定任务之间的依赖关系。Prefect 的 Flow 是动态的你可以在运行时根据条件决定调用哪些 Task这让 Prefect 更适合处理复杂的、有分支的逻辑。Prefect 的另一个核心抽象是State。每个 Flow Run 和 Task Run 都有一个状态状态可以是Pending、Running、Completed、Failed、Crashed等等。状态之间的流转由引擎控制你可以通过钩子函数在状态变化时执行自定义逻辑。5.3 依赖图谱引擎与客户端的双中心从依赖图谱上看Prefect 有两个中心engine/和client/。engine/依赖flows/、tasks/、states/等核心模块负责执行逻辑。client/依赖schemas/、utilities/等模块负责和服务端通信。这两个中心之间的依赖相对较少engine/通过client/来上报状态但执行逻辑本身不依赖服务端。这种双中心的设计让 Prefect 可以以两种模式运行一种是有服务端的模式状态上报到 Prefect 服务端可以在 UI 上看到执行情况另一种是无服务端的模式状态只在本地管理适合开发和测试。这种灵活性是 Airflow 和 n8n 都不具备的。Prefect 对数据库的依赖也比 Airflow 弱。在无服务端模式下Prefect 可以用 SQLite 存储状态甚至可以用内存存储。在有服务端模式下Prefect 用 PostgreSQL 或 SQLite 作为后端但执行引擎本身不直接依赖数据库而是通过客户端来交互。5.4 扩展机制装饰器和钩子函数Prefect 的扩展机制主要是装饰器和钩子函数。你可以用task装饰器把任意函数变成 Task用flow装饰器把任意函数变成 Flow。你还可以用with_options方法来配置 Task 的重试策略、超时时间、缓存策略等。Prefect 也支持钩子函数比如on_completion、on_failure、on_crashed等等。你可以在 Flow 或 Task 上注册这些钩子在状态变化时执行自定义逻辑。这种钩子式的扩展比继承更轻量你不需要理解一个庞大的基类只需要写一个函数就行。Prefect 还提供了Block抽象来管理配置和凭证。你可以把数据库连接、API 密钥等敏感信息封装成 Block然后在 Flow 或 Task 里引用。Block 可以存在本地也可以存在 Prefect 服务端这种灵活性让配置管理变得更方便。5.5 配置与状态管理本地优先服务端可选Prefect 的状态管理是本地优先的。在无服务端模式下状态存在本地文件或内存里执行引擎直接管理状态流转。在有服务端模式下状态通过客户端上报到服务端但执行引擎仍然在本地运行。这种设计的好处是 Prefect 的部署非常灵活。你可以在本地开发机上跑一个 Flow不需要启动任何服务端。你也可以在生产环境部署一个 Prefect 服务端集中管理所有 Flow 的状态和调度。这种灵活性是 Airflow 和 n8n 都不具备的。Prefect 的配置主要通过prefect.toml文件和环境变量来管理。配置项比 Airflow 少但比 n8n 多。Prefect 还提供了一个prefect config命令行工具来查看和修改配置比手动编辑配置文件方便一些。6. 三大引擎横向对比架构基因决定选型边界6.1 核心抽象对比把三个引擎的核心抽象放在一起看差异非常明显。维度Airflown8nPrefect核心抽象DAG OperatorWorkflow NodeFlow Task抽象关系强绑定静态声明松耦合连接驱动动态调用运行时确定使用方式声明式配置为主可视化拖拽为主编程式装饰器为主学习曲线陡峭概念多平缓直观中等Python 原生Airflow 的抽象最重概念最多学习曲线最陡。但它的抽象也最成熟生态最完善适合复杂的、稳定的、需要长期维护的数据管道。n8n 的抽象最轻最直观适合快速搭建业务自动化流程尤其是需要和非技术人员协作的场景。Prefect 的抽象介于两者之间既有 Python 原生的灵活性又有现代编排框架的规范性适合数据科学家和 Python 开发者。6.2 扩展机制对比扩展机制决定了二次开发的成本也决定了引擎能不能适应你的特殊需求。维度Airflown8nPrefect扩展方式继承 BaseOperator实现 INodeType装饰器 钩子扩展成本高需理解生命周期中需理解接口低写函数即可多语言支持Python 为主JS/TS/PythonPython社区生态非常丰富丰富节点多成长中Airflow 的扩展成本最高但社区生态最丰富你需要的 Operator 大概率已经有人写好了。n8n 的扩展成本中等节点开发相对独立社区节点数量增长很快。Prefect 的扩展成本最低但社区生态还在成长中有些集成可能需要自己写。6.3 状态管理对比状态管理决定了引擎的可靠性和可运维性。维度Airflown8nPrefect状态存储数据库必须内存默认本地/服务端可选持久化强弱可选中等恢复能力强弱中等部署复杂度高低中Airflow 的状态管理最重必须依赖数据库但持久化和恢复能力最强。n8n 的状态管理最轻默认在内存中持久化是可选的适合短流程和快速执行。Prefect 的状态管理最灵活可以本地也可以服务端适合不同规模的部署。6.4 选型边界什么场景选什么引擎基于上面的静态扫描结果我给出自己的选型边界判断。选 Airflow 的场景你需要调度大量的、复杂的、有严格依赖关系的数据管道你的团队有专门的运维人员你需要丰富的 Operator 生态来对接各种数据源你的任务需要长期稳定运行状态不能丢。典型场景是数据仓库 ETL、机器学习特征工程管道、大规模批处理任务。选 n8n 的场景你需要快速搭建业务自动化流程你的团队里有非技术人员需要参与流程设计你的流程以 API 调用、数据转换、通知发送为主你希望可视化地看到流程的执行情况。典型场景是营销自动化、CRM 数据同步、内部工具集成、微信自动发布流。选 Prefect 的场景你是 Python 开发者希望用原生 Python 写工作流你的流程有复杂的动态分支逻辑你希望部署灵活可以本地也可以服务端你不需要 Airflow 那么重的生态但需要比 n8n 更规范的编排能力。典型场景是数据科学管道、机器学习实验编排、Python 脚本的自动化调度。7. 实操中的常见问题与排查技巧7.1 Airflow 常见问题问题一调度器卡住不执行任务。这个我遇到过好几次最常见的原因是数据库连接池被打满。Airflow 的调度器、Web 服务器、Worker 都会连数据库如果连接数配置不合理很容易出现连接等待。排查方法是看数据库的活跃连接数如果接近上限就调大sql_alchemy_pool_size和sql_alchemy_max_overflow。问题二DAG 解析失败但看不到具体错误。Airflow 的 DAG 解析是在单独的进程中进行的错误信息可能不会直接显示在 Web UI 上。排查方法是看airflow dag-processor的日志或者手动运行airflow dags list来看解析错误。常见原因是 import 错误或者 DAG 文件里有语法错误。问题三任务一直处于 queued 状态。这通常是执行器的问题。如果你用的是 Celery Executor检查一下 Worker 是否在运行队列是否配置正确。如果你用的是 Kubernetes Executor检查一下 Pod 是否能正常创建。我踩过的坑是 Worker 的并发数配置太小任务排队等 Worker。7.2 n8n 常见问题问题一忘记密码了怎么办。n8n 的密码是存在数据库里的如果你忘了密码可以通过命令行重置。具体操作是进入 n8n 容器运行n8n user-management:reset然后重启 n8n就可以重新设置密码了。这个命令在 n8n 的 CLI 文档里有但不太显眼我第一次找的时候花了点时间。问题二Docker 部署 n8n 后数据丢失。这个坑很常见原因是没挂载数据卷。n8n 的数据默认存在容器内的~/.n8n目录下如果容器重建数据就丢了。解决方法是在docker run时加上-v n8n_data:/home/node/.n8n把数据目录挂载到宿主机上。问题三n8n 连接外部服务时凭证配置错误。n8n 的凭证管理是通过credentials来做的每种节点类型有自己的凭证类型。常见错误是选错了凭证类型或者凭证的字段填错了。排查方法是先在节点的凭证配置里点“测试”看能不能连通然后再保存。7.3 Prefect 常见问题问题一Flow 运行时报状态上报失败。这通常是因为 Prefect 服务端的地址配置错了或者服务端没启动。排查方法是检查PREFECT_API_URL环境变量然后手动访问一下服务端的健康检查接口。如果你不需要服务端可以用prefect config set PREFECT_API_URL来禁用状态上报。问题二Task 重试不生效。Prefect 的 Task 重试需要在task装饰器里配置retries参数或者在with_options里配置。常见错误是配置了重试但没配置retry_delay_seconds导致重试间隔太短任务还没恢复就又开始重试了。问题三Flow 在本地能跑但部署后跑不了。这通常是依赖问题。Prefect 的部署需要把代码和依赖一起打包如果你用的是prefect deploy需要确保prefect.yaml里配置了正确的依赖安装命令。我踩过的坑是本地有某个包但部署环境没有导致 import 失败。7.4 常见问题速查表引擎问题现象可能原因排查方法Airflow调度器卡住数据库连接池满检查活跃连接数调大连接池AirflowDAG 解析失败import 错误或语法错误看 dag-processor 日志Airflow任务一直 queuedWorker 未运行或并发数小检查 Worker 状态和并发配置n8n忘记密码无运行 user-management:resetn8n数据丢失未挂载数据卷检查 docker run 的 -v 参数n8n凭证配置错误凭证类型或字段错误用凭证测试功能验证Prefect状态上报失败API URL 配置错误检查 PREFECT_API_URLPrefect重试不生效未配置 retry_delay检查 with_options 配置Prefect部署后跑不了依赖缺失检查 prefect.yaml 依赖配置8. 我个人的选型心得三个引擎我都用了一段时间如果让我给一个简单的建议我会说看你的团队构成和流程复杂度。如果你的团队里有专门的数据工程师流程复杂且需要长期维护Airflow 是稳妥的选择。它的生态和成熟度是另外两个暂时比不了的虽然学习曲线陡但一旦上手能做的事情非常多。如果你的团队里业务人员比较多需要快速搭建自动化流程n8n 是最友好的。它的可视化编辑器让非技术人员也能参与流程设计而且 Docker 部署非常简单几分钟就能跑起来。但要注意数据持久化的问题生产环境一定要挂载数据卷。如果你是 Python 开发者流程有复杂的动态逻辑Prefect 是最顺手的。它的装饰器写法让工作流代码读起来就像普通 Python 代码而且部署灵活本地开发体验非常好。但它的社区生态还在成长中有些集成可能需要自己写。最后分享一个小技巧如果你不确定选哪个可以先用 n8n 快速搭一个原型验证流程的逻辑。如果原型跑通了再根据实际需求决定要不要迁移到 Airflow 或 Prefect。这样比一开始就纠结选型要高效得多。