今日学习：Lambda 表达式与函数式编程

Lambda 表达式是 C++11 引入的匿名函数对象语法糖：[捕获列表](参数列表) { 函数体 }。它让"一段行为"可以像值一样被创建、拷贝、传递和存储——这是函数式编程在 C++ 中的落地形态。

为什么今天学它？第一，它是 STL 算法（std::sort、std::find_if）、Qt6 信号槽、std::async 并发的共同基石，不理解 lambda 就几乎无法写现代 C++。第二，对 Web 开发者来说它是迁移成本最低的概念——你天天写箭头函数，但 C++ 的捕获语义、生命周期责任和 JS 闭包有本质差异，这个差异正是 C++ 新人事故率最高的来源之一。第三，它和前两篇一脉相承：lambda 捕获变量本质上是所有权问题，正好复习 RAII 与移动语义。

一句话说清 lambda：编译器把 lambda 展开成一个匿名的"函数对象"类（闭包类型），捕获列表变成它的成员变量，函数体变成它的 operator()。它不是一个运行时魔法，而是编译期的语法糖——零抽象成本。

1. Lambda 的本质：匿名函数对象

看这段代码：

auto add = [x](int a) { return a + x; };

编译器会生成一个等价于下面的类：

struct __lambda_1 {
    int x;                              // 捕获的变量变成成员
    auto operator()(int a) const { return a + x; }  // 函数体变成 operator()
};

关键洞察有三点：① 每个 lambda 都有唯一的、编译器生成的类型（闭包类型），所以 lambda 和函数指针不同，它是有状态的可调用对象；② 因为是具体类型，编译器可以完全内联，零运行时开销；③ 捕获列表就是"把哪些外部变量放进这个对象里"的声明——这就是闭包（closure）。

2. 捕获语义：显式声明依赖

捕获列表是 lambda 与 JS 箭头函数最大的语法差异。C++ 要求你显式声明要捕获哪些变量、按什么方式捕获：

// 按值捕获：创建时拷贝一份到闭包对象里
[int x]            // 捕获 x 的副本（C++14 起可写 [x]）
[=]               // 全部按值捕获（默认捕获）

// 按引用捕获：不拷贝，闭包持有引用
[&x]              // 捕获 x 的引用
[&]               // 全部按引用捕获

// 成员函数内：捕获 this 指针（访问成员变量）
[this]             // 捕获 this 指针本身（C++17 起 [=, this] 亦可）
[*this]             // C++17：按值捕获当前对象的副本

// C++14 init-capture：捕获时做表达式（如移动）
[ptr = std::move(ptr)]   // 把 ptr 移动进闭包

三条铁律：按值捕获发生在 lambda 创建的那一刻（拷贝当时的快照）；按引用捕获不拷贝，但被引用对象必须活得比 lambda 久；默认捕获 [=] 在成员函数里捕获的是 this 指针，不是成员变量的副本——这是最容易踩的坑。

3. C++14 / 17 / 20 的演进

• C++14：泛型 lambda（参数用 auto，相当于模板）；init-capture（[x = expr]）；返回类型自动推导。
• C++17：constexpr lambda（满足条件的 lambda 可用于编译期计算，如模板参数）；[*this] 按值捕获当前对象；[=, this] 显式捕获 this。
• C++20：模板 lambda（[]<typename T>(T v){}，可显式命名模板参数）；无状态 lambda 可默认构造与赋值；lambda 可用于未求值上下文（如 decltype([] {})）。

4. Lambda vs std::function：零开销 vs 类型擦除

这是性能上最重要的一个区分。lambda 有具体类型，直接调用可以内联；而 std::function 把任意可调用对象类型擦除成一个统一类型：

// ✅ 模板参数：零开销，可内联（推荐）
template<typename F>
void for_each(F&& f) { f(1); }   // f 是具体类型，编译器可内联

// ⚠ std::function：类型擦除，间接调用 + 可能的堆分配
std::function<void(int)> f = [](int x) { ... };
f(1);  // 经过虚函数/函数指针的间接调用

std::function 的实现通常有"小对象优化"（小闭包直接放内部缓冲），但大闭包仍会堆分配；调用是间接的，比裸 lambda 慢一个数量级左右。它存在的意义是类型擦除：当你要把回调存进容器、放进队列、跨模块传递时，需要统一的类型。规则是：能模板化就模板化，只有"运行时才知道调用目标"时才用 std::function。

案例1：Qt6 信号槽的 functor 重载

Qt5 起 QObject::connect 支持 lambda 作为槽函数，Qt6 全面拥抱这一写法。这是 lambda 在真实框架中最典型的应用：

// Qt6 推荐的 connect 写法：lambda 槽 + context object
connect(button, &QPushButton::clicked, this, [this] {
    handleClick();                 // 捕获 this 访问成员
});

