emplace_back与push_back：C++容器操作的效率密码

当vector需要扩容时

每次在C++的vector里塞新元素，就像往已经装满的行李箱硬塞衣服。当容量不足时，vector会找个更大的”行李箱”，把旧物件全搬过去。这时候push_back和emplace_back的差异就藏在这个搬运过程里。传统push_back像请搬运工（构造函数+拷贝构造），而emplace_back直接在现场组装家具（原地构造），省时省力。

push_back的工作流水线

想象你在工厂组装汽车：push_back先在外面把汽车造好（创建临时对象），再用吊车运进厂房（拷贝构造）。比如vec.push_back(MyClass(10))，这里经历了：

• MyClass临时对象在厂外诞生
• vector腾出新车位（可能触发扩容）
• 把整车复制到vector里
• 销毁门外临时车

这就像网购——快递盒（临时对象）拆完就扔，浪费资源

emplace_back的现场施工

em直接让工程师带着零件进厂房组装。调用vec.emplace_back(10)时：

• vector直接分配内存格子
• 在格子内部调用构造函数MyClass(10)
• 0次拷贝，0次临时对象

省去了”造车-运车”的中间商赚差价，尤其当对象像大象般笨重时，优势更明显。

性能擂台实测对比

用存储10000个复杂对象的测试说话：

当对象构造函数像老牛拉车般缓慢时，emplace_back能提速30%以上。但若对象轻如羽毛（比如int），差异可以忽略不计。

选择恐惧症解救指南

该抄起哪把工具？记住三条黄金法则：

• 对象构造成本大时→emplace_back
• 需要显式调用构造函数时→emplace_back
• 简单内置类型→push_back更直观

特殊场景注意：当vector存储基类指针时，push_back(new Derived)能自动向上转型，而emplace_back需要手动static_cast。

小心emplace的暗礁

别被高性能冲5640昏头，这些坑摔过的人才懂：

• 参数误判：emplace_back(“hello”)可能匹配错构造函数
• 异常危机：构造中途出错会导致vector数据污染
• 初始化列表陷阱：emplace_back({1,2})需要额外std::initializer_list

建议用完美转发时加上std::forward，像给参数系安全带。

C++11后的新战场

自从emplace家族在C++11登场，其他容器也跟风升级：

map的emplace(“key”, value) vs insert
set的emplace_hint精准定位插入

甚至queue也加入emplace战队。但记住：list的emplace_back和push_back差异极小，因为链表从不搬家。

终极选择心法

说到底，选谁取决于你像不像个”抠门老板”：

• 追求极致性能→emplace_back省搬运工工资
• 代码可读性优先→push_back直白如白话诗
• 维护老代码→别乱把push_back改成emplace_back

当你盯着vector犹豫时，先问自己：这个对象构造贵不贵？它要长途搬运吗？答出来，工具选择自然明朗。