同名只跑一次
同一个处理器被多个任务通知时，默认只执行一次，执行时机仍在统一的末尾阶段。这正是它比“在任务里直接重启服务”更值得用的原因：改十处配置也只重载一次。但去重是按处理器名字做的，参数不同、名字不同都会被当成两个处理器各跑一次，想精细控制动作顺序就得靠合理命名与声明顺序。
基本信息
| 去重粒度 | 按处理器名合并，同名的多次通知只执行一次 |
|---|---|
| 执行顺序 | 按声明顺序，不按通知顺序 |
| 生效前提 | 仍需有任务实际发生变更 |
| 例外情况 | 强制触发之后再有变更会再执行一次 |
典型使用场景
- 多个任务修改同一份配置，只需重载一次服务
- 同一个处理器被不同任务多次通知，确认它只执行一次
- 动作参数不同的场景拆成多个命名处理器，例如先校验再重载
- 需要按固定顺序执行多项服务动作，靠声明顺序表达
- 排查重复重启：先看是不是用了两个名字或写了两段同名动作
合并与拆分
合并与拆分
# handlers 段示例
# - name: 重载 nginx # 同名的多次通知会合并为一次
# ansible.builtin.service:
# name: nginx
# state: reloaded
# - name: 校验并重载 nginx # 动作不同就是另一个处理器
# ansible.builtin.shell: nginx -t && systemctl reload nginx
#
# 任务侧：notify 写处理器名即可，多个任务可以通知同一个名字
# notify: 重载 nginx执行次数对照
| 情形 | 执行次数 | 说明 |
|---|---|---|
| 同名处理器被多次通知 | 一次 | 合并到末尾统一执行 |
| 同名但动作写了两遍 | 取决于解析结果 | 易出现只跑其中一段的错觉 |
| 不同名字的处理器 | 各一次 | 顺序按声明顺序 |
| 强制触发后再变更 | 再执行一次 | 合并失效的常见原因 |
同名处理器重复声明时，实际行为取决于解析结果而不是通知先后，容易得到只跑了一部分的错觉。坚持一个名字对应一段动作。
把重启动作写进多个处理器会让服务被重启多次，连接中断时间叠加。能合并的动作合并进同一个处理器，确需分开时在注释里写清顺序意图。
用命名表达意图
处理器名最好直接说明动作与对象，例如重载某服务、重载某项配置，而不是笼统地写重启服务。名字清楚之后，通知点一眼能看出意图，合并与拆分也不再依赖记忆；同一批变更需要两个动作时，用两个名字并在注释里说明顺序要求。