为何在R语言中更推荐使用enquo+!!而非substitute+eval？

作为经常和R语言元编程打交道的开发者，我太懂为什么不少base R老玩家会觉得substitute()+eval更直观——毕竟是原生工具，不用额外依赖。但其实enquo()+!!（rlang包的核心工具，也是tidyverse生态的标准范式）在可靠性、兼容性和可维护性上都更胜一筹，咱们一步步拆解。

核心优势：准引用的上下文感知能力 #

enquo()属于**准引用（quasiquotation）**工具链，它和substitute()最大的区别在于：

• enquo()不仅捕获传入的表达式字面内容，还会自动绑定表达式所在的原始上下文环境。
• substitute()仅捕获表达式的字面形式，完全丢失了环境信息，后续用eval时很容易出现找不到变量的问题。

举个实际的坑：如果在函数外部定义变量再传入，substitute()+eval直接失效：

val <- 10
test_f1 <- function(data, var) {
  m <- enquo(var)
  data %>% mutate(new = !!m * 2)
}
test_f2 <- function(data, var) {
  m <- substitute(var)
  data %>% mutate(new = eval(m) * 2)
}
d %>% test_f1(val) # 正常运行，enquo保留了val的全局环境上下文
d %>% test_f2(val) # 报错！eval在mutate的数据集环境里找不到val

要让f2正常工作，你得手动写eval(m, envir = parent.frame())，这不仅增加了代码复杂度，后续嵌套调用时还会出更多问题。

结合你的示例：为什么选f1而非f2？ #

表面上两个函数都能生成正确的two_y列，但藏着不少隐性问题：

• 嵌套调用的稳定性：如果把f2放到另一个函数里调用，立刻失效：

  wrapper <- function(data, var) {
    f2(data, var)
  }
  d %>% wrapper(y) # substitute捕获的是`var`而非`y`，eval找不到var
  

  而f1用enquo()会自动沿着调用栈追踪表达式的原始来源，完全不会有这个问题。
• tidyverse生态兼容性：enquo()+!!是dplyr、ggplot2等包的原生元编程语法，和其他功能无缝衔接。比如你要在ggplot里动态指定x轴：

  plot_func <- function(data, x_var) {
    x <- enquo(x_var)
    ggplot(data, aes(x = !!x, y = y)) + geom_point()
  }
  plot_func(d, x) # 直接生效
  

  换成substitute()+eval的话，你得手动调整eval的环境，代码会变得非常别扭。
• 代码可读性：enquo()明确表示“我要捕获这个参数的表达式和上下文”，!!明确表示“把捕获的表达式插入到这里”，逻辑清晰。而substitute()+eval的环境处理逻辑非常隐晦，新人看代码要花大量时间理清eval到底在哪个环境执行。

效率差异：日常场景可忽略，复杂场景enquo()更优 #

在简单的单函数调用场景下，两者的效率差异几乎感受不到。但在复杂的元编程场景（比如大量嵌套函数、循环调用动态参数），enquo()+!!的表现会更好：

• enquo()在捕获表达式时已经绑定了正确的环境，后续的!!只是做表达式拼接，不需要额外的环境查找。
• eval()每次调用都需要解析环境，尤其是手动指定envir参数时，会产生额外的开销。
  不过对于大多数日常业务代码来说，这点效率差异远不如代码的可靠性重要。

给base R开发者的小建议 #

我完全理解substitute()+eval的直观性——毕竟是base包原生工具，不用额外依赖rlang。但如果你经常写tidyverse风格的函数，尤其是需要处理动态参数的场景，建议慢慢转向enquo()+!!：

• 它能帮你避开很多环境相关的诡异bug，这些bug往往很难调试。
• 随着tidyverse生态的普及，准引用语法会越来越成为团队协作的标准，代码风格更统一。

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