C++ vector emplace_back和push_back怎么选-C++-PHP中文网

传已有对象时应无脑用push_back，因其语义清晰、行为可预测；传构造参数时优先选emplace_back，可跳过临时对象、提升性能；对int等平凡类型二者无实质差异。

c++ vector emplace_back和push_back怎么选

传已有对象时，无脑用 `push_back`

如果你手头已经有一个构造好的对象（比如局部变量、成员变量或函数返回值），push_back 是唯一合理选择。此时 emplace_back 不仅不能简化逻辑，反而可能因完美转发引发隐式转换歧义或编译失败。

常见错误现象：emplace_back(obj) 对非拷贝/移动友好的类型（如含 explicit 构造函数的类）可能静默调用错误构造函数，甚至编译不过；而 push_back(obj) 明确表示“我要搬这个现成的对象”，语义清晰、行为可预测。

已有 std::string s = "hello"？直接 vec.push_back(s) 或 vec.push_back(std::move(s))
函数返回 Person get_person()？用 vec.push_back(get_person())，别写 vec.emplace_back(get_person())
类型有 explicit Person(int)？emplace_back(42) 会失败，push_back(Person(42)) 才合法

传构造参数时，优先选 `emplace_back`

当你知道要构造什么、且参数明确（比如 "Alice" 和 25），emplace_back 能跳过临时对象的构造与析构，在底层直接调用目标类型的构造函数——这对自定义类、std::string、std::pair 等尤其明显。

性能影响：在高频插入循环中（如读配置生成千个对象），emplace_back("name", 30) 比 push_back(Person("name", 30)) 少一次完整对象的构造+析构，实测可减少 10%~30% 的 CPU 时间（取决于对象复杂度）。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

插入 std::pair<int std::string></int>？vec.emplace_back(1, "foo") 比 vec.push_back(std::make_pair(1, "foo")) 更干净
构造 std::string？vec.emplace_back("hello") 避免临时 std::string 实例，比 vec.push_back("hello") 多一次隐式转换再移动
参数含右值引用？emplace_back(std::move(s), 42) 能正确转发，而 push_back 接收的是已移动过的对象，无法再拆解

`push_back` 和 `emplace_back` 在 trivial 类型上没区别

对 int、double、const char* 这类无构造/析构逻辑的类型，两者生成的汇编几乎一致，编译器会完全优化掉所谓“拷贝”开销。别为 std::vector<int></int> 的插入纠结用哪个。

容易踩的坑：有人看到 “emplace_back 更快” 就全局替换，结果在 vec.emplace_back(42) 这种地方引入了不必要的模板实例化开销（虽然极小），还让代码偏离直觉——整数就是值，不是“构造出来”的。

插入原始类型？用 push_back(42) 或 emplace_back(42) 都行，选读起来顺的那个
团队代码风格统一优先于微优化：如果项目里全是 push_back，除非真有性能瓶颈，否则不值得改

不确定时，先写 `push_back`，再看是否值得换

现代 C++ 的惯性是“能用 emplace_back 就用”，但真实项目里更常见的是：参数来源复杂（来自 map 查找、optional 解包、lambda 捕获）、类型构造函数不稳定（后期加了 explicit）、或调试时需要观察临时对象生命周期。这时候硬上 emplace_back 反而增加理解成本和维护负担。

关键判断点：你是否真的在“创建新对象”？如果是，且参数直接、类型稳定、无歧义转换，emplace_back 值得；如果只是“放一个已有东西进去”，push_back 就是终点。