std::views::chunk_by仅在相邻元素谓词结果翻转处切分，即pred(a,b)与pred(b,c)不同时在b、c间切割；它不按值分组、不分块长度、不比较非相邻元素，且要求谓词无状态、签名正确、底层为forward_range。
直接说结论：std::views::chunk_by 不是“按值分组”，也不是“每 N 个切一刀”，它只在相邻元素对的谓词结果**翻转处**切分——即 pred(a,b) 和 pred(b,c) 返回值不同时，在 b 和 c 之间切一刀。用错场景或写错谓词，结果必然反直觉。
为什么 std::views::chunk_by(std::equal_to{}) 没按你想象分组
常见错误现象：对 {1,2,1,1} 应用 std::equal_to{}，得到 [1], [2], [1,1]，但你以为它该把所有 1 归一块。这不是 bug，是设计使然。
- 它从不比较非相邻元素：第 0 个和第 2 个
1完全无关 - 调用顺序是：
pred(1,2)→ false → 切，pred(2,1)→ false → 再切，pred(1,1)→ true → 不切 - 首元素永远自成一块起点，不参与首次谓词调用
- 若真要“所有相同值归为一组”，得先
std::ranges::sort，再用chunk_by；或等 C++26 的std::views::group_by（尚未标准化）
std::views::chunk_by 谓词必须满足的硬约束
编译失败或运行时未定义行为，90% 出在这里。不是逻辑写错了，而是签名或状态违规了。
- 必须是二元可调用对象，形如
bool(const T&, const T&)；若输入是const std::vector<int>，而谓词写成(int&, int&)，直接编译不过 - 禁止捕获非常量局部变量：
[counter](auto&, auto&) mutable { return ++counter % 2; }→chunk_by_view不可复制 → 后续接| std::views::transform触发use of deleted function - 禁止隐式状态：
static int x、std::rand()、修改外部引用都算 - 安全写法只有三种：
[](const auto& a, const auto& b) { return a.category == b.category; }、[=](int a, int b) { return a / 10 == b / 10; }、或标准函数对象如std::less{}
哪些容器能用，哪些一用就崩
std::views::chunk_by 对底层迭代器要求比 std::views::chunk 高得多——它需要能多次解引用同一位置、甚至回退一个元素做比较。
立即学习“C++免费学习笔记（深入）”；
- 安全类型：
std::vector、std::array、std::string、原生数组、std::span - 危险类型：
std::list和std::forward_list编译失败，报错'The range argument to views::chunk_by must model forward_range'—— 表面看它们满足概念，实则因迭代器失效敏感性被标准库主动拒之门外 - 最隐蔽的坑：把临时
std::vector{1,2,3}直接传入管道，视图内部持有的是悬垂迭代器；必须先绑定具名变量：std::vector data = {1,2,3}; auto v = data | std::views::chunk_by(pred); - 一旦原容器发生重分配（如
vector::push_back），所有已构造的chunk_by_view::iterator立即失效——这点比chunk严格得多
别和 std::views::chunk 混，名字像，行为毫无关系
看到 chunk_by 就想当然写 chunk_by(3)？这是最典型的误用。它的签名根本不接受整数参数。
-
std::views::chunk(3)：按固定长度切，{1,2,3,4,5}→[1,2,3], [4,5] -
std::views::chunk_by：只响应谓词结果翻转，{1,2,3,4,5}配合std::less{}→[1,2,3,4,5]（全程递增，谓词恒 true）；配std::greater{}→[1], [2], [3], [4], [5]（每对都 false） - 想模拟“每 3 个一组”？不能靠
chunk_by。强行用索引状态（如捕获i并取模）会破坏视图可复制性，管道组合直接报废 - 二者语义层完全割裂：一个是位置驱动，一个是相邻关系驱动；混用预期等于自己给自己埋雷
真正难的不是写对 lambda，而是意识到 chunk_by 的切分点永远落在两个元素之间，且只由局部比较决定——它不记忆历史，不预测未来，也不容忍状态。一旦脱离这个前提，所有调试都是在和设计对抗。
