仿函数相比普通函数指针具有内联优化、状态封装、模板特化和缓存友好四大优势。其operator()可被编译器静态绑定并内联，支持带阈值等状态的定制逻辑，数据与代码局部性高，且按值传递成本可控；而函数指针调用需间接跳转，无法内联，状态依赖全局变量易致cache miss，转型还损失类型信息。
仿函数能被编译器内联，普通函数指针不能
普通函数指针调用时，编译器通常无法确定最终跳转目标，所以几乎不会内联——每次调用都得走一次间接跳转，有额外开销。而仿函数的 operator() 是具名成员函数，模板实例化后类型固定，编译器在多数情况下能直接内联展开，省掉调用栈帧、参数压栈等动作。
常见错误现象：std::sort(v.begin(), v.end(), &my_compare_func) 传函数指针，性能反而不如 std::sort(v.begin(), v.end(), MyCompare{})；尤其在循环密集或小函数（如比较两个 int）场景下，差距可达 2 倍以上。
实操建议：
- 优先用具名仿函数或 lambda（编译期可内联），避免裸函数指针传给 STL 算法
- 若必须用函数指针（比如动态选择逻辑），至少确保函数体足够大，让内联收益不明显时再权衡
- 用
-O2 -fopt-info-vec-optimized或查看汇编确认是否真被内联（搜索call指令是否消失）
仿函数状态与代码局部性更好，缓存更友好
带状态的仿函数（比如计数器、滑动窗口统计器）把数据成员和逻辑紧挨着放在同一对象里，CPU 缓存行加载时一并命中。普通函数若靠全局变量或外部传参维持状态，数据可能分散在不同内存页，频繁 cache miss。
立即学习“C++免费学习笔记（深入）”；
使用场景：自定义 std::priority_queue 的比较器需访问某个阈值字段；或 std::transform 中累积加权和。
实操建议：
- 把相关状态封装进仿函数类，而非拆成独立变量 + 函数
- 避免在仿函数中持有裸指针或长生命周期引用——对象复制时容易悬垂（STL 算法常按值传递仿函数）
- 若状态较大（如含
std::vector），考虑用mutable+ 懒初始化，或改用std::shared_ptr管理
模板推导让仿函数零成本抽象，普通函数要转型
STL 算法是模板函数，接收仿函数类型作为模板参数。编译器据此生成专用版本，所有调用路径都静态绑定。而普通函数传入时往往需强制转型为函数指针类型（如 bool(*)(int,int)），丢失类型信息，还可能触发隐式转换开销。
参数差异举例：std::sort 对 LessThan{threshold: 100} 和 GreaterThan{threshold: 50} 会生成两套完全独立的机器码；但若都转成同一种函数指针类型，就只能共享一份通用逻辑，且无法针对阈值做常量传播优化。
实操建议：
- 不要为适配 STL 而把仿函数包装成
std::function——那会引入类型擦除开销，彻底抵消优势 - lambda 表达式本质也是仿函数，
[=](int a, int b) { return a > b; }同样享受模板推导和内联 - 若需运行时切换策略，再考虑
std::function，但得接受性能折损
谓词类仿函数在 STL 中默认按值传递，复制成本可控
很多人担心“仿函数带状态，复制会不会很重？”。实际上 STL 要求谓词类（如排序比较器）是轻量、无副作用的——标准明确允许算法内部多次复制该对象。只要你的仿函数不含大内存块或系统资源句柄，复制开销几乎为零。
容易踩的坑：
- 在仿函数里放
std::mutex或FILE*—— 复制后状态不一致，行为未定义 - 成员变量是
std::string且频繁修改 —— 复制可能触发 COW 或堆分配（C++11 后基本无 COW，但仍要留意 small string 优化边界） - 误用
this指针捕获到外部作用域（比如在 lambda 里写[this]() { ... }再传给算法），导致生命周期依赖难排查
真正关键的是设计意图：仿函数不是为了“比普通函数快一点”，而是为了在保持高性能的同时，自然承载状态、参与模板元编程、与 STL 生态无缝咬合。一旦你开始写 std::find_if(..., [state](auto& x) { return x.val > state.threshold; })，其实已经在用它的核心能力了——只是没意识到那背后是编译器静默生成的、带状态的、可内联的类。
