Ansible中failed/changed与failed_when/changed_when冲突及官方行为问询

我来帮你梳理Ansible里关于failed_when和changed_when的官方规则，解决你提到的冲突疑问：

1. 官方对“特性冲突”的定义与解决方案 #

其实官方并不认为这是冲突，而是把failed_when和changed_when看作对模块默认返回值的自定义修正机制。默认的.failed和.changed是模块自身根据执行逻辑生成的，但实际场景中用户经常需要根据业务规则自定义失败/变更判断标准，这两个关键字就是用来满足这种需求的——它们的作用是替换默认的.failed和.changed字段值，而非与默认值并行存在。

2. 评估顺序与相互影响规则 #

官方明确规定这两个关键字的评估逻辑是完全独立、互不影响的，具体流程是：

• 首先，模块正常执行，生成原始返回结果（包含模块默认的.failed、.changed以及其他输出字段）。
• 随后，Ansible会分别独立评估changed_when和failed_when的表达式：
  • changed_when仅负责决定最终返回结果中.changed字段的最终值，不受.failed状态的影响。
  • failed_when仅负责决定最终返回结果中.failed字段的最终值，同样与.changed的状态无关。

3. 在failed_when中引用command_result.failed的行为 #

当你在failed_when里引用command_result.failed时，这里的.failed指的是模块执行后生成的原始默认值，而非经过failed_when修改后的最终值。举个实际例子：

- name: 测试自定义失败判断
  command: /bin/false
  register: cmd_result
  failed_when: cmd_result.failed == false

在这个任务中，command模块执行/bin/false会生成默认的.failed=true；随后failed_when的表达式cmd_result.failed == false会被评估为false，因此最终任务的.failed字段会被设置为false——也就是任务不会被标记为失败。

这里的核心逻辑是：failed_when使用的是模块原始返回值，避免了循环依赖的问题。

内容的提问来源于stack exchange，提问作者sourcejedi