Ruby/Chef中`end if`与`only_if`条件写法有什么区别

这两种写法效果完全不一致，核心差异来自Chef运行的两阶段模型，以及两种写法所属的语法范畴完全不同：前者是Ruby原生的流程控制语法，后者是Chef资源提供的原生守卫（Guard）机制。

两种写法的具体执行逻辑 #

1. 后缀if写法（end if 条件） #

这是纯Ruby语言层面的后置条件判断，判定时机在Chef运行的编译阶段：

• 条件返回假时，do...end包裹的整个资源定义代码块完全不会被解析执行，对应的资源根本不会被加入Chef的待执行资源集合，在本次Chef运行中相当于这个资源从未被定义。
• 条件返回真时，资源才会被正常解析加入资源集合，后续进入执行阶段正常运行。

2. only_if守卫写法 #

这是Chef所有资源内置的条件守卫属性，判定时机默认在Chef运行的执行阶段：

• 无论条件是否成立，资源块在编译阶段都会被完整解析、加入待执行资源集合，块内所有编译期执行的逻辑（普通Ruby代码、非lazy包裹的属性赋值等）都会正常运行。
• 直到Chef按顺序执行到该资源时，才会运算only_if后的条件：条件返回假时直接跳过资源的实际修改动作，将资源标记为跳过状态；条件返回真时才正常执行资源的实际操作。

核心差异对比 #

• 资源可见性差异：后缀if条件不满足时资源完全不存在，如果其他资源配置了对该资源的notifies/subscribes通知、或者存在资源间的依赖引用，会直接抛出“找不到资源”的错误；only_if模式下资源始终存在于资源集合中，依赖、通知关系都能正常解析，只是资源实际执行动作会被跳过。
• 判定时机差异：后缀if的条件仅在编译期运算一次，无法感知执行阶段才生成的节点属性、或前序资源执行后产生的系统状态变化；only_if默认在执行期运算，可以获取最新的系统状态，也支持通过参数调整判定时机，适配更多场景。
• 副作用差异：如果资源块内写了编译期执行的自定义逻辑，后缀if条件不成立时这些逻辑完全不会运行；only_if模式下这些逻辑无论条件是否成立都会在编译期执行，可能产生预期外的副作用。

官方推荐only_if的原因 #

Chef本身是声明式配置管理工具，only_if作为资源原生能力，完全适配Chef的资源依赖、通知、上报等核心机制，符合“声明资源期望状态+执行前提”的设计思路，能避免大部分因编译/执行阶段混淆产生的坑。而后缀if是命令式的Ruby流程控制，要求使用者非常熟悉Chef的两阶段运行模型，新手使用很容易出现逻辑错误，比如用编译期条件判断执行期才会生成的文件/状态，导致资源完全不加载。

典型踩坑场景：用后缀if判断某配置文件存在才定义服务资源，但该配置文件是前序template资源在执行阶段才会创建的——编译期判断时文件还未生成，服务资源根本不会被加载，哪怕后续配置文件正常生成，服务也不会被Chef管理。

内容的提问来源于stack exchange，提问作者Evan R.