minFreq只能在新key插入或旧频次桶变空且等于当前minFreq时更新；直接用freq_to_list[minFreq].empty()会隐式构造空list污染哈希表，应先find再判空；Node必须显式存freq字段，不可依赖链表位置推断。
LFU 缓存中 minFreq 无法 O(1) 定位，本质不是算法没想清楚，而是更新逻辑和数据结构耦合出错了——minFreq 必须只在两个确定事件中变更：新 key 插入、或旧频次桶变空且恰好等于当前 minFreq。其他任何地方主动扫描、遍历或“每次 get 都检查”，都会让均摊复杂度退化。
为什么 freq_to_list[<code>minFreq].empty() 是危险操作
直接写 freq_to_list[minFreq].empty() 看似自然，但 std::unordered_map::operator[] 在 key 不存在时会隐式构造一个空 std::list，污染哈希表、增加哈希冲突，还掩盖了 minFreq 已失效的事实。
- 正确做法永远用
freq_to_list.find(minFreq)先查存在性，再判断是否为空 - 更安全的写法：
auto it = freq_to_list.find(minFreq); if (it != freq_to_list.end() && it->second.empty()) - 若用
std::vector<:list>></:list>替代 map，需配合maxFreq截断（如 > 1000 归入高频桶），避免 vector 无限扩容
minFreq 只能在两个时机更新
它不是“当前所有频次的最小值”，而是“当前非空频次桶中最低的那个”。这个值只会在以下两种情况改变：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
-
put插入全新 key 时，无条件置为1（因为新节点必进freq_to_list[1]，该桶此刻一定非空） -
get或put导致某节点从频次f升至f+1后，若freq_to_list[f]变空 且f == minFreq，才执行minFreq++ - 淘汰后不立即推进
minFreq，而是在下次evict()入口处做惰性校准：while (freq_to_list.find(minFreq) == freq_to_list.end() || freq_to_list[minFreq].empty()) minFreq++;，并加越界防护（如if (minFreq > max_observed_freq) minFreq = 1;）
Node 结构里必须带 freq 字段，不能靠链表位置反推
有人试图省掉 Node::freq，认为“节点在哪个链表里，频次就该是几”。这在并发或复用链表场景下极易出错：链表可能被清空后复用、节点可能被 splice 到错误桶、甚至 freq_to_list 的 key 被重映射——没有显式 freq 字段，minFreq 更新就失去依据。
立即学习“C++免费学习笔记（深入）”；
-
Node至少含：int key、int value、int freq、std::list<node>::iterator it</node> -
it必须在插入链表后立刻赋值，且每次erase或splice后失效，不可缓存跨操作使用 - 避免 false sharing：把
freq放 struct 开头，用alignas(64)对齐，防止与邻近 Node 的freq共享 cache line
真正卡住 LFU 性能的，从来不是链表怎么连，而是 minFreq 和频次桶空置状态之间那层薄薄的同步逻辑——漏掉一次 erase 后的 empty() 检查，或在不该 ++ 的时候多加了一次，整个 O(1) 承诺就崩了。
