手动触发是什么
手动触发用于补单、灰度验证与故障应急：绕过定时计划立即跑一次任务，并在触发时显式传入业务日期等参数。它本身不是问题，问题出在「不传参数直接触发」——调度器会取默认日期，很容易覆盖当天正在跑的分区。因此手动触发有两条硬要求：参数显式传入、原因留痕记录。
基本信息
| 适用平台 | Airflow（CLI 与界面）、DolphinScheduler（界面补数与重跑）、其他调度类似 |
|---|---|
| 关键参数 | 业务日期或分区、运行标识，避免使用默认值 |
| 触发方式 | Airflow 用 airflow dags trigger，界面 Trigger DAG with config |
| 留痕内容 | 触发人、触发时间、原因、影响分区与预期结果 |
| 并发风险 | 手动实例与定时实例可能同时写同一分区 |
典型使用场景
- 补单：上游延迟导致某天分区未产出，指定日期重跑该分区
- 应急止损：线上数据错误需立即重算，不等下一个调度周期
- 灰度验证：新逻辑先在单个分区试跑，确认结果再放开全量
- 联调测试：开发环境按指定日期跑通整条链路
- 故障复现：按当时参数重跑，验证修复方案是否有效
Airflow 手动触发
Airflow 手动触发
# 传入业务日期，避免取默认值覆盖当天数据
airflow dags trigger daily_orders \
--conf '{"bizdate": "2026-10-11", "reason": "upstream_delay"}'
# 指定执行日期与逻辑运行标识，便于回溯定位这一次运行
airflow dags trigger daily_orders --exec-date 2026-10-11T00:00:00+08:00
# 确认这次运行是否已进入队列，以及历史运行记录
airflow dags list-runs -d daily_orders | head
airflow tasks states-for-dag-run daily_orders <run_id>参数覆盖风险对照
| 做法 | 风险 | 建议 |
|---|---|---|
| 不传参数直接触发 | 取默认日期，可能覆盖当天正在跑的数据 | 必须显式传业务日期 |
| 手工改代码后重跑 | 代码与线上版本不一致，结果不可复现 | 走发布流程，再触发 |
| 同一分区并发触发两次 | 两实例写同一分区，结果取决于完成顺序 | 先确认无运行中实例，再触发 |
| 应急触发无记录 | 复盘时无法还原现场与影响面 | 记录原因、影响分区与执行人 |
手动触发前先确认目标分区没有正在运行的任务：定时实例与手动实例同时写同一分区时，最终结果取决于完成顺序，事后对账也无法还原。
只对单个任务做调试时可用 airflow tasks test（本地执行、不写调度元数据），它不会产生真实的运行记录，因此不能替代生产补数。