Ansible --check 显示正常，正式执行前还要查什么

Ansible 预演没有报错，正式执行却跳过了关键步骤，或者输出里泄露了配置密码。--check 和 --diff 都有使用边界：模块是否支持预演、任务有没有强制绕过 check、差异里是否包含秘密，要分开确认。

check mode 不是运行整个剧本的模拟器

以下示例用于 ansible-core 的常见用法，版本与模块支持情况仍以本机文档为准：

ansible-playbook -i inventory.ini site.yml --syntax-check
ansible-playbook -i inventory.ini site.yml --list-hosts
ansible-playbook -i inventory.ini site.yml \
  --check --diff --limit test-web

test-web 必须是清单里的测试主机或组。语法检查不连接验证所有业务条件，主机列表检查目标范围，check mode 则要求模块预测变化。这三条命令不能互相替代。

支持 check 的模块可以报告预计变化；不支持的模块可能跳过。某个任务没有 changed，不一定表示目标已经满足要求。还要检查被跳过任务对后续 register、条件判断和通知链的影响。

看看剧本有没有绕过预演

任务可以显式配置 check_mode: false，即使整个剧本在 check 模式，该任务也可能正式运行。反过来，check_mode: true 可以让特定任务始终预演。阅读自己执行的剧本，不把从外部取得的 YAML 当成无害配置文件。

command、shell 等命令任务的预演支持有限，不能指望它们猜出任意脚本的变化。某些命令通过 creates、removes 提供判断条件，仍不代表模块完整模拟了脚本。对于数据库迁移、重启和外部 API 调用，另写可核对的预检与恢复流程。

diff 可能输出完整配置

模板任务启用 diff 时，旧文件与新文件内容可能进入终端或 CI 日志。如果文件包含秘密，应限制相应任务的 diff 或使用恰当的日志保护。例如：

- name: Render private application configuration
  ansible.builtin.template:
    src: private-config.j2
    dest: /etc/example/private.conf
    mode: '0600'
  diff: false
  no_log: true

模板路径和目标路径是示例。no_log 会限制诊断输出，排障时也更难看到失败细节；应在受控环境另核对所需字段，不能靠临时公开秘密解决问题。文件权限和模板渲染成功，也不证明应用读取后能够运行。

第一次正式执行只选一个目标

预演完成后，使用同一个 inventory、同一版本剧本和明确的 --limit 进行小范围执行。保存输出并检查实际服务、配置和业务入口，再决定扩大范围。不要在预演与正式执行之间偷偷改变量文件或更换动态清单却沿用旧结论。

把预期 changed、允许重启的服务和恢复步骤写清。若结果与预演不同，停止扩散并查原因。模块支持与任务行为见 Ansible check/diff 文档，目标范围可接着看 inventory 与 limit 检查。