C++ lambda 捕获：闭包状态、引用与生命周期
08 lambda 捕获让临时规则贴近调用点
排查线上问题时，你手里有一份日志记录，每条记录带级别和耗时。现在的需求很小：统计耗时超过 50 毫秒的记录，同时把 error 级别的也算上。这个规则依赖两个运行期变量，一个阈值和一个目标级别。如果用普通函数来写，函数签名里只能收到算法递进来的单个元素，阈值和目标级别无处安放，要么写成全局变量，要么把规则改成固定常量，代码立刻变得难看。lambda 允许你把 threshold 和 target 写进方括号，规则本体写在调用点旁边，算法照常接收一段范围和一个可调用对象，两边各管各的事。
本章要回答的核心问题是：为什么很多算法调用里的判断规则适合写成 lambda。答案的核心在于一个事实：lambda 会生成一个闭包对象（closure object），捕获列表决定这个闭包对象从外部拿到什么状态，参数列表决定算法把每个元素怎样交给它。前面几章已经把范围、谓词、查询、转换、删除和数值累计逐个讲了一遍，那些章节里的规则足够轻量，用匿名写法一笔带过就够了。这一章关注的是规则本身：编译器把方括号语法变成了什么结构，几种捕获方式各自付出什么代价，以及什么时候应该放弃 lambda，给规则一个正式的名字。
一个普通函数装不下的规则
std::count_if 拿到一段迭代器范围和一个谓词之后，做的事情非常固定：从 first 走到 last，每到一个位置就解引用一次，把元素交给谓词，谓词返回 true 就把计数器加一。整个过程中，算法给谓词的输入只有一个，就是当前元素。谓词没有机会收到第二个参数，算法也不知道你的业务里还有一个阈值。这就是普通函数在这里走不通的根本原因：函数能携带的全部信息都写在签名里，而签名里唯一的参数位置已经被元素占掉了。
在 lambda 出现之前，工程上有两条常见的绕行路线。第一条是把阈值写成全局变量或静态变量，函数内部去读它。这条路能编译，但共享可变状态会污染所有调用者，多线程环境里要加同步，单元测试之间还会互相干扰，改一处测试数据可能影响另一处的判断结果。第二条是手写一个函数对象类，把阈值存成成员，重载 operator()。这条路语义正确，代价是仪式感十足：为了一个只在一个地方用的条件，你要声明一个类、写构造函数、写调用运算符，再把定义放到离调用点几十行以外的地方，读者看到 count_if 的调用时还得跳回去找这个类才能读懂规则。
因此工程上真正的问题可以讲得很准确：规则需要一点上下文，而这点上下文的生命周期就在当前函数里，出了这个函数谁也不该再碰它。lambda 恰好把这几个要求合在一起——它像局部变量一样就地创建，用完即弃；它像对象一样可以携带数据，数据写在捕获列表里；它像函数一样可以被调用，算法拿到它之后调用方式与调用普通谓词毫无区别。这三条特性对应了闭包对象的三个维度：生命周期、状态和调用约定，后面几节分别展开。
编译器把 lambda 变成一个类
这一节回答的是 lambda 表达式在编译之后变成了什么。lambda 在语法上只有方括号、圆括号和花括号，但它是一个表达式，求值结果是一个对象。编译器看到 lambda 时，会为它生成一个唯一的、没有名字的类，这个类重载了 operator()，lambda 的函数体就成为 operator() 的函数体。捕获列表里的每个变量都会成为这个类的一个数据成员，在 lambda 表达式被求值的那一刻完成初始化。你用 auto 接住 lambda 时，接住的正是这个匿名类型的对象，标准文档里把它的类型称为闭包类型（closure type）。
有几个细节值得记住。第一，每个 lambda 表达式都对应一个独立的闭包类型，哪怕你在两处写下逐字符完全相同的 lambda，它们也是两个不同的类型，不能互相赋值。第二，闭包对象的体积大致等于捕获成员的体积之和，捕获两个 int 的 lambda 很小，捕获一个大容器的 lambda 就很重，复制闭包对象的成本跟着成员走。第三，没有捕获任何变量的 lambda 可以隐式转换成函数指针，因为它没有状态要携带；一旦捕获列表非空，这条转换路径就断了，闭包对象必须带着自己的数据走。
还有一条默认规则容易踩到：lambda 生成的 operator() 默认是 const 成员函数。这意味着按值捕获进来的成员在函数体里是只读的，你不能在 lambda 体里给捕获的副本赋值，除非在参数列表后面加上 mutable 关键字。这个默认设计是有意为之——它鼓励谓词保持纯粹的判断语义。一个每次调用结果都依赖于内部被改写状态的谓词，在 count_if、find_if 这类算法手里容易产生难以预料的行为，因为标准并不保证算法按什么次数和顺序调用谓词，也不保证它只持有一份谓词副本。
把闭包的类模型理解清楚之后，很多看似"灵异"的现象都有了直接解释。同一个 lambda 赋值给两个 auto 变量，行为一致，原因是两个闭包对象类型相同、成员相同，只是两个实例。把 lambda 存进 std::function 之后还能带着捕获的状态到处走，原因是 std::function 内部持有的是整个闭包对象，成员数据跟着对象一起被复制或移动。调试时看到的那串奇怪类型名——一长串编译器生成的标识符——那正是匿名闭包类型在符号表里的真实长相。lambda 没有任何运行时魔法，它把"定义一个带成员的小类并立即实例化"这件繁琐的事压缩成了一行表达式。
按值捕获把状态拷进闭包
按值捕获的语义是这样的：在 lambda 表达式被求值的那个时间点，把外部变量的值复制一份，存进闭包对象的成员里。这里的关键是时间点——复制发生在定义 lambda 的那一行，不是在每次调用它的时候。定义之后再修改外部变量，闭包里的副本不会跟着变；反过来，闭包对象被复制给算法、被移动、被临时存放，它的副本始终完好，因为它与外界没有牵连。这种自包含的特性让按值捕获成为默认首选：闭包对象的行为可以完全从它自身的定义推导出来，不依赖任何外部对象是否还活着。
代价同样直接——捕获什么就复制什么。捕获一个 int 阈值几乎免费，捕获一个 std::string 就要付出一次字符串复制，捕获一个装满配置的大对象就要认真想想值不值。工程上的做法很朴素：小而便宜的配置项，比如阈值、开关、短名字，按值捕获；体积大的对象，如果只需要读，考虑按引用捕获并确认生命周期，或者干脆把需要的字段提前提取成小变量再按值捕获。C++14 补上了初始化捕获（init capture）的写法，可以写成 [p = std::move(p)] 这样的形式，把只能移动的资源转移进闭包，这进一步印证了捕获列表就是成员初始化列表这个模型：你写什么，闭包里就长什么。
按值捕获和 mutable 配合时还有一个细节值得想清楚。加上 mutable 之后，你可以在函数体里修改捕获的副本，比如给谓词加一个内部计数器，统计它被调用了多少次。修改只落在闭包对象自己的成员上，外部的原始变量不受影响。但这里有个容易踩的坑：算法内部如果复制了谓词，计数也会跟着副本走，你在调用点持有的那份闭包未必看到完整的次数。这类"带内部状态的谓词"在标准算法手里的行为容易和直觉打架，工程上的稳妥做法是让谓词保持纯粹，把统计和副作用挪到按引用捕获的外部变量上，或者写成显式的函数对象，把状态暴露在成员声明里。
按引用捕获以零拷贝换生命周期义务
按引用捕获在闭包里存的是引用，即对外部对象的一种绑定关系，不发生复制。这个选择带来两个直接效果。一方面，闭包读到的永远是外部变量的当前值，外部改了，下一次调用就看到新值；另一方面，闭包里对外部变量的写操作会穿透到原始对象上。后一个特性有正当用途，比如用 std::for_each 配合 [&total] 把范围内的元素累加到一个外部计数器里，遍历结束后 total 里就是总和，这是前几章已经见过的写法。
这种零拷贝的代价是一条硬性义务：外部对象必须活得比闭包对象的每一次使用都久。在典型场景里，lambda 定义好，同一行就交给算法，算法在这段范围上同步执行完毕，外部变量还在当前栈帧上活得好好的，义务自动满足。风险出现在闭包对象被带走的时候：被存进成员变量、被塞进任务队列、被注册成回调、被 return 给上层调用者。只要闭包的使用时刻可能晚于外部变量的销毁时刻，按引用捕获就制造了悬空引用。判断这件事没有语法层面的护栏，全靠你盯着生命周期，这也是为什么审查 lambda 时第一眼看的就是捕获列表。
算法通过参数列表把元素交进来
捕获列表管状态，参数列表管数据流，两条通道互不干扰。算法遍历范围时，每到一个位置就解引用迭代器，把得到的元素交给谓词的参数。本章示例里参数写成 const LogLine& line，这意味着每条日志记录以常量引用的方式进入规则，不发生复制，也不允许规则修改记录内容。如果参数类型写成按值传递，每条记录都会复制一份进来，范围大的时候这笔开销会很明显；如果参数类型与元素类型对不上，编译会在模板实例化深处报错，错误信息往往又臭又长，但根子通常就是参数声明和容器元素类型不匹配。
标准库的设计在这里体现得很干净：算法从头到尾不知道闭包里捕获了什么，它只认一个调用约定——传入一个元素，拿回一个布尔值。规则需要的外部上下文全部由捕获列表在算法视野之外解决。以前要塞进函数签名或全局状态的上下文，现在安静地待在闭包对象的成员里，算法的接口因此保持住了它的通用性。
参数列表这一侧还有几个实用细节。参数类型写成 const auto& 可以让同一个 lambda 适配多种元素类型，写成具体类型则换来编译器更早的类型检查和更清晰的接口提示。函数体里可以有任意多条语句，声明中间变量、提前返回、组合多个条件都没问题，但一旦需要好几行逻辑才能说清判断，就该考虑这个规则是否已经复杂到值得一个名字。返回类型默认由 return 语句推导，多个返回路径推导出不一致类型时才需要显式写尾置返回类型，日常谓词几乎用不到。调用频率也值得留意：count_if 对每个元素调用一次谓词，sort 的比较器会被调用大约 O(n log n) 次，谓词函数体保持轻量、避免在每次调用里做重复的重活，收益会直接体现在整条数据处理链上。
代码示例
本章的示例文件是 代码示例/08-lambda-capture/lambda_capture.cc，它把"耗时超阈值或级别为 error"这条过滤规则写成一个按值捕获的 lambda，交给 std::count_if 去数日志记录。
// Copyright (c) 2026 yus3nable
// SPDX-License-Identifier: MIT
#include <algorithm>
#include <iostream>
#include <string>
#include <vector>
struct LogLine {
std::string level;
int cost_ms = 0;
};
int main() {
const std::vector<LogLine> logs{
{"info", 12}, {"warn", 45}, {"error", 180}, {"info", 75}};
int threshold = 50;
const std::string target = "error";
// 捕获列表按值拷入 threshold 和 target，参数接收算法递来的单条记录
const auto slow_or_error = [threshold, target](const LogLine& line) {
return line.cost_ms >= threshold || line.level == target;
};
const int matched = static_cast<int>(
std::count_if(logs.begin(), logs.end(), slow_or_error));
std::cout << "matched: " << matched << '\n'; // 输出 matched: 2
}
这段代码的结构可以按三层来读。最外层是数据，LogLine 是一个只有级别和耗时两个字段的小结构体，logs 里放着四条记录，级别分别是 info、warn、error、info，耗时分别是 12、45、180、75 毫秒。中间一层是规则需要的上下文，threshold 是 50 毫秒的阈值，target 是目标级别字符串，它们都是 main 函数里的局部变量，出了这个函数谁也不该见到。最内层是规则本体，lambda 的捕获列表把这两个局部变量按值拷进闭包，函数体用一条表达式完成判断：耗时达到阈值，或者级别等于目标，满足任意一条就算命中。
执行路径同样值得走一遍。std::count_if 从 logs.begin() 走到 logs.end()，每到一个位置就把那条 LogLine 以常量引用的形式交给 slow_or_error。第一条 info、12 毫秒，两个条件都不成立，不计数；第二条 warn、45 毫秒，也没到阈值，不计数；第三条 error、180 毫秒，两个条件同时成立，计一次；第四条 info、75 毫秒，耗时越线，再计一次。最终输出是 matched: 2。整个过程中算法对捕获列表一无所知，它反复执行"传元素、收布尔值"这一个动作，闭包对象自己带着阈值和目标级别走完全程。
这个例子还揭示了一个容易形成错误直觉的语义点：按值捕获的副本不会跟踪外部变量的后续变化。这个误判之所以常见，是因为在按引用捕获时，闭包确实始终读到外部变量的最新值，两种捕获方式在脑中容易混淆。具体到这段代码，如果在 lambda 定义之后、count_if 调用之前把 threshold 改成 100，闭包里的副本仍然是 50，输出不会变。想让规则跟着最新值走，就得把 threshold 改成按引用捕获，同时接受生命周期义务。另外这里捕获 target 付了一次 std::string 复制的成本，对于只有四条记录的 demo 无所谓，但如果这段代码出现在每条请求都执行的热路径上，就值得评估一下是否改用 std::string_view 或按引用捕获。小例子里的每个选择，放大到真实流量上都会变成可见的成本。
默认捕获和悬空引用的边界
这一节讨论两个问题：默认捕获 [=] 和 [&] 的隐性代价，以及按引用捕获在闭包被带走时引发的悬空访问。
lambda 提供了两种偷懒写法：[=] 表示把函数体里用到的外部变量全部按值捕获，[&] 表示全部按引用捕获。短小的就地 lambda 用它们没有问题，但这两个符号把闭包的成员列表藏了起来，读者要从函数体反推闭包到底依赖了什么。[=] 的风险是静默复制——函数体里随手用了一个大对象，闭包就悄悄复制了一份，代码评审时很难发现。[&] 的风险更尖锐——函数体里用到的任何局部变量都被绑进闭包，闭包一旦被带走，所有被引用对象的生命周期都要重新审计。捕获列表写窄一点，等于把规则对象的依赖关系写在明处，这个习惯在团队协作里很值钱。
悬空引用是按引用捕获最严重的事故形态。一个函数里定义了局部变量，lambda 按引用捕获了它，然后这个 lambda 被 return 出去、被存进类的成员、被交给异步任务。函数返回后栈帧销毁，局部对象的生命周期结束，闭包里那份绑定关系指向的内存不再属于任何有效对象。之后每次调用这个 lambda，读写都落在已销毁对象的旧址上，行为属于未定义行为（UB）。这种错误的阴险之处在于代码能编译，短期内甚至能跑出正确结果——因为原栈空间可能还没被覆盖——直到某次调用栈变化或优化选项调整，问题才以完全无关的症状暴露出来。
防御方法分两步。写代码时，先问这个闭包对象会不会离开当前作用域：如果它只在同一条语句里交给同步执行的算法，引用捕获是安全的；一旦要存储、返回、异步执行，就逐项检查每个被引用对象能不能活到闭包最后一次使用之后，答不上来就改成按值捕获或者转移所有权。审查代码时，把捕获列表当作闭包类的成员声明来读，[&] 开头的 lambda 一律追问它会被存到哪里、被调用到什么时候。这两步都不依赖工具，靠的是把"闭包是对象，捕获是成员"这个模型用在每一次判断上。
还有一个和成员函数相关的特殊情况。在类的成员函数里写 lambda 时，捕获 this 捕获的是指针本身，按值捕获 this 复制的也只是指针值，对象本体没有跟着进闭包。一个容易产生的错觉是"按值捕获了 this，对象就安全了"，毕竟按值捕获通常意味着复制一份独立的副本；但 this 是指针，独立的副本只是指针值的副本，指向的对象仍然是原来那一个。如果持有这个 lambda 的回调在对象销毁之后才触发，通过 this 访问成员同样是悬空访问，事故形态和引用捕获局部变量一模一样。C++17 补了 [*this] 的写法，可以把整个对象按值复制进闭包，代价是一次完整拷贝，适用面限于小而值语义清晰的对象。原则不变：先确定闭包活得有多久，再决定它应该以什么方式持有外部状态。
泛型 lambda 能走多远
C++14 允许把 lambda 的参数写成 auto，例如 [](const auto& item) { return item.valid(); }。这样的 lambda 生成的 operator() 是一个成员模板，编译器按照实际传入的元素类型实例化，同一个 lambda 可以服务多种元素类型的容器。它特别适合结构性访问——只关心元素有某个字段、能调用某个方法、能做某种比较的场景，规则本身与具体类型解耦，配合第 02 章讲过的迭代器能力模型，可以写出适配面很宽的调用点代码。
泛型 lambda 的边界也很清楚。它没有名字，类型由编译器生成，你没法在接口文档里写出它的类型，也没法在两个翻译单元之间共享它，除非把它放进头文件里让每个包含者各自实例化。函数体一旦复杂起来，多层条件、外部状态、隐式修改搅在一起，匿名语法就没有地方安放注释和中间变量的名字，可读性会快速下降。经验法则很朴素：能在调用点一眼读懂的短规则，无论普通 lambda 还是泛型 lambda 都合适；规则需要解释、需要单独测试、需要在多个调用点复用时，就该给它一个名字，让它出现在接口声明和文档里。
泛型 lambda 和标准库算法的配合还有一层性能含义。count_if 这类算法以模板参数的形式接收谓词，闭包类型在编译期完全可见，operator() 通常能被直接内联进算法的循环体，一次谓词调用和手写循环里的一个 if 判断成本相当。这条内联路径成立的前提是类型在编译期确定；一旦把 lambda 先塞进 std::function 再传给接口，调用就要多走一层类型擦除（type erasure）带来的间接跳转，闭包对象还可能涉及堆上分配。关于 std::function 的取舍，本系列后面有专门一章讨论，这里先记住结论：就地传给模板算法的 lambda 几乎没有抽象成本，被类型擦除包装过的可调用对象才有间接开销，两者不要凭感觉混用。
从临时规则到可复用组件
判断一条规则应该写成 lambda 还是具名类型，可以从三个问题出发。第一，这条规则在几个地方用？只在一处用的短规则，lambda 是最低成本的写法，定义贴着调用点，读者不需要跳转。第二，这条规则需要携带多少状态，状态活多久？少量小而便宜的上下文，按值捕获干净利落；状态变多、需要缓存中间结果、需要在多次调用之间累计信息时，lambda 的匿名形式就开始吃力。第三，这条规则需不需要被测试和文档单独对待？谓词写进 lambda 之后，单元测试只能连着算法一起测；规则一旦成为业务关键逻辑，独立命名和独立测试的价值会超过就地书写的便利。
落到日常代码里，还有几个值得养成的习惯。给 lambda 起名字时用谓词的自然语言描述，比如 slow_or_error 读出来就是判断本身，看到调用点的人不需要再进入函数体。捕获列表逐项写，写不下的情况先问自己为什么这条规则需要那么多上下文——依赖太多往往说明规则该升级成具名类型。函数体里只做判断，日志打印、指标上报、容器修改这类副作用要么明确按引用捕获并写清楚，要么挪出谓词。写完以后用两三个边界样例在脑子里过一遍：空范围返回什么，全部命中和全部不命中时结果对不对，捕获的副本是不是你期望的那个值。这几条习惯加起来花不了一分钟，却能挡掉绝大多数 lambda 相关的线上事故和评审返工。
lambda 解决的是"规则贴近调用点"这个问题，它让谓词、比较器、转换函数有了零仪式的写法，前面章节讲的范围模型因此真正好用了起来，算法调用点附近就能读完整个数据流。但 lambda 的天花板同样明显：没有名字，类型说不出口，状态只活在一次构造里，跨调用点复用要靠拷贝粘贴。当一条规则从临时逻辑长成可复用组件——需要配置项、需要累计统计、需要一个能在文档里指代的名字时——普通对象的能力就接上来了。下一章的函数对象正是沿着这条线展开：一个重载了 operator() 的具名类，既能像函数一样被算法调用，又能像普通成员变量一样把状态长期带在身上。"闭包是对象，捕获是成员"这个模型，也是理解一切可调用对象的基础。
阅读导航
