要真正移动 vector 元素到 list，必须显式使用 std::make_move_iterator 配合 list 构造或 insert；否则默认拷贝。移动后 vector 仍有效但元素已移出，推荐调用 clear() 保留容量，shrink_to_fit() 可选。
用 std::move_iterator 配合 list::insert 或构造函数最直接
直接调用 list::assign 或 list 构造函数时传入 vector 迭代器，只会拷贝元素；要真正“移动”（即对每个元素调用移动构造），必须显式使用移动迭代器。否则，哪怕 vector 元素是可移动的，list 仍会走拷贝路径。
-
std::list<t> lst(std::make_move_iterator(v.begin()), std::make_move_iterator(v.end()));</t>—— 构造新list，v保持有效但元素处于“已移出”状态（值不确定，仅可析构或赋值） -
lst.insert(lst.end(), std::make_move_iterator(v.begin()), std::make_move_iterator(v.end()));—— 追加到现有list尾部 - 别用
lst.assign(v.begin(), v.end())：它不识别移动语义，强制拷贝
vector::clear() 后不能认为内存被释放，但移动后 vector 可安全复用
移动操作不会改变 vector 的容量（v.capacity() 不变），只把每个元素逐个移动走，最后调用 v.clear() 是推荐收尾动作——它将大小置为 0，但保留分配的内存。如果后续还要往 v 里塞新数据，这反而省了重新分配。
- 移动后不
clear()也没错，但v.size()仍是原值（只是内部对象已被移出），容易引发误读 -
v.shrink_to_fit()可选，但不必要：它触发内存回收，有额外开销，且不保证成功 - 若想彻底清空并释放内存，顺序应为：
std::make_move_iterator→ 插入/构造 →v.clear()→v.shrink_to_fit()
移动失败的常见原因：元素类型不支持移动构造
即使写了 std::make_move_iterator，如果 T 没有移动构造函数（例如显式删除、或只有拷贝构造且未定义移动），编译器会回退到拷贝。此时不会报错，但性能没提升，甚至可能因拷贝失败而编译不通过。
- 检查
static_assert(std::is_move_constructible_v<t>);</t> - 自定义类中，确保移动构造函数未被隐式抑制（如声明了拷贝构造但没写移动构造，且含不可移动成员）
- 内置类型（
int、double）、std::string、std::vector等默认支持移动；std::array不支持（因为其元素是直接存储的，移动即拷贝）
性能与语义差异：比 std::move(v) + list::splice 更通用
list::splice 能零开销转移整个 list 的节点，但它只接受另一个 list；你无法把 vector “整体 splice” 过去。所以对 vector → list 场景，make_move_iterator 是唯一标准解法。
立即学习“C++免费学习笔记（深入）”；
- 不要尝试
std::move(v)后传给list构造函数：那只是移动vector对象本身（指针和大小信息），不是移动其元素内容 - 移动迭代器方式时间复杂度是 O(n)，空间上只多一个
list节点的开销（每个元素额外一个指针），这是不可避免的——vector是连续内存，list是链式节点，结构转换必然发生 - 如果追求极致性能且元素类型简单，考虑是否真需要
list：多数场景下std::deque或带reserve()的vector更快
clear() 导致 size() 和实际内容不一致，调试时容易误判。 
