为何C++不允许在非静态环境的Lambda中使用非静态数据成员作默认参数？

先看你给出的代码：

struct A {
    int m_i;
    
    void f() const;
};

void A::f() const
{
    auto l = [&](int x = m_i) { };
}

int main()
{
    A a{1};
}

这段代码编译失败，核心原因不是Lambda不能访问m_i，而是Lambda生成的闭包类的operator()函数，不能把非静态成员作为默认参数，深层缘由可以从这几个角度理解：

1. 默认参数的本质是函数的静态属性 #

C++里，默认参数是和函数签名绑定的静态规则，不属于任何对象实例。哪怕是类的非静态成员函数，它的默认参数也不能直接引用非静态成员——因为默认参数是在函数层面定义的，调用时不需要依赖某个具体实例就能确定默认值的来源（成员函数调用时必须有实例，但默认参数表达式本身不能直接绑定到实例的非静态成员）。

Lambda本质是编译器自动生成的匿名闭包类，它的operator()就是这个类的非静态成员函数，自然要遵循普通成员函数的默认参数规则：不能用非静态成员作为默认参数，因为默认参数表达式无法在函数签名层面和具体实例绑定。

2. Lambda捕获与默认参数的求值逻辑冲突 #

Lambda捕获this（或通过[&]隐式捕获this）是为了在调用时能访问当前对象的成员，但默认参数的求值时机是调用operator()的时候，而非Lambda定义时。如果允许用m_i作默认参数，相当于要求编译器在调用时通过this->m_i获取值，但默认参数的规则要求表达式必须能在函数定义的作用域中被解析，且不依赖于调用时的动态上下文（比如当前的this指向）。这种冲突会导致编译器无法在解析Lambda的operator()签名时，确定默认参数的合法性。

3. 避免潜在的生命周期风险 #

假设允许这么写，当Lambda被拷贝到f()函数作用域外调用时，this指向的A对象可能已经被销毁，此时默认参数m_i的求值就会触发未定义行为。默认参数的设计初衷是提供稳定、安全的默认值，允许依赖实例的非静态成员作默认参数，会引入难以察觉的生命周期隐患，违背了默认参数的设计原则。

4. 保持语言规则的一致性 #

如果单独给Lambda开特例，允许它用非静态成员作默认参数，会破坏C++中成员函数默认参数的统一规则，增加开发者的理解成本——比如容易混淆Lambda捕获和默认参数的作用逻辑，也会让编译器的实现复杂度大幅提升（需要为Lambda的operator()单独处理默认参数与this的绑定逻辑）。

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