std::move_iterator是零开销的迭代器适配器，将解引用结果转为T&&以支持移动语义，需配合uninitialized_move等算法使用，不适用于输入流迭代器或返回临时值的自定义迭代器。
std::move_iterator 本质是“带移动语义的迭代器适配器”
它不自己存储数据，也不改变容器结构，只是把 operator* 和 operator-> 的返回类型从 T& 悄悄变成 T&&。真正触发移动的是后续算法（比如 std::copy、std::uninitialized_copy）在解引用时调用移动构造/赋值——所以它必须配合支持右值引用操作的算法或手动解引用使用。
常见误用：直接对 std::vector<std::string> 用 std::move_iterator + std::copy 到另一个 std::vector，却忘了目标容器的 push_back 或 assign 是否接受右值。结果还是拷贝——因为 std::vector::push_back(T&&) 存在，但 std::copy 内部调用的是 iterator_traits::reference，而目标迭代器（如 back_inserter）最终调用的仍是 push_back(const T&)，除非你显式传入移动就绪的迭代器。
真正实现“就地移动元素”的典型场景：重定位容器内部区间
比如把一个 std::vector 的后半段“挪”到前面，同时让原位置进入有效但未定义状态（即元素被移走）。这时不能靠 std::copy，得用 std::uninitialized_move 或手动循环 + std::move，而 std::move_iterator 是让这个过程可组合的关键胶水。
- 源区间必须能提供可移动的左值（即容器本身没被
std::move过，否则迭代器失效） - 目标区间必须是未初始化内存（如新分配的 raw buffer）或已析构旧对象的内存（需确保 no-throw move constructible）
-
std::move_iterator通常和std::make_move_iterator一起用，避免手写模板参数
std::vector<std::string> v = {"a", "b", "c", "d"};
std::vector<std::string> w(2); // 预留空间
// 把 v[2] 和 v[3] 移动到 w 中
std::uninitialized_move(
std::make_move_iterator(v.begin() + 2),
std::make_move_iterator(v.end()),
w.begin()
);
// 此时 v[2] 和 v[3] 处于有效但未定义状态（比如空字符串），w[0], w[1] 已被移动构造
和 std::move 容器本身的区别：别混淆“移动迭代器”和“移动整个容器”
std::move(v) 让整个 v 进入“被移动后状态”，之后访问 v 的任何元素都是未定义行为（除非重新赋值）。而 std::make_move_iterator(v.begin()) 不影响 v 的生命周期，只影响通过该迭代器读取时的值类别。
立即学习“C++免费学习笔记（深入）”；
- 错误写法：
auto it = std::make_move_iterator(std::move(v).begin())——std::move(v)返回右值引用，.begin()可能返回 dangling 迭代器 - 正确前提：源容器必须保持活跃且未被移动，仅用其迭代器做“视图转换”
- 性能影响：零开销抽象，编译期生成等效于手写
std::move(*it)的代码
容易被忽略的兼容性坑：输入迭代器不适用
std::move_iterator 要求底层迭代器满足 LegacyIterator（至少是 InputIterator），但它**不适用于只读单次遍历的输入流迭代器**（如 std::istream_iterator）。因为 std::move_iterator 的 operator* 会尝试对临时对象调用 std::move，而输入迭代器解引用返回的是临时值（rvalue），再 move 一次是冗余甚至非法的（C++17 起禁止对纯右值调用 std::move）。
更隐蔽的问题：某些自定义迭代器若 operator* 返回 T（而非 T& 或 const T&），套上 std::move_iterator 后会尝试对临时对象 move，触发编译错误或静默降级为拷贝。
安全做法：只对容器原生迭代器（std::vector::iterator、std::deque::iterator 等）或明确返回左值引用的自定义迭代器使用 std::move_iterator。
