C++常量正确性：const everywhere是否过度？【可变性最小化原则】

不加 const 易致意外修改、悬垂引用、编译失败等；const 成员函数不可修改非 mutable 成员或调用非 const 函数；auto 忽略顶层 const；返回 const 值类型会禁用移动语义。

const 修饰变量时，哪些地方不加反而会出问题？

不加 const 最直接的风险是意外修改——尤其在函数参数、返回值、成员函数中。比如传入一个 std::

vector& 参数，调用方默认认为你可能改它；而如果声明为 const std::vector&，编译器会拦住所有写操作，也向协作者明确语义。

常见踩坑点：

• 把临时对象绑定到非 const 左值引用（void f(int&); f(42); → 编译失败），但允许绑定到 const int&
• 返回局部对象的 const 引用（const std::string& get() { return "hello"; }）仍悬垂，const 不延长生命周期
• auto 推导忽略顶层 const：const int x = 42; auto y = x; → y 是 int，不是 const int

const 成员函数里能调什么？不能调什么？

标记为 const 的成员函数，隐式地将 this 指针变为 const T*，因此只能调用其他 const 成员函数，且不能修改任何非 mutable 成员变量。

典型误用场景：

• 在 const 函数里调用非 const 重载版本（如 map[key] 是非 const，应改用 map.at(key) 或 map.find(key)）
• 试图修改缓存字段但忘了加 mutable：比如 mutable std::optional cached_result;
• 调用标准库容器的非常量接口（vec.push_back()、str += "x"）直接编译报错

const_iterator 和 auto + begin() 混用时的陷阱

用 auto it = container.begin() 在 const 容器上推导出的是 const_iterator，但很多人误以为它只是“只读迭代器”，其实它还影响 operator* 返回类型——解引用得到的是 const T&，无法传给期望 T& 的函数。

更隐蔽的问题：

• for (auto& x : container) 在 const 容器中等价于 for (const auto& x : container)，但若容器本身非常量，却想强制只读遍历，必须显式写成 for (const auto& x : container)
• std::vector 的 operator[] 返回代理对象，其 const 版本行为与普通容器不一致，加 const 可能掩盖逻辑错误
• std::span 构造时若源是 const T*，则 span.data() 返回 const T*，强行 const_cast 去 const 就破坏了常量正确性边界

什么时候加 const 真的没用，甚至有害？

const 不是银弹。过度使用会干扰模板推导、妨碍 move 语义、增加冗余签名。

值得关注的反模式：

• 函数返回 const 值类型（const std::string foo();）：阻止移动，C++17 后还可能抑制 RVO，纯属负优化
• 模板参数中对 const T& 过度泛化：比如 template void f(const T& x) 会拒绝接受右值（除非加万能引用），不如用 const T& + T&& 重载或 std::forward
• 在 PIMPL 中把 impl 指针声明为 std::unique_ptr：既不能修改 impl，又无法调用其非常量成员，失去封装意义

// 错误：返回 const 值类型，禁用移动
const std::vector get_data() {
    return {1, 2, 3};
}

// 正确：让返回值保持可移动
std::vector get_data() {
    return {1, 2, 3};
}

真正关键的不是“所有地方都加 const”，而是清楚每处 const 所守卫的契约边界：它是否防止了不该发生的修改？是否暴露了不该暴露的可变性？是否和调用上下文的语义一致？这些判断比机械套用规则重要得多。