




const_iterator 是编译期只读迭代器,确保无法修改元素,提升接口安全性与通用性;它与 iterator 底层类型常相同,区别仅在 const 限定,推荐优先使用 cbegin()/cend() 获取。
它和 iterator 的底层类型可能完全一样(比如 vector),但编译器会阻止通过它调用非 const 成员函数,比如 operator* 返回的是 const T&,operator-> 返回的是 const T*。这不是运行时保护,而是编译期契约——只要用了 const_iterator,就无法写出 *it = x 这类赋值语句。
常见错误现象:传入 iterator 却只读遍历,结果因接口开放写权限,后续有人误加赋值逻辑,破坏封装性;或者函数声明接受 iterator,导致无法传入 const 容器(因为 const vector 返回的是 const_iterator,不能隐式转成 iterator)。
const_iterator
Container::iterator,则无法接收 const Container& 的迭代器,必须改用 Container::const_iterator 或模板推导auto 时注意:对 const 容器调用 begin(),auto 推出的就是 const_iterator;但对非常量容器,默认 begin() 返回 iterator,需显式写 c.begin()(其中 c 是 const 引用)或用 cbegin()
当一个算法函数只读不写,却把参数声明为 iterator,就人为限制了调用方:你不能把 const vector 的迭代器传进去,哪怕你只是想遍历求和。而声明为 const_iterator 后,既接受 const 容器的迭代器,也兼容非常量容器的 const_iterator(比如 v.cbegin())。
性能上无额外开销——const_iterator 和 iterator 通常是同一类型(如 libstdc++ 中 std::vector 和 const_iterator 都是 T* 或包装指针的轻量结构),区别纯在 const 限定符。
const_iterator,而非 iterator
auto 或概念约束,而不是重载两个版本cbegin() 明确表达“我要只读遍历”的意图,且无论容器本身是不是 const,都返回 const_iterator。相比 begin(),它规避了因容器非常量而导致返回可写迭代器的风险;相比强制 static_cast 或取地址再转,它零开销、可读性强、符合标准库惯用法。
容易踩的坑:在函数内部对参数 const_iterator 做 ++it 是允许的(移动位置不等于修改元素),但有人误以为“const 迭代器不能自增”,其实 it 本身是可变的,只是它指向的内容不可变。
cbegin()/cend() 替代 begin()/end() 来获取只读迭代器const_iterator 可以和 iterator 比较(如 it != v.end()),只要它们来自同一容器,比较操作是定义良好的vector::const_iterator 类型别名,现在更推荐直接用 auto 或 cbegin() 避免冗长类型书写泛型算法里如果写 template,调用时传 const_iterator 没问题,但若函数内部试图解引用并赋值(*first = x),编译就会失败——这反而是好事。但更隐蔽的问题是:如果模板函数本意只读,却没限制 Iter 必须满足“可解引用为 const 类型”,那用户可能误传 iterator,导致函数体被误改。
这时候可以用 std::is_const_v<:remove_reference_t>> 做 SFINAE,或 C++20 概念:requires std::same_as<:iter_value_t>, std::iter_const_reference_t ——不过实践中,更简单有效的方式是:直接把参数类型写成 Container::const_iterator,或用 const Container& 作参数,再调用其 cbegi。
const Container& 传参 + cbegin(),比传两个迭代器更安全——它天然绑定容器生命周期,避免迭代器悬空const_iterator,而是判断「这个函数到底该不该拥有写权限」——一旦模糊,类型系统就失去意义。很多 bug 其实源于接口一开始就没想清楚读写边界。