const引用参数能避免对象拷贝开销，同时提供编译期只读保障、无空悬风险、支持临时对象绑定，是C++中非内置类型函数参数传递的首选策略。
const引用参数能避免对象拷贝开销
当函数接收 std::string、std::vector 或自定义类（如 QIcon）这类对象时，值传递会触发完整拷贝——构造副本、分配内存、复制数据，甚至可能触发深拷贝逻辑。而 const std::string& 这类声明不创建副本，只传地址，函数内部通过引用访问原始对象，省掉所有拷贝成本。
常见错误现象：void process(std::string s) 在处理大字符串时 CPU 占用突增、函数调用延迟明显；换成 void process(const std::string& s) 后性能回归正常。
- 内置类型（
int、double）没必要用 const 引用，值传递更直接 - 类对象越大、拷贝逻辑越重，const 引用收益越明显
- 编译器对小对象的返回值优化（RVO/NRVO）不适用于参数传递，不能依赖它抵消拷贝代价
const确保函数不会意外修改实参
引用本身是别名，没有 const 修饰时，函数内任何赋值或成员函数调用都可能改变原始对象状态。加上 const 后，编译器会在编译期拦截所有非常量操作，比如 s += "suffix" 或 v.push_back(42) 都会报错：error: assignment of member '...' in a const object。
这不只是安全机制——它让接口契约清晰：调用者一眼看出该参数只读，无需翻阅函数实现或文档确认副作用。
立即学习“C++免费学习笔记（深入）”；
- 没有 const 的引用参数（如
std::string& s）允许修改，但多数只读场景下这是危险且易被误用的 - const 引用还能接受临时对象，比如
func(std::string("hello"))合法；而非 const 引用则拒绝绑定临时量 - const 引用比非 const 引用兼容性更强：能同时接收 const 和 non-const 实参
为什么不是 const 指针或普通引用
对比 const T* ptr 和 const T& ref：前者需解引用（*ptr），空指针风险存在，调用方还得取地址（func(&x)）；后者语法简洁、无空悬风险、强制初始化，语义更贴近“我只想安全地看这个对象”。
普通引用（T&）虽也避免拷贝，但放弃只读约束后，函数行为变得不可预测——尤其在大型项目中，一个看似只读的辅助函数悄悄改了传入的 std::map，调试起来极难定位。
-
const T&是唯一同时满足「零拷贝 + 编译期只读保障 + 无空值风险 + 支持临时对象」的组合 - 某些场景下移动语义（
T&&）更适合可变操作，但它和 const 引用解决的是不同问题 - 不要为图省事把所有参数都写成
const T&：如果函数明确要修改对象，就该用T&，让意图暴露在签名里
QTableWidgetItem 构造函数里的 const QIcon& 就是典型用例
像 QTableWidgetItem(const QIcon& icon, const QString& text) 这样的签名，说明构造过程只读取图标和文本内容来初始化自身字段，绝不会去调用 icon.addPixmap(...) 或 text.replace(...)。既保证 UI 组件不污染原始资源，又避免每次创建 item 都拷贝整个图标数据。
容易踩的坑：有人试图在构造函数里把 icon 存为非 const 成员引用（const QIcon& m_icon），却忘了生命周期——若传入的是局部变量或临时 QIcon，对象析构后引用就悬空了。这时候必须拷贝或用智能指针管理所有权。
真正关键的不是“用了 const 引用”，而是“理解它何时安全、何时需要转为值语义或共享所有权”。
