vector插入性能瓶颈根本不在emplace_back和push_back之争，而在于未调用reserve()导致的频繁扩容；扩容时拷贝/移动现有元素的开销远超构造方式差异，仅当预分配后且插入非平凡类型时emplace_back才有明显优势。
vector插入性能瓶颈根本不在emplace_back和push_back之争
直接说结论：如果你没调用reserve()，就别急着纠结用哪个插入函数——扩容开销会吃掉所有微小差异。实测显示，未预分配时emplace_back()比push_back()快不了多少，甚至可能更慢，因为扩容过程强制调用拷贝构造、析构旧对象、再构造新元素，这部分成本远高于单次构造方式的差别。
常见错误现象：vector在循环中逐个push_back()或emplace_back()，观察到CPU时间集中在内存分配和元素搬移上，capacity()值跳变多次；perf或vtune里看到大量operator new和memcpy调用。
- 触发扩容时，
emplace_back()仍需拷贝现有元素（调用拷贝/移动构造），不是“完全免拷贝” -
reserve()之后，两者性能差距才真正浮现，且只在构造成本高的类型上明显 - 对
int、double等trivial类型，编译器通常能优化掉差异，汇编几乎一致
什么情况下emplace_back确实更快？看构造函数调用次数
关键判断依据不是“用了右值”，而是“是否绕过了临时对象生命周期”。当类有非平凡构造逻辑（比如动态分配内存、打开文件句柄、加锁等），emplace_back()能少一次构造+一次析构。
典型场景：插入std::string、自定义Person、含std::vector成员的结构体。
立即学习“C++免费学习笔记（深入）”；
-
vec.push_back(Person("Alice", 25))→ 先调用Person构造函数，再调用移动构造（或拷贝构造），最后析构临时对象 -
vec.emplace_back("Alice", 25)→ 只调用一次Person构造函数，在vector已分配的内存中直接完成 - 若类禁用移动构造（
= delete），push_back()退化为拷贝构造，开销更大
push_back在C++11后并不“过时”，它更适合已有对象场景
很多人误以为emplace_back()是万能替代品，但实际中push_back()更自然、更安全的使用场景并不少见。
常见使用场景：
- 你已经有一个现成对象：
Person p = get_person_from_db(); vec.push_back(p); - 参数来自运行时计算，无法直接转发（比如
std::string拼接结果）：vec.push_back(combine_name(first, last)); - 需要复用同一对象多次插入（如默认配置项）：
Config cfg = load_default(); for (int i = 0; i - 插入
std::move()后的右值：vec.push_back(std::move(temp_obj));，此时底层就是调用emplace_back()实现的
真实项目中该怎么做？三步走
别靠直觉，按数据特征和插入模式决策：
- 先估算最终大小：如果知道要插N个元素，无条件加
vec.reserve(N)；哪怕估高20%，也比不预分配强 - 再看插入来源：参数明确（如字面量、简单变量）→ 优先
emplace_back()；已有对象或复杂表达式 → 用push_back() - 最后做验证：对关键路径打点，用
vec.capacity()确认没意外扩容；对复杂类型，加构造/析构计数器看实际调用次数
容易被忽略的一点：不同STL实现的扩容因子不同（GCC用2.0，MSVC用1.5），这意味着同样插入100万个元素，实际搬移的总字节数可能差30%以上——reserve()不是可选项，是必选项。
