std::move不能真正移动const对象，因为它仅将const T转为const T&&，而标准库移动操作只接受T&&，故实际调用拷贝构造或赋值。
std::move 不能真正移动 const 对象
std::move 只是类型转换，它把左值转成 T&&（右值引用），但前提是原类型可绑定到该右值引用。而 const T 对象经 std::move 后得到的是 const T&&，不是通常能触发移动构造/赋值的 T&&。
编译器会优先匹配 const T&& 版本的重载（如果存在），否则退回到 const T& 的拷贝版本 —— 这就是“看似用了 move，实则还是拷贝”的根源。
- 移动操作函数（如
vector的移动构造）通常只声明为T&&，不接受const T&& - 如果你自己写了
void foo(const std::string&& s)，std::move(s)才可能调用它，但这不是标准库行为 - 对
const std::vector<int></int>调用std::move后传给std::vector构造函数，最终调用的是拷贝构造，不是移动构造
const 对象 + std::move 的典型错误现象
常见表现是性能没提升、对象仍被完整拷贝、甚至编译失败（当目标函数只接受非 const 右值引用时）。
- 代码写成：
const std::string s = "hello"; std::string s2 = std::move(s);→ 实际调用std::string(const std::string&)拷贝构造 - 返回局部 const 对象并试图 move：
const std::vector<int> get_data() { return {1,2,3}; }</int>，再auto v = std::move(get_data());→ 仍是拷贝，且get_data()返回的是临时对象，本身已可被移动，加 const 反而阻断了它 - 容器里存着
const元素（如std::vector<const int></const>），无法对其元素调用任何修改或移动操作，连std::move都无意义
什么时候 const + std::move 可能“生效”？
极少数情况：你显式提供了接收 const T&& 的重载，且逻辑上允许“只读式转移”（比如仅转移内部指针而不修改原对象状态）。但这属于自定义语义，标准库完全不支持。
立即学习“C++免费学习笔记（深入）”；
- 例如自己实现一个包装类：
MyString(MyString&&)和MyString(const MyString&&)都存在，后者做浅拷贝或只读视图转移 - 但
std::string、std::vector、std::unique_ptr等所有标准类型，均未提供const T&&构造函数或赋值运算符 - 因此，对标准类型而言，
std::move作用于const对象，等价于白写一行
实战建议：如何避免掉进这个坑
关键不是“怎么让 const 对象 move”，而是“为什么你会想 move 一个 const 对象”。多数时候，这是设计信号：不该 const，或不该 move。
- 如果变量需要被移动，就不要声明为
const—— 移动本质是破坏性操作，与 const 语义冲突 - 函数返回值别加
const（如const std::vector<int> f()</int>），这会抑制返回值优化（RVO）和移动语义 - 检查是否误用了
const引用参数：void process(const std::string& s)是合理的，但若后续想 move 它，说明接口设计有问题 —— 应拆成process(std::string&&)和process(const std::string&)两个重载 - 用
static_assert检查是否真触发了移动：static_assert(std::is_rvalue_reference_v<decltype>);</decltype>不够，还得确认目标函数是否真匹配了T&&版本
-Wpessimizing-move in Clang）能直接捕获“std::move 作用于 const 对象”的冗余调用。这种写法不报错，但几乎总意味着逻辑矛盾。 
