std::ranges::for_each并非为副作用操作设计，而是纯函数式接口，仅接受一元可调用对象且不修改原范围；真正需执行副作用（如打印、修改元素）时，应优先选用range-for或std::for_each。
std::ranges::for_each 不能直接用于有副作用的范围操作
它确实存在，但名字有误导性——std::ranges::for_each 是纯函数式接口，只接受一元可调用对象，且不返回迭代器或修改原范围；它不会“遍历并执行副作用”如修改元素、打印、计数等，除非你显式把副作用写进 lambda 里。它的设计目标是与 std::ranges::for_each_n 和算法管道（pipe syntax）配合，而非替代传统 for 循环做 I/O 或状态更新。
真正想“对每个元素执行副作用”，应该用传统 range-for 或 std::for_each
如果你的目标是：打印每个值、修改容器内元素、记录日志、触发回调，std::ranges::for_each 不比下面两种方式更安全或更简洁：
-
for (auto& x : rng) { /* 修改 x 或调用函数 */ }—— 最直观，支持引用/移动语义，无额外开销 -
std::for_each(begin(rng), end(rng), [](auto& x) { /* ... */ })—— C++17 前主流写法，兼容所有迭代器类型 -
std::ranges::for_each(rng, [](auto& x) { /* ... */ })—— 语法稍短，但底层仍等价于上一条，且要求rng满足std::ranges::range，对某些自定义 view 可能意外失败
std::ranges::for_each 的实际适用场景很窄
它真正有用的地方，是作为管道中的一环，配合 | 操作符传递数据流，且副作用被封装为“不可见”的转换逻辑（比如日志埋点 + 继续转发）：
auto logged = rng
| std::views::transform([](int x) { std::cout << "got: " << x << '\n'; return x * 2; })
| std::views::filter([](int x) { return x > 0; });
但注意：std::ranges::for_each 本身不参与这种链式构建；它没有返回 view，不能接 |。强行用它只会中断 pipeline：
立即学习“C++免费学习笔记（深入）”；
- 错误写法：
rng | std::ranges::for_each([](int x){...}) | std::views::filter(...)→ 编译失败，因为for_each返回void - 正确替代：
std::ranges::for_each只能单独成句，无法嵌入视图链
常见错误：误以为它能像 Python 的 map() 那样惰性求值或返回新范围
它既不惰性，也不返回新范围，更不生成副本。典型误用包括：
- 写
auto result = std::ranges::for_each(v, f);→result是void，编译报错 - 传入 const 范围却在 lambda 里试图修改元素 → 编译失败，因推导出的参数类型是
const int& - 对
std::views::iota(0, 10)使用它后，期望能继续迭代 → 实际什么也没产生，原 view 未被消费或缓存
真正需要副作用+组合能力时，优先考虑 std::views::transform + 无副作用纯函数，或拆成两步：先 std::ranges::for_each 做副作用，再另起一个 view 链做变换。
