meta: clear_facts 仅清除当前 play 内存中的 facts 变量，不影响主机实际状态、ssh 记录、fact 缓存文件或系统标识；它用于防止敏感信息泄露、强制重采或精简内存，但无法解决“机器指纹”或“缓存漂移”问题。
Ansible 的 meta: clear_facts 并不能清空“机器指纹”或规避所谓“缓存漂移”，这个理解存在根本性偏差。它只清除当前 play 中已收集的 facts（即内存中的变量），不影响主机的实际状态、SSH known_hosts 记录、Ansible 的 fact 缓存（如 JSON 文件）、或任何底层系统标识（如 SSH host key、MAC 地址、/etc/machine-id 等）。
什么是 meta: clear_facts 的真实作用
它仅在当前 play 执行过程中，让后续任务无法再访问此前通过 gather_facts: true 或 setup 模块获取的 facts 变量（如 ansible_os_family、ansible_all_ipv4_addresses 等）。常用于：
- 避免敏感信息（如
ansible_product_serial）在后续任务中被意外引用或日志输出 - 在同一个 play 中多次运行
setup模块前重置 facts，强制重新采集（但需手动调用） - 精简内存占用（极少数场景）
所谓“机器指纹”和“缓存漂移”实际指什么
用户常混淆的几类真实问题及对应机制：
-
SSH host key 变更：目标主机重装系统后 SSH 公钥变化，触发 Ansible 连接警告。这不是 Ansible 缓存，而是本地
~/.ssh/known_hosts的记录冲突，需用ssh-keygen -R或ansible_ssh_extra_args="-o StrictHostKeyChecking=no"（不推荐生产）处理 -
Fact 缓存文件残留：启用
fact_caching: jsonfile后，旧 facts 存于fact_cache/目录。若主机配置变更但缓存未更新，会导致判断错误。应定期清理该目录，或设fact_cache_timeout缩短有效期 -
Inventory 动态变化未刷新：使用脚本生成 inventory 时，若未加
--flush-cache或未禁用 cache plugin，可能读到过期 IP/变量。应确保每次执行前 inventory 是最新快照 -
自定义变量污染：在
host_vars/或group_vars/中硬编码了易变字段（如 IP、证书路径），而未通过 facts 或 lookup 动态获取，导致逻辑错位
批量关键节点下真正可控的“指纹同步”实践
若目标是确保多台节点状态一致、避免因历史残留导致行为差异，应聚焦可操作点：
- 统一关闭 fact 缓存：
fact_caching: memory（默认）或直接不配置，避免磁盘缓存干扰 - 在 play 开头显式重新采集 facts：
- setup: gather_subset=all，配合cacheable: no禁用本次缓存 - 对 SSH 层做预检：用
command: ssh-keyscan -t rsa {{ inventory_hostname }}提前获取并校验 host key，失败则中断 - 关键任务前清空临时变量：用
set_fact: { 'my_custom_var': omit }或meta: clear_facts配合后续setup，确保逻辑不依赖旧值 - 用
changed_when: false和check_mode: no显式控制幂等性边界，而非依赖 facts 衍生判断
为什么不建议用 clear_facts “规避漂移”
它既不改变主机实际指纹，也不刷新连接层信任状态，更不清理外部缓存。强行在关键 play 中插入 meta: clear_facts 可能导致后续任务因缺失必要 facts（如 ansible_distribution_major_version）而报错或逻辑跳变。真正的稳定性来自明确的事实来源、及时的缓存管理、以及对基础设施变更的主动响应，而非掩盖变量可见性。