// 延迟执行：QTimer::singleShot + lambda（事件循环下一轮执行）
QTimer::singleShot(0, this, [this] {
    refreshView();
});

为什么必须传 this 作为第三个参数（context object）？因为 Qt 会监听 context 的析构：当 this 指向的对象销毁时，连接自动断开，lambda 永远不会在悬垂对象上被调用。这相当于把"闭包生命周期"问题交给框架兜底——但前提是你必须传 context。这也是 Qt 与 Node.js EventEmitter 的关键差异：JS 里你必须手动 off()，忘记就泄漏/崩溃。

案例2：Chromium 的 base::BindOnce / RepeatingCallback

Chromium 是超大型 C++ 工程，跨线程回调极其频繁。它不用裸 lambda 跨线程传递，而是封装了 base::OnceCallback（只能调用一次，移动语义，类似"unique_ptr 版回调"）和 base::RepeatingCallback。回调对象的生命周期通过 base::WeakPtr、任务队列等机制严格管理：

// Chromium 风格（示意）：绑定回调 + 弱指针防悬垂
base::BindOnce(&MyClass::OnResult, weak_factory_.GetWeakPtr(), data);
// 回调执行时若对象已销毁，WeakPtr 为空 → 安全跳过

这告诉我们：大型工程里，"回调何时执行、执行时对象是否还活着"是一等公民问题，需要专门的机制（WeakPtr、任务队列、Context）而不是靠程序员自觉。Qt 的 context object 和 Chromium 的 WeakPtr 是同一思想的两套实现。

案例3：STL 算法与 C++20 ranges

// 排序：lambda 作为比较器（等价于 JS 的 sort 回调）
std::sort(items.begin(), items.end(),
      [](const Item& a, const Item& b) { return a.score > b.score; });

// C++20 ranges：管道式组合，接近 JS 的链式调用
auto top = items | std::views::filter([](const Item& i) { return i.valid; })
                | std::views::transform([](const Item& i) { return i.score; });

对比 JS 的 arr.filter(...).map(...)，ranges 管道在思路上完全同构——lambda 就是你的回调。区别在于 C++ 的 lambda 可以是无捕获的（此时可转换为函数指针）、constexpr 的（编译期执行）、零开销的（内联）。

❌ 错误1：引用捕获逃逸作用域（悬垂引用）

这是 Web 开发者转 C++ 后第一个重大事故。JS 闭包引用外部变量永远不会失效（GC 保证），于是新人习惯性写 [&]，然后把 lambda 返回/存储到更外层：

// ❌ 悬垂引用：local 在 makeDangling 返回时已销毁
std::function<void()> makeDangling() {
    int local = 42;
    return [&] { std::cout << local; };  // UB！local 已死
}

用 AddressSanitizer 编译运行，会立即报 stack-use-after-return（今日实践任务里你会亲手复现）。解决：按值捕获（[local]）或按值捕获 shared_ptr 延长生命周期。

❌ 错误2：Qt 里捕获 this 但对象已销毁

// ❌ 没传 context object：dialog 销毁后 lambda 仍可能被调用 → 崩溃
connect(button, &QPushButton::clicked, [this] { useDialog(); });

// ✅ 传 context：对象析构时连接自动断开
connect(button, &QPushButton::clicked, this, [this] { useDialog(); });

还有更隐蔽的：[=] 在成员函数里捕获的是 this 指针，不是成员变量的副本。对象销毁后，闭包里的 this 就是悬垂指针。

❌ 错误3：滥用 std::function

把所有回调都声明成 std::function，热路径上每次调用都有类型擦除开销（间接调用 + 可能的堆分配）。对性能敏感的代码（渲染循环、每帧回调、高频事件），应该用模板或 auto 参数保留具体类型。

❌ 错误4：误用 mutable 与共享捕获

按值捕获的变量在 operator() 里默认是 const，想修改副本必须加 mutable（[x]() mutable { x++; }）。另外，lambda 捕获 shared_ptr 会延长其生命周期——这既是特性也是坑：如果 lambda 被长期存储（如全局回调表），它持有的 shared_ptr 会让对象"永远活着"，造成内存泄漏；跨线程共享捕获变量更是数据竞争，需要 std::mutex 或原子操作。

Trade-off 分析

显式捕获 vs 默认捕获（[=]/[&]）：

• ✅ 显式捕获让"闭包依赖什么"一目了然，review 时可审计
• ✅ 默认捕获隐藏依赖，[&] 更是悬垂引用的温床
• ❌ 显式捕获在变量多时冗长——但这是值得付的代价

模板 vs std::function：

