std::move对const对象无效，会退化为拷贝；因其返回const T&&，而移动操作符仅接受T&&，重载解析失败，只能调用拷贝构造/赋值。
对 const 对象调用 std::move 会退化为拷贝
直接说结论：std::move 对 const 对象无效，编译器会跳过移动构造/赋值，回退到拷贝路径。这不是 bug，是标准行为——因为移动操作必须修改源对象（比如把指针置为 nullptr），而 const 禁止修改。
常见错误现象：
- 你以为加了
std::move就能避免拷贝，结果性能没变化，甚至更差（多一次无意义转型） - 类中只定义了移动构造函数，但删掉了拷贝构造函数；对
const对象调用std::move后编译失败，报错类似use of deleted function ‘X::X(const X&)’
根本原因：std::move(const T&) 的返回类型是 const T&&，而绝大多数移动操作符签名是 T&&（非 const 右值引用）。两者不匹配，重载解析失败，只能选拷贝。
const T&& 几乎不会被调用，也难以被实现
你可能见过 void f(const T&&) 这样的函数声明，但它在实践中极少有用。标准库容器、智能指针、std::string 等所有主流类型，其移动操作符都只接受 T&&，而非 const T&&。
立即学习“C++免费学习笔记（深入）”；
如果你自己写一个类并显式提供 const T&& 版本的移动构造函数，它也不会被 std::move 触发——因为 std::move 本身不参与重载决策，只是改类型；真正触发哪个函数，取决于目标函数签名是否匹配。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
所以别试图“绕过 const 限制”去移动：要么去掉 const，要么接受拷贝。
哪些场景容易误用 std::move + const
典型误用集中在参数传递和返回值优化环节：
- 函数参数是
const T&，你在函数体内对它调用std::move(x)—— 没用，x 是 const 左值，转成const T&&后仍无法触发移动 - 返回一个局部
const对象，比如const std::vector<int> v = {...}; return std::move(v);</int>—— 编译器本可自动应用 RVO 或移动，加std::move反而干扰优化，且因const导致退化为拷贝 - 用
std::move转发const成员变量，如std::move(obj.member_)，而member_声明为const std::string member_;—— 移动语义完全失效
真正需要移动时，const 和 std::move 天然冲突
移动语义的核心是所有权转移，这要求源对象被修改（例如释放资源、清空内部指针）。只要对象是 const，这个前提就不存在。
所以实际编码中应明确取舍：
- 如果对象内容不该被修改，就接受拷贝，或改用引用/指针传递避免复制
- 如果性能关键且对象很大，就不要把它设计成
const—— 把 const 性质移到接口层（比如只暴露 const 成员函数），而非数据本身 - 检查类是否真的实现了移动操作符：
static_assert(std::is_move_constructible_v<t>)</t>，否则std::move单独存在毫无意义
最常被忽略的一点：std::move 不是性能开关，它是类型转换工具；而 const 是语义锁。两者相遇，语义锁胜出——移动不会发生，拷贝照旧，代码还变得更难读。
