存储基类对象时，使用std::reference_wrapper替代指针是否有弊端？

很好的问题！作为经常处理C++容器和多态场景的开发者，我来拆解一下你关心的两个核心点——用std::reference_wrapper存储基类对象的弊端，以及这类vector本身的潜在问题：

• 切片问题依然可能找上门（操作不当的话）：很多人以为用了reference_wrapper就能避免对象切片，但其实切片是对象赋值/拷贝导致的问题，和引用/指针无关。比如你先把一个Derived对象赋值给Base对象，再用std::reference_wrapper<Base>去引用这个Base对象，那它依然是被切片后的基类实例，多态调用会失效——这点和指针的坑是一样的，新手很容易踩。
• 对象生命周期的隐形依赖：和裸指针一样，reference_wrapper只是引用，不拥有对象所有权。但它看起来更像“值类型”，容易让开发者忽略背后的对象生命周期问题。比如你存了一个局部栈对象的reference_wrapper，当局部对象销毁后，vector里的wrapper就变成了悬垂引用，而且reference_wrapper没有空状态，不像指针可以设为nullptr来标记无效，排查这类UB（未定义行为）会比指针更麻烦。
• 无法直接存储临时对象：std::reference_wrapper默认不能绑定到临时对象（强行用std::ref绑定的话，临时对象销毁后立刻悬垂）。这意味着你不能直接在vector里emplace新的派生类对象，必须先在外部创建好对象（比如堆上、全局区或者生命周期足够长的栈区），再把引用传进去，大大限制了使用场景——对比之下，智能指针（比如std::unique_ptr<Base>）可以直接在容器内创建和管理对象，灵活得多。
• 多态类型转换更繁琐：虽然你可以通过get()方法获取底层引用，再用dynamic_cast进行类型转换，但reference_wrapper本身没有提供直接的转换接口。比如你不能直接把std::reference_wrapper<Base>转换成std::reference_wrapper<Derived>，必须先拿到引用、转换成功后再重新包装，比指针的转换流程多了一步。

• 默认初始化和resize受限：std::reference_wrapper没有默认构造函数，所以你不能直接调用vec.resize(10)这种需要默认构造元素的操作，必须提供一个已有的对象作为初始值——而且这个对象的生命周期必须覆盖vector的整个使用周期，否则又会出现悬垂问题。
• “值语义”的误导性：std::reference_wrapper是可拷贝的，但拷贝它只是拷贝引用关系，不是拷贝底层对象。如果你的代码依赖容器的“值语义”（比如拷贝容器时期望元素是独立的实例），那用reference_wrapper的vector会完全不符合预期——拷贝后的vector和原vector引用的是同一批对象，任何对对象的修改都会同时影响两个容器，很容易引发意外的副作用。
• 部分标准库算法兼容性问题：虽然reference_wrapper大多能适配标准库算法，但少数场景会出问题。比如std::sort，如果你的排序逻辑是想交换底层对象的位置，交换reference_wrapper只是交换引用指向，根本不会动到底层对象；另外，有些算法需要创建临时元素，而reference_wrapper无法绑定临时对象，会直接编译失败。
• 调试体验变差：调试时，你看到的是std::reference_wrapper的包装对象，而不是直接的对象内容，必须额外一步去获取引用的对象才能查看数据。在复杂的调用栈和容器结构里，这会增加调试的复杂度，不如直接看指针或者值对象直观。

当然，也不是说std::reference_wrapper一无是处——如果你有一批已经存在、生命周期由外部可靠管理的基类/派生类对象，需要统一管理它们的引用，且不需要容器拥有对象所有权，那它比裸指针更安全（不会出现空指针，除非悬垂），也比指针的语法更接近值类型。但一定要提前意识到上面这些弊端，避免踩坑。

内容的提问来源于stack exchange，提问作者Michael Smith