std::views::chunk_by仅基于相邻元素对调用谓词切分，不考虑全局值分布；其谓词必须是二元、无状态、不可修改的可调用对象，如std::equal_to{}或按十位分组的lambda。
std::views::chunk_by 只认相邻元素对，不看全局值分布
它不是按“所有相等元素归为一组”来分块，而是仅在 i 和 i+1 位置上应用谓词，一旦返回 false 就切一刀。比如用 std::equal_to{} 对 {1,2,1,1} 切分，结果是 [1],[2],[1,1]，而不是你可能期待的 [1],[2],[1,1]（看起来一样，但逻辑完全不同）——第三块成立只因为索引 2 和 3 的元素相等，跟前面的 1 完全无关。
常见错误现象：
- 传入
std::less{}试图做单调段切分，却漏掉非严格递增的拐点（比如{1,2,2,1}中第二个2到1才触发切割，前两个2被合并） - 误以为能替代
std::views::split：后者按匹配值/子串切，chunk_by永远只看相邻关系
谓词必须是二元可调用对象，且不能修改状态
chunk_by 在内部维护一个“当前块起始元素”，每次比较都拿它和下一个元素传给谓词。这意味着谓词签名必须是 bool(T, T)，且不能依赖外部变量或捕获可变状态——否则行为未定义（多数实现会在 debug 模式下断言失败）。
使用场景限制：
立即学习“C++免费学习笔记（深入）”；
- 支持
std::equal_to{}、std::greater{}、lambda 如[&](auto a, auto b) { return a / 10 == b / 10; }（按十位分组） - 不支持捕获局部变量并修改它，例如
[count](auto, auto) mutable { return ++count 是错的 - 若输入范围是
const，谓词参数类型也必须接受const T&
chunk_by_view 迭代器失效风险比 chunk 高得多
chunk_by 生成的 chunk_by_view 是前向视图（forward_range），但它内部依赖原范围迭代器的多次解引用与比较。一旦原容器发生插入/擦除（哪怕只是 std::vector::push_back 导致重分配），所有已构造的 chunk_by_view::iterator 立即失效——而 std::views::chunk 因为只依赖随机访问偏移，反而更耐折腾。
容易踩的坑：
- 把
chunk_by结果存成成员变量，但原容器是函数局部std::vector，返回后视图悬垂 - 在循环中边遍历
chunk_by边修改原容器（如删除当前块首元素），触发未定义行为 - 对
std::list使用chunk_by：虽满足 forward_range，但节点指针稳定性差，实际比 vector 更易出问题
C++27 增强了 chunk_by 的诊断能力，但语义没变
C++27 并没有改 chunk_by 的切分逻辑，只是让编译器更容易告诉你哪里错了。比如传入一元谓词，C++23 可能报一长串模板推导失败，C++27 会直接提示 “chunk_by requires a binary predicate, got unary callable”。另外，当谓词抛异常时，C++27 明确要求传播而非静默吞掉。
性能影响很小，但要注意：
- 仍不支持
constexpr（不像filter_view在 C++27 已支持） - 若谓词本身开销大（比如涉及字符串比较或系统调用），整个切分过程就变成 O(n) 次调用，无法优化掉
- 和
std::views::zip_transform组合时，要确保两个范围长度一致，否则chunk_by可能提前终止
vec | std::views::chunk_by(pred)，而是想清楚“我到底要按什么边界切”——相邻性判断这层抽象，既给了你精确控制力，也悄悄藏好了所有歧义点。 
