c++oding="utf-8" ?>
std::views::filter 的 lambda 必须值捕获，因视图惰性执行易致悬垂引用；不支持 size()、随机访问及 data()；临时容器参与管道会引发生命周期问题；参数类型需严格匹配或显式转换。
std::views::filter 的 lambda 捕获必须是值捕获
如果你在 std::views::filter 的 lambda 中尝试捕获局部变量的引用（比如 [&x]），编译会失败或行为未定义——因为视图是惰性的，筛选逻辑可能在原作用域结束后才执行。视图对象本身不持有数据，只保存 lambda 的副本，而引用捕获会让 lambda 持有悬垂引用。
实操建议：
- 一律用值捕获：
[x]、[=]或显式列出需复制的变量 - 若需捕获大型对象，优先捕获指针或
std::shared_ptr，避免不必要的拷贝 - 注意 lambda 类型是否可默认构造：若用于模板推导（如管道操作），带引用捕获的 lambda 不满足
std::copy_constructible
filter 后接 to_vector() 或 begin()/end() 时的常见编译错误
直接对 std::views::filter 结果调用 .size() 或用作数组下标会编译失败——它不提供随机访问迭代器，也不保证支持 size()。更隐蔽的问题是：某些容器（如 std::vector）的迭代器类型和 filter 视图的迭代器类型不兼容，导致 std::to_vector() 调用失败（C++23 前需手动包含 <ranges></ranges> 和 <vector></vector>）。
实操建议：
- 需要实际容器时，显式调用
std::ranges::to<:vector>()</:vector>（C++23）或手动构造：std::vector result{filtered.begin(), filtered.end()} - 避免对 filter 视图调用
.data()、.at()、operator[] - 遍历时始终用范围 for 或
for (auto it = filtered.begin(); it != filtered.end(); ++it)，不要假设支持it + n
filter 管道中嵌套 view 导致的生命周期陷阱
写成 v | std::views::filter(p) | std::views::transform(f) 很自然，但若 v 是临时容器（如函数返回的 std::vector），整个管道表达式生成的视图会绑定到该临时对象的生命周期——而 C++ 标准只延长临时对象到完整表达式末尾，不是到视图销毁时。结果就是迭代时访问已析构内存。
实操建议：
- 永远让源容器拥有独立生命周期：把临时容器赋给具名变量再参与视图构造
- 避免
foo() | std::views::filter(...)这类写法，其中foo()返回值是纯右值 - 若必须链式调用，用
std::views::all(v)显式包装左值，或改用std::ranges::filter_view手动管理
lambda 参数类型不匹配引发的隐式转换失败
filter 的 lambda 形参类型必须与视图元素类型严格匹配，或能无损转换。例如源是 std::vector<int></int>，但 lambda 写成 [](long x) { return x > 0; }，某些标准库实现（如 libstdc++）会在编译期拒绝——因为 int 到 long 的转换不被视为“直接绑定”，而 filter_view::iterator 的 operator* 返回的是 const int&，不能隐式转为 long。
实操建议：
- lambda 参数尽量用
auto（[=](auto x)）或精确匹配源类型（int、const T&） - 若需类型转换，显式在 lambda 内部做：
[](int x) { return static_cast<long>(x) > 0; }</long> - 调试时可加
static_assert(std::is_same_v<decltype>::iterator::value_type>), int>)</decltype>验证推导类型
filter 的“惰性”不是免费的——它把计算延迟到迭代那一刻，也把所有生命周期、类型、所有权问题一并推迟暴露。最常被忽略的，是那个你以为还在的临时容器，其实两行代码前就没了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
