ansible check mode 是有边界的模拟执行机制，需结合模块支持度判断、--diff 输出、assert断言和结构化报告生成，才能实现安全合规的变更前验证。
Ansible 的 Check Mode 不是“只读快照”，而是一种有边界的模拟执行机制。它能帮你预判变更影响、识别潜在风险，并支撑合规报告生成，但必须配合模块支持度判断、输出结构设计和分层验证策略，才能真正落地为安全可靠的线上变更前检查流程。
确认关键模块是否原生支持 check_mode
不是所有模块在 --check 下都行为一致。核心原则是查 ansible-doc -t module
-
support: full（如
user、file、apt、systemd_service）：会模拟完整逻辑，返回准确的changed: true/false和差异信息 -
support: partial（如
copy、lineinfile）：可能跳过内容读取或校验（例如lineinfile在大文件中仍会全量读取，带来性能开销） -
support: none（如
shell、command）：直接标记为skipped: true，看似安静，实则掩盖真实变更点——这类任务必须人工审查或替换为幂等模块
用 --diff + register + debug 构建可审计的变更清单
Check Mode 配合 --diff 参数，能让 copy、template、lineinfile 等模块输出具体行级差异，这是合规报告的核心数据源：
- 对每个配置类任务添加
register: task_result，捕获模块输出 - 用
debug或community.general.csv汇总注册变量，提取diff.before/diff.after、dest、state等字段 - 示例：预演
nginx.conf更新时，--diff会清晰列出将被注释的旧行、新增的 TLS 配置段，直接对应等保/PCI-DSS 中“配置变更需留痕”要求
嵌入 assert 断言做基线符合性判定
合规不仅是“改了什么”，更是“改得对不对”。Check Mode 下 assert 模块仍会执行条件校验，适合嵌入安全基线检查：
- 检查账户锁定状态：
assert: { that: "item.password_lock == true", msg: 'User {{ item.name }} must be locked per policy' } - 验证 SSH 配置强度：
assert: { that: "ansible_sshd_config.PasswordAuthentication|default('no') == 'no'" } - 断言失败时输出明确错误信息，不中断执行流，便于汇总成“不合规项清单”供审计签字
生成结构化报告并规避副作用陷阱
最终报告需兼顾机器可读与人工可审，同时避开 Check Mode 的隐性风险：
- 用
set_fact聚合各节点检测结果（如compliance_passed、files_to_modify、assert_failures） - 结尾统一用
community.general.json_file输出标准化 JSON，字段含时间戳、主机名、检查项、预期值、实际值、是否通过 - 特别注意：避免在 check_mode 任务中调用含副作用的操作（如
uri模块发 POST、docker_container拉镜像元数据），确需探测时优先选stat或setup这类纯读取模块
