为何需同时使用`connection: local`与`delegate_to: localhost`？是否有优势？

核心结论 #

同事的说法部分正确，但绝大多数场景下不需要同时使用这两个参数，甚至可能增加配置的混淆性。

两者的本质区别 #

先明确两个参数的实际作用：

• delegate_to: localhost：将任务的执行目标主机切换为控制机（localhost），但执行时会沿用该主机在inventory中配置的连接方式——如果你的localhost默认是SSH连接（没特殊配置的话），它会通过SSH连本地；如果inventory里给localhost设了ansible_connection=local，则会直接本地执行。
• connection: local：强制任务使用本地直接执行的方式，完全跳过SSH连接流程，不管任务的目标主机是谁。

对同事说法的验证 #

同事提到的delegate_to仅改变SSH目标、connection: local用直接本地连接，这个描述是准确的。但说“两者结合消除层级提升速度”的说法存在误区：

• 如果你的localhost已经在inventory中配置了ansible_connection=local（这是Ansible的通用最佳实践），单独用delegate_to: localhost就会自动走本地连接，和加connection: local的效果完全一致，不存在性能差异。
• 只有当localhost默认用SSH连接（未配置local连接）时，connection: local才会跳过SSH握手带来小幅性能提升，但这种场景非常少见——正常都会给localhost设置本地连接。

正确的使用场景 #

1. 只想在控制机执行任务：直接用connection: local即可，不需要delegate_to，这个参数会强制任务在控制机本地运行，无需指定目标主机。
2. 基于inventory配置的本地执行：如果已经给localhost配置了ansible_connection=local，直接用delegate_to: localhost就足够，无需额外加connection: local。
3. 极端特殊场景：仅当localhost默认是SSH连接，且你需要临时强制某个任务绕开SSH直接本地执行时，才需要同时使用两者——但这种情况几乎不会出现在规范的Ansible配置中。

额外提醒 #

同时使用两个参数会增加配置的理解成本，后续维护者可能疑惑为什么要重复设置，建议优先采用单一参数的简洁写法。

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