std::copy_if未复制元素的主因是目标迭代器未预留空间或非插入型；正确做法为用std::back_inserter或预调resize；lambda捕获需注意生命周期；链表宜用原地remove_if；C++20推荐std::ranges::copy_if。
std::copy_if 为什么没把元素复制过去
常见现象是调用 std::copy_if 后目标容器空空如也，或者只复制了部分——根本原因是目标迭代器没预留空间或不是插入型迭代器。std::copy_if 不会自动扩容，它只是“逐个赋值”，如果目标是 std::vector 且用 vec.begin() 作输出，而 vec.size() < 预期结果数量，就会写到未初始化内存甚至越界。
- 正确做法：用
std::back_inserter(vec)（适用于需要动态追加的场景） - 若已知上限且追求性能，先
vec.resize(n)，再用vec.begin()，但必须确保n≥ 实际匹配数，否则多余位置会被默认构造值填充 - 别对空
std::array或栈数组裸用std::copy_if输出——它们没有back_inserter，得自己算好边界
lambda 捕获外部变量时 std::copy_if 编译失败
错误常表现为 “no match for call” 或 “cannot bind ‘this’ in lambda”，本质是捕获方式与谓词对象生命周期不匹配。比如在函数内定义局部 std::vector<int> filter_vals = {1,3,5};，然后传 [&filter_vals](int x){ return filter_vals.count(x); } 给 std::copy_if ——这没问题；但如果把 lambda 存进 std::function 再传入，就可能因引用悬空崩溃。
- 安全优先：用值捕获
[=]或显式值捕获[filter_vals]，尤其当 lambda 可能脱离当前作用域存活 - 性能敏感时才用引用捕获
[&]，且必须确保被捕获对象的生命周期长于std::copy_if调用本身 - 避免混合捕获
[&, filter_vals]：C++14 起允许，但可读性差，容易误判哪个变量是引用、哪个是值
用 std::copy_if 处理 std::list 或 std::forward_list 效率低
虽然语法上完全可行，但 std::copy_if 对链表类容器输出到另一个链表时，若用 std::back_inserter，每次插入都是 O(1)，总体 O(n)；但若目标是 std::vector，又得反复 realloc，反而不如直接用容器自身的 remove_if + erase 原地过滤（对 std::list 是 O(n) 且无移动开销）。
- 原地过滤更合适：
lst.remove_if([](int x){ return x % 2 == 0; });—— 不分配新内存，不复制元素 - 必须保留原容器？那
std::copy_if没问题，但目标选std::vector前先reserve，选std::list就用std::back_inserter -
std::forward_list没有push_back，只能用std::front_inserter，结果顺序会反转，得手动 reverse 或改用其他策略
std::copy_if 在 C++17 之后的替代选择
如果你用的是 C++20，std::ranges::copy_if 更直观：支持直接传容器、自动推导迭代器、无需手写 begin/end，而且配合视图（view）还能惰性求值。但注意它不改变原容器，和老版语义一致。
立即学习“C++免费学习笔记（深入）”；
- C++20 示例：
std::ranges::copy_if(src, std::back_inserter(dst), [](int x){ return x > 0; }); - 兼容旧代码？别直接换，因为
std::ranges版本要求输入为范围（range），老式原始指针数组需包一层std::span或用传统接口 - 真正省事的场景是管道式过滤：
auto positive = src | std::views::filter([](int x){ return x > 0; }) | std::views::transform(std::abs);—— 但这是 view，不是 copy，要落地还得接std::ranges::copy
最易被忽略的一点：无论用哪个版本，谓词函数里修改输入元素是未定义行为——std::copy_if 只读取，不承诺你不能改，但改了可能导致迭代器失效或逻辑错乱，实际中几乎没人这么干，可一旦混进调试代码就很难排查。