• ✅ 模板零开销、可内联；std::function 统一类型、可存储
• ❌ 模板会导致代码膨胀（每种 lambda 类型实例化一份）；std::function 有间接调用和潜在堆分配

铁律：lambda 只在"创建它的作用域内使用"时，按引用捕获才安全。一旦 lambda 可能逃逸（存储、返回、跨线程），一律按值捕获或转移所有权。这条规则能避免 90% 的 lambda 事故。

箭头函数 vs lambda：同一个概念，不同的责任划分

JS 的箭头函数（以及普通 function）是词法闭包：自动捕获所有外层变量，变量引用存在堆上的环境记录里，由 GC 管理。你从不需要声明"捕获列表"，也永远不会遇到悬垂引用——因为 JS 的闭包变量永远活在堆上。

C++ 的 lambda 需要显式捕获列表，因为栈变量销毁是确定性的——一旦逃逸就是 UB。这看起来是"麻烦"，其实是把安全责任从运行时（GC）转移给了编译期（你）：代价是你要思考生命周期，收益是零 GC 开销、确定性析构、可内联的性能。

// React：deps 数组 ≈ C++ 的捕获列表
const cb = useCallback(() => doSomething(x), [x]);  // 声明依赖 x

// C++：捕获列表同样在"声明依赖"
auto cb = [x] { doSomething(x); };

类比映射表

迁移心法：把"箭头函数"换成"lambda + 捕获列表"，把"GC 兜底"换成"生命周期自担"。你在 JS 里为防泄漏手动写的 off()、removeEventListener、clearInterval，正是 C++ 程序员每天要思考的闭包生命周期问题——只是 C++ 把它前置到了编译期，代价更高，回报也更高。

lambda 看似语法细节，实则是团队代码质量的分水岭。回调是组件解耦的枢纽，而"回调的生命周期约定"就是组件边界契约。作为 Team Leader，你要在三个层面发力：

🔍 如何 Code Review

• 查捕获列表：看到默认捕获 [&] 或 [=]，问一句"这个 lambda 会逃逸吗？"——默认捕获隐藏依赖，是 review 的红线。
• 查 Qt connect：凡是 connect 没传 context object（第三个参数）的，一律打回。这是 Qt 崩溃的头号来源。
• 查 std::function：热路径/高频调用处滥用 std::function 要指出；确认它出现在"需要类型擦除"的边界（队列、插件接口、跨模块回调）。
• 查捕获 this 的长期存储：lambda 被存进全局/静态容器且捕获了 this 或 shared_ptr，等于人为制造生命周期泄漏。

📋 制定规范

• 团队规范明确：禁止裸 [&] 默认捕获（除非 lambda 明确不逃逸且在同一函数内立即调用）；推荐显式捕获列表。
• 回调边界统一：跨线程、跨模块回调必须带生命周期担保——Qt 用 context object，自研框架用 weak_ptr/连接令牌（connection token）。
• 约定 std::function 只在"公共接口/存储边界"使用，内部实现用模板或 auto。

👥 如何培养新人

• Web 转 C++ 的新人第一次重大事故几乎都是悬垂引用。安排一次"闭包生命周期"小课：用 ASan 复现 stack-use-after-return，再对比 JS 闭包为什么不会——一次演示胜过十次说教。
• 让新人用 lambda 重写旧的函数指针/回调代码，review 捕获列表的正确性，把"生命周期思考"练成肌肉记忆。
• 引导新人阅读 Qt 的 connect 文档中 context object 一节，理解框架如何替你兜底——以及为什么你不能依赖兜底。

• 《Effective Modern C++》Item 31–34 — Scott Meyers：lambda 的默认捕获模式、std::bind 与 lambda 的取舍、泛型 lambda、lambda 与 std::function 的性能差异。推荐理由：每一节都是可以直接落地的规则。
• 《C++ Primer》第5版 第10章 — 泛型算法与 lambda 的完整入门，配合大量练习。推荐理由：从零开始，Web 背景读者友好。
• cppreference.com: Lambda expressions — en.cppreference.com/w/cpp/language/lambda。最权威的语言规范参考，含 C++20 模板 lambda 与未求值上下文。
• C++ Core Guidelines: F.50–F.52 — isocpp.github.io/CppCoreGuidelines。关于"何时用 lambda、何时用函数/函数对象"的官方共识。
• Qt 官方文档：Signals & Slots — doc.qt.io/qt-6/signalsandslots.html。functor 重载 connect 的完整说明，重点读"带 context object 的重载"。推荐理由：理解 Qt 如何把闭包生命周期问题框架化。
• "Back to Basics: Lambdas" (CppCon) — 视频讲座，深入闭包类型与捕获的内部实现。推荐理由：把"语法糖展开"讲得极透彻。