std::initializer_list构造时强制拷贝元素且不支持移动，对非pod类型造成额外开销；其数据仅引用栈上临时数组，生命周期受限，跨作用域易悬垂；应优先用emplace_back或范围构造替代。
std::initializer_list 的拷贝不等于元素拷贝
它本身只是个轻量包装，内部只存两个指针（首尾迭代器），但它的构造会触发所有元素的**临时对象生成和逐个拷贝**。你写 std::vector<int>{1, 2, 3}</int>，编译器先在栈上构造三个 int 临时量，再用它们初始化 std::initializer_list，最后把这仨挨个挪进 vector 内部缓冲区——中间至少一次拷贝（或移动），对大对象就是实打实的开销。
- 对
std::String、自定义类等非 POD 类型，std::initializer_list构造时强制调用拷贝构造函数，无法绕过 - 即使目标容器支持移动语义（如
std::vector），std::initializer_list提供的仍是 const 引用，无法移动，只能拷贝 - Clang/GCC 在 -O2 下会对 trivial 类型（如
int）做优化，但对用户类型基本不优化，别依赖
emplace_back 比 initializer_list 更省，但不能直接替换
想避免拷贝？别一股脑全用 {...} 初始化。对已存在容器，优先用 emplace_back 或 insert；对新建容器，考虑用范围构造而非 initializer_list。
-
vec.emplace_back(1, "hello")直接在容器内构造对象，零拷贝（前提是类型支持完美转发） -
std::vector<:string> v{std::string("a"), std::string("b")}</:string>→ 两次std::string构造 + 两次拷贝；换成v.reserve(2); v.emplace_back("a"); v.emplace_back("b")就只剩两次构造 - 注意：
std::initializer_list是 const 的，所以std::vector<t>{std::move(a), std::move(b)}</t>中的std::move无效——仍走拷贝构造
initializer_list 的生命周期陷阱常被忽略
它绑定的是字面量或临时量，一旦离开作用域就失效。最典型的就是返回局部 initializer_list 或绑定到引用：
auto get_list() { return std::initializer_list<int>{1, 2, 3}; // 错！临时数组生命周期结束，返回悬垂引用 }-
std::initializer_list不拥有数据，只引用一段栈内存（编译器生成的匿名数组），该数组寿命仅限于完整表达式 - 写
const auto& il = {1,2,3};是合法的，因为 c++11 允许延长临时量生命周期；但auto il = {1,2,3};会触发拷贝（转成std::initializer_list对象），而数据仍在原栈帧 - 跨函数传递时，务必确认数据来源是 Static、全局，或已 move 到堆/容器中
替代方案：什么时候该放弃 initializer_list
不是所有场景都适合它。当元素构造代价高、数量大、或需要延迟/条件构造时，initializer_list 反而是性能负优化。
立即学习“C++免费学习笔记（深入）”；
- 初始化含 100+ 个
std::shared_ptr<heavyobject></heavyobject>的容器？改用循环 +emplace_back，避免 100 次无谓拷贝 - 需要根据运行时条件决定是否插入某元素？
initializer_list是编译期确定长度的，做不到；得用push_back/emplace_back - 和
std::vector::assign、std::Array混用时注意：前者接受迭代器范围，后者要求编译期大小，initializer_list在中间卡得不上不下，兼容性反而差
真正要小心的不是语法怎么写，而是“谁在什么时候、以什么方式、拷贝了几次你的对象”。std::initializer_list 看似方便，背后全是隐式拷贝点，而且编译器几乎从不帮你省掉。