R语言list2env()显式传参与默认parent参数行为差异问题咨询

一、你的问题分析完全准确 #

你观察到的行为差异是真实存在的，对根源的定位也没有偏差。这一现象本质是R语言形参惰性求值的固有规则导致的，和list2env本身的代码实现没有逻辑冲突：

• R对两类参数表达式的求值边界有明确区分：
  • 当参数使用函数定义时的默认值时，表达式会在list2env自身的运行帧内部、真正需要取值的时刻才完成求值。此时list2env内部运行parent.frame()，拿到的是调用list2env的上游函数的运行环境，也就是你测试里f1的函数帧，这也是为什么默认参数场景下，新建环境的父链上会包含f1对应的专属环境层。
  • 当你在f2的函数体内显式写出parent = parent.frame()传给list2env时，这个表达式不会被原封不动传到list2env内部再求值，而是在f2的运行上下文里就提前算完了。此时在f2的帧里执行parent.frame()，拿到的是f2的上游环境（也就是全局环境），你传给list2env的已经是求值完成的环境对象，而非待执行的表达式，最终父链自然跳过了f2本身的环境层。
• 你写的修复版函数逻辑完全成立：通过substitute()把传入的parent表达式截获下来，在list2env_fixed的内部环境、创建新环境的正确时机再求值，本质是把显式传参和默认参数的求值上下文做了统一，所以测试结果和默认参数场景的行为完全对齐。

二、这不属于R语言的bug，无需向官方提交报告 #

从设计规范层面，这一行为完全符合R语言的官方定义，不存在需要修正的缺陷：

• R从语言设计之初就明确了两类参数表达式的求值规则：显式传入的表达式在调用点的上下文求值，默认值表达式在目标函数的运行帧内求值。这套规则是实现惰性求值、闭包语义、动态调用栈追踪的核心基础，parent.frame()、match.call()、ls()这类依赖调用栈动态行为的基础函数，都建立在这套规则之上。
• 大家容易觉得行为“反常”，本质是惯性认知偏差：绝大多数常规参数（比如数值计算、字符串拼接）在显式传参和用默认值时结果完全一致，所以会形成“字符串完全相同的表达式，不管放在哪个位置写，结果都一样”的思维惯性。但parent.frame()是高度依赖栈帧位置的特殊函数，一旦表达式从目标函数内部移动到调用点，求值时看到的栈帧就会变化，结果自然和原场景不同。
• 你提到的“灵活调整parent.frame()的n参数定位目标调用环境”的需求，原list2env的默认参数逻辑已经完全支持：只要不手动覆盖parent参数，list2env内部的parent.frame()会自动追踪正确的调用层级，不需要做任何修改。如果显式传参时希望复现默认参数的行为，只需要在调用点调整parent.frame()的n值，匹配对应栈帧即可。
• 你实现的统一延迟求值逻辑，属于提升开发体验的优化，而非bug修复。这类处理在很多上层包的函数实现中非常常见，但base R的原list2env实现完全符合语言规范，不存在逻辑漏洞，也不需要附带补丁调整。

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