为何C++中std::function::operator=始终构造而非赋值对象？

核心差异：类型擦除的本质限制 #

std::variant是有界类型多态，它的所有可能类型都在编译期确定，因此当左右操作数类型匹配时，编译器可以直接定位到对应类型的赋值运算符，完成原地赋值。

但std::function和std::any属于无界类型擦除：

• std::any可存储任意可拷贝/可移动的类型，编译期无法预知当前存储类型或待赋值的新类型；
• std::function擦除了可调用对象的具体类型，仅保留调用签名。

这种特性导致“直接赋值”存在无法解决的问题：

1. 类型匹配检查的额外开销：每次赋值都需要运行时对比类型ID，增加不必要的性能损耗；
2. 兼容性受限：并非所有类型都提供合法的赋值运算符（比如禁用赋值的类型），而std::function和std::any的设计目标是兼容所有符合要求的类型，依赖赋值运算符会缩小适用范围；
3. 异常安全风险：直接赋值过程中若抛出异常，原有对象可能处于破坏状态。而“构造临时+swap”是强异常安全的：临时对象构造成功后才执行swap，若构造失败，原有对象完全不受影响。

带小对象优化（SOO）时用swap处理赋值的原因 #

实现带SOO的std::any或std::function时，对象存储分为两种情况：小对象直接存在内部缓冲区，大对象分配在堆上。用swap处理赋值有以下关键优势：

• 统一实现逻辑：无需区分小对象/大对象的存储情况写不同分支，swap可以统一处理两种场景，简化代码维护；
• 降低内存管理复杂度：小对象场景下，swap缓冲区比“析构原有+构造新对象”更高效（比如POD类型的swap是字节级拷贝）；大对象场景下，交换堆指针几乎是O(1)操作，避免了额外的内存分配/释放；
• 延续异常安全：临时对象的构造逻辑已经包含了小对象直接构造、大对象堆分配的处理，而swap操作本身是noexcept的（指针交换、缓冲区字节交换均无异常），确保整个赋值过程的强异常安全。

最佳实践 #

• 坚持“构造临时+swap”范式：不要试图为类型匹配的场景做特殊优化——除非你能证明类型检查的开销远大于析构+构造的成本，且目标类型均支持赋值。标准库实现通常不会这么做，因为要保证通用性和异常安全；
• 确保swap的无异常性：自定义实现时，内部swap必须是noexcept的，才能保证整个赋值操作的强异常安全。比如小对象缓冲区用std::swap（POD类型天然noexcept），大对象直接交换堆指针；
• 利用移动语义优化临时对象构造：赋值右值时，优先用移动构造创建临时对象，减少不必要的拷贝开销。

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