用 std::unordered_map 显式传参缓存比 static 更安全线程友好，避免模板实例隔离、数据竞争和生命周期失控，需确保键可哈希且递归统一走缓存分支。
直接用 std::unordered_map 存参数到结果的映射，比手写全局静态缓存安全、线程友好，且避免重复计算——但必须注意键类型可哈希、递归入口要统一走缓存分支。
为什么不能只靠 static 变量做缓存
很多人第一反应是加个 static std::map 在函数里，但这在多参数组合、多线程或模板实例化时容易出错：
-
static变量在模板函数中会为每个实例（如fib<int></int>和fib<long></long>）生成独立副本，但缓存逻辑本应按值语义共享 - 多个线程同时调用同一函数，
static缓存无锁访问会引发数据竞争 - 无法控制缓存生命周期，比如想对某次计算临时禁用缓存，或复用已有缓存对象时束手无策
用 std::unordered_map 手动管理缓存的典型模式
核心是把「输入参数」转成可哈希的键，常见做法是打包成 std::tuple 或自定义结构体。以斐波那契为例：
long long fib(int n, std::unordered_map<int long>& cache) {
if (n second;
cache[n] = fib(n-1, cache) + fib(n-2, cache);
return cache[n];
}</int>
调用时传入一个局部 cache 对象：fib(40, {})。这样既避免全局状态，又支持不同调用隔离缓存。
- 键类型必须满足
std::hash可用，单参数直接用原类型；多参数推荐std::tuple<t1></t1>，它默认支持哈希（C++17 起） - 别用
std::map替代std::unordered_map：查找复杂度从 O(1) 退化到 O(log n)，递归深度大时明显拖慢 - 缓存对象建议按需构造，而非复用长期存活的容器——防止内存无限增长
用 lambda + 捕获实现更简洁的闭包式缓存
如果不想暴露缓存参数，可用 mutable lambda 封装状态：
auto make_fib = []() {
std::unordered_map<int long> cache;
return [=](int n) mutable -> long long {
if (n second;
return cache[n] = (*this)(n-1) + (*this)(n-2); // 注意：需捕获 this 或改用 std::function
};
};</int>
实际中更稳妥的是配合 std::function：
std::function<long long> fib = [&](int n) -> long long {
if (n second;
return cache[n] = fib(n-1) + fib(n-2);
};</long>
- lambda 捕获
cache必须是[&cache]或值捕获后标记mutable，否则无法修改 - 递归调用必须通过
std::function对象（如fib(n-1)），不能直接调用 lambda 名——它没名字 - 这种写法适合封装成工具函数，但调试时堆栈更难读，生产环境建议优先选显式缓存参数方式
容易被忽略的边界点：缓存键的等价性与生命周期
缓存失效往往不是因为算法错，而是键没真正“唯一标识”计算意图：
- 浮点参数慎用——
double直接作 key 会因精度误差导致重复计算；应先 round 或转整数倍单位 - 指针或引用作为键时，缓存的是地址值，不是所指内容；若内容可变，缓存结果就不可靠
- 缓存对象若在递归中途被 move 或析构（比如传入临时
std::unordered_map{}），后续访问会 crash - 某些场景需要带过期机制（如时间戳+TTL），标准容器不提供，得自己包装一层带时间戳的结构
缓存不是加了就快，关键是让键足够稳定、足够轻量、足够贴近你的等价判断逻辑。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
