vector::emplace_back通过完美转发参数直接在vector底层内存调用元素构造函数，绕过临时对象的创建与移动；仅当容量不足扩容或元素不可移动时才无法避免拷贝/移动。
vector::emplace_back 是怎么绕过拷贝/移动的
它不创建临时对象，而是直接在 vector 底层内存里调用元素类型的构造函数。关键在于：emplace_back 把参数原样转发给目标类型的构造函数，跳过了「先构造临时对象 → 再移动/拷贝进容器」这一步。
比如 std::vector<:string> 存储长字符串时，push_back("hello") 会先构造一个临时 std::string，再调用移动构造；而 emplace_back("hello") 直接在 vector 分配好的内存位置上调用 std::string(const char*) 构造函数。
- 前提是 vector 当前容量足够，否则仍会触发扩容——扩容时仍需移动已有元素（此时无法避免）
- 若元素类型没有匹配的构造函数（比如只接受右值引用），
emplace_back编译失败，而push_back可能隐式转换后移动 - 转发参数使用的是完美转发（
std::forward），所以emplace_back(std::move(s))会调用移动构造，emplace_back(s)会调用拷贝构造
emplace_back 和 push_back 在什么情况下性能没差别
当元素是 trivial 类型（如 int、double、POD 结构）或编译器开启强优化（如 -O2）时，push_back 的临时对象常被完全优化掉，汇编里看不出差异。
更常见的是：构造函数本身开销极小，或者对象很小（std::pair），临时对象的构造+移动成本几乎为零，此时 emplace_back 带来的收益可忽略。
立即学习“C++免费学习笔记（深入）”；
- 调试模式（未开启优化）下差异最明显
- 涉及堆分配的类型（如
std::string、std::vector）更容易测出差距 - 注意：如果构造函数有副作用（比如打日志），
emplace_back和push_back的调用次数不同，行为也不等价
为什么 emplace 不支持指定位置（比如 emplace_at）
vector 没有 emplace_at 或类似接口，是因为在中间插入需要移动后续所有元素——哪怕新元素原地构造，移动已有元素仍要调用它们的移动/拷贝构造函数，无法规避临时对象语义。
真正支持“原地构造+不移动”的只有尾部插入（emplace_back）和头部/中间插入（emplace）配合迭代器定位，但后者依然要搬移元素：
-
v.emplace(v.begin() + i, args...)：先腾出位置（移动[i, end)），再在i处原地构造 - 移动过程仍可能触发已有元素的移动构造，这部分开销无法消除
- 若元素类型不可移动（仅可拷贝），则必须拷贝，
emplace也救不了
容易被忽略的陷阱：allocator 和 placement new 的实际约束
emplace_back 的原地构造依赖于 std::allocator::construct，其底层通常用 ::new(p) T(args...)（placement new）。这意味着：
- 元素类型
T必须是可平凡析构（trivially destructible）或析构函数可安全调用——否则 vector 在异常中途析构时可能出问题 - 若自定义 allocator 重载了
construct，且没正确处理异常安全（比如构造抛异常后未回滚内存状态），emplace_back可能导致未定义行为 - 对齐要求必须满足：若
T要求 16 字节对齐，而 vector 分配的内存块起始地址不对齐，placement new行为未定义（实际中std::allocator保证对齐，但自定义分配器需自行确保）
这些细节在日常编码中很少暴露，一旦涉及自定义类型+自定义分配器+异常路径，就很容易掉坑里。
