try_emplace更安全，因仅键不存在时才构造值对象，避免重复构造/析构及异常风险；正确调用为try_emplace(key, args...)，不支持pair或piecewise_construct。
为什么try_emplace比emplace和insert更安全？
因为try_emplace只在键不存在时才构造值对象，避免了重复构造+析构的开销，也绕过了emplace可能触发的“先构造再移动/拷贝再丢弃”的陷阱。尤其当值类型构造代价高（比如含std::string、std::vector或自定义资源管理类）时，这个差异会直接体现在性能和异常安全性上。
常见错误是误用emplace：传入键和值参数后，即使键已存在，emplace仍会先构造值对象，再发现冲突、销毁它——这不仅浪费，还可能在构造中途抛异常导致逻辑错乱。
-
try_emplace第一个参数是键，后续参数**仅用于构造值**，且仅当键不存在时才调用 - 键已存在时，返回
std::pair<iterator bool></iterator>中bool为false，iterator指向现有元素，值参数完全不参与任何构造 - 不支持用
std::piecewise_construct——如果需要分段构造键和值（如键本身也要惰性构造），得回退到emplace并手动检查
try_emplace的正确调用方式与参数传递细节
调用形式固定为：map.try_emplace(key, arg1, arg2, ...)，其中arg1, arg2...会被转发给值类型的构造函数。注意：键是单独传的，不参与值的构造。
典型误用：把整个std::pair当参数传——这会触发编译错误或意外调用pair构造而非值构造。
- ✅ 正确：
cache.try_emplace("user_123", 42, "active")→ 假设值类型是UserInfo(int, std::string) - ❌ 错误：
cache.try_emplace("user_123", std::make_pair(42, "active"))→ 编译失败或隐式转换歧义 - ⚠️ 注意：如果值类型只有默认构造函数，
try_emplace("key")合法；但若值无默认构造，则必须提供足够参数
和insert + value_type对比时容易踩的坑
insert({key, value})或insert(std::make_pair(key, value))会强制先构造value（甚至可能拷贝），再插入——即使键已存在，value也白造了一次。而try_emplace彻底规避这点。
另一个隐蔽问题：insert接受std::pair<const key value></const>，但若Value构造涉及临时对象（如std::string("hello")），这些临时对象的生命周期只撑到完整表达式结束，而insert内部可能延长其使用（尤其在异常路径下），引发悬垂引用。
-
try_emplace的参数是右值引用转发，生命周期由容器内部控制，更可靠 - 若值类型不可移动（仅可拷贝），
insert可能触发额外拷贝；try_emplace仍只构造一次（且仅在必要时） - 对
std::map<k std::unique_ptr>></k>这类类型，try_emplace(k, new T)比insert({k, std::unique_ptr<t>(new T)})</t>更简洁且无冗余分配
什么时候不该用try_emplace？
不是所有插入场景都适合——核心限制在于：它不支持“键不存在则插入，存在则就地修改值”的原子操作。如果业务逻辑需要“查-改-插”三步合并，try_emplace无法替代operator[]或find+insert组合。
- 需要覆盖旧值？用
map[key] = value或insert_or_assign（C++17） - 键类型没有
operator或不可比较？<code>try_emplace照样报错，和别的方法一样 - 值类型构造函数是
explicit且参数不匹配？编译失败，需显式转型，而insert有时能靠隐式转换蒙混过关（但这反而是隐患）
最常被忽略的一点：try_emplace返回的iterator指向的是**新插入元素或已有元素**，但它的second成员（即值）永远是原值——不会自动更新。想更新必须手动赋值，这点和operator[]的行为本质不同。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
