斐波那契堆的 decrease-key 能达 O(1) 摊还时间，因其延迟修复堆序：仅剪切节点并标记父节点，将整理工作推迟至 extract-min 时通过 consolidate 统一处理，从而将代价摊销。
decrease-key 能做到 O(1) 摊还时间，靠的是“不立即修复堆序”，只做剪切（cut）+ 标记（mark），把结构整理延迟到 extract-min 时统一处理。
为什么 decrease-key 不直接上浮节点
二叉堆里 decrease-key 后必须向上冒泡（bubble-up），最坏要走 log n 层；斐波那契堆反其道而行：只要新值比父节点小，就直接把该节点从父树中“剪下来”，扔进根链表——这步只需改几个指针，left、right、parent、child 的局部调整，没有循环或递归，所以是常数时间操作。
标记（marked）字段的作用不是记录“被减过”，而是控制级联剪切
节点被剪切后，如果它的父节点是“已标记”的（marked == true），说明父节点之前已经丢过一个孩子了，这次再丢一个，就触发级联剪切：把父节点也剪下来，递归向上检查。这个机制防止某棵树退化成链表，保证度数增长可控。关键点在于：
- 新创建的节点
marked初始为false - 节点第一次失去孩子时，设
marked = true；第二次再失去，才被剪切 - 只有被剪切进根链表的节点，
marked才重置为false
extract-min 是真正的“埋单时刻”，decrease-key 的代价在这里摊销
每次 extract-min 都会触发 consolidate：遍历当前所有根节点，用辅助数组按 degree 分组，合并相同度数的树（小根作父，大根作子）。这个过程耗时 O(log n)，但它平摊到了之前所有 O(1) 的 insert 和 decrease-key 上。没有这一步延迟整理，decrease-key 就不可能维持 O(1) 摊还复杂度。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
C++ 实现中容易漏掉的三个细节
写 C++ 版本时，这几个地方最容易出错：
- 剪切节点后，必须更新父节点的
degree（减 1），否则后续consolidate会误判树的度数 - 把节点插入根链表时，不能只连
left/right，还要确保parent == nullptr、marked == false -
consolidate中合并两棵树时，被挂为子树的那个节点，其parent要正确指向新父节点，且marked置为false（新子节点不继承标记）
真正难的不是写对单个操作，而是让 marked、degree、parent 这三者在剪切/合并/提升过程中始终自洽——稍有脱节，decrease-key 的摊还保证就崩了。
