handlers 是仅在被 notify 且对应 task 状态变为 changed 时才执行的特殊 tasks，不按书写顺序运行，而是在 play 所有 tasks 结束后统一、去重、按定义顺序执行。
handlers 是什么，和 tasks 有什么本质区别
handlers 不是“高级 tasks”，而是仅在被 notify 且对应 task 发生了状态变更（即 changed 为 True）时才执行的特殊 tasks。它不会像普通 task 那样每轮都跑，也不会按书写顺序立即执行——Ansible 会把所有 notify 收集起来，等当前 play 的所有 tasks 跑完后，再统一、去重、按定义顺序执行 handlers。
常见误解是以为写在 tasks 后面的 handler 就会“紧接着”运行，其实不会；更危险的是误以为 handler 能响应任意变化（比如文件内容变了但模块没报告 changed），它只认模块返回的 changed 状态。
关键点：只有模块明确标记自己“改变了系统状态”，notify 才会触发 handler。例如 copy 拷相同内容不触发，template 渲染出不同内容才触发；lineinfile 匹配不到目标行并插入了，才算 changed。
怎么写一个能被正确触发的 handler
handler 定义在 play 顶层的 handlers 区块里，名字必须和 notify 字符串完全一致（包括空格和大小写）。它本身也是 task 结构，但只能用支持“服务管理”的模块，最常用的是 systemd 或 service。
- name: Update nginx config
copy:
src: nginx.conf
dest: /etc/nginx/nginx.conf
notify: Reload nginx
<p>handlers:</p>
- name: Reload nginx systemd: name: nginx state: reloaded daemon_reload: no
注意几个易错细节：
-
systemd模块的state: reloaded表示发送SIGHUP（平滑重载），不是restarted（重启进程），这对线上服务很关键 - 如果目标系统用 SysV init（如旧版 CentOS 6），得换用
service模块，并确认该 service script 支持reload子命令 -
daemon_reload: no是默认值，除非你真改了.service文件本身，否则别开，开了反而可能因 unit 文件未加载而失败
为什么改了配置但 handler 没触发？排查三步法
最常遇到的现象是：配置文件明明更新了，Reload nginx 却没执行，play 结束后服务还是旧配置。
- 检查对应 task 是否真的返回
changed：在 playbook 末尾加- debug: var=ansible_facts不管用，应该加- debug: msg="changed status: {{ your_task_name_result.changed }}"（需先用register捕获结果） - 确认
notify字符串和 handlername逐字符一致，建议复制粘贴，别手敲 - 查看完整输出加
-v参数运行：ansible-playbook site.yml -v，搜索NOTIFIED和Running handler关键字，没有出现就说明没触发；若看到skipping: [host]，说明 handler 被跳过了（通常因为没被 notify 或已执行过）
另外，多个 task notify 同一个 handler，它也只执行一次——这是设计特性，不是 bug。
reload 和 restart 的选择逻辑不能靠猜
reloaded 不等于“安全”，它取决于服务自身是否支持热重载。Nginx、OpenSSH、rsyslog 通常支持；但 MySQL、PostgreSQL、Redis 默认不支持配置热重载，强行 reloaded 可能静默失败或无效果。
判断依据只有一个：查该服务的官方文档或直接在目标机器上运行 sudo systemctl reload xxx 看是否报错。如果报 Failed to reload xxx.service: Job type reload is not supported，就必须用 restarted，并接受短暂中断。
- name: Restart redis if config changed
template:
src: redis.conf.j2
dest: /etc/redis/redis.conf
notify: Restart redis
<p>handlers:</p>
- name: Restart redis systemd: name: redis state: restarted
真正容易被忽略的是：有些服务（如 HAProxy）需要先做语法检查再 reload，否则 reload 会失败导致服务中断。这时 handler 应该封装成两步——先 shell: haproxy -c -f /etc/haproxy/haproxy.cfg，再 systemd: state=reloaded，且用 ignore_errors: yes 和 failed_when 控制流程。这不是 handler 的责任边界，而是你得把它写进 handler 里。
