不加 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 成员变量。
典型误用场景：
立即学习“C++免费学习笔记（深入）”；
- 在
const函数里调用非const重载版本（如map[key]是非 const，应改用map.at(key)或map.find(key)） - 试图修改缓存字段但忘了加
mutable：比如mutable std::optionalcached_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::vectorget_data() { return {1, 2, 3}; } // 正确：让返回值保持可移动 std::vector get_data() { return {1, 2, 3}; }
真正关键的不是“所有地方都加 const”，而是清楚每处 const 所守卫的契约边界：它是否防止了不该发生的修改？是否暴露了不该暴露的可变性？是否和调用上下文的语义一致？这些判断比机械套用规则重要得多。
