哈夫曼树构建必须用priority_queue实现小顶堆，时间复杂度O(n log n)；编码表生成须用DFS递归，避免BFS拼接错误；字符统计需用unsigned char防符号扩展；同频节点顺序不影响最优性但影响编码一致性。
哈夫曼树构建必须用 priority_queue，别手写排序队列
手动维护一个按权值升序排列的节点列表，在每次合并后重新插入、再排序，不仅代码冗长，而且时间复杂度会退化到 O(n²)。C++ 标准库的 priority_queue（默认大顶堆）配合自定义比较器，能天然支持小顶堆语义，让每次取最小两个节点的操作稳定在 O(log n)。
常见错误是直接用 priority_queue<node></node> 却没重载 operator，或误以为默认就是小顶堆——其实它是大顶堆，必须显式传入 <code>greater 或自定义仿函数：
struct Node {
int freq;
char ch;
Node* left;
Node* right;
Node(int f, char c) : freq(f), ch(c), left(nullptr), right(nullptr) {}
};
auto cmp = [](const Node* a, const Node* b) { return a->freq > b->freq; };
priority_queue<Node*, vector<Node*>, decltype(cmp)> pq(cmp);
- 节点指针入队，避免拷贝；出队后记得
delete释放（除非用智能指针） - 频率相同时无需额外排序逻辑——哈夫曼算法对同频节点顺序不敏感，不影响最优性
- 若输入只有 1 个字符（如压缩单字符文件），需单独处理：直接生成编码
"0"，不能进 while 循环
编码表生成必须用 DFS 递归，BFS 容易漏位或错序
从根到叶子的路径决定编码（左 0 右 1），DFS 天然携带路径状态，每到叶子就存下当前 string 编码；BFS 虽可实现，但需同步维护每个节点对应的编码字符串，容易在入队时拼接错误，尤其遇到空子节点时边界混乱。
递归写法简洁且不易错，关键点在于：参数传引用避免字符串重复拷贝，叶子判断用 !node->left && !node->right，而非只判 node->ch != '<p>递归写法简洁且不易错，关键点在于：参数传引用避免字符串重复拷贝，叶子判断用 <code>!node->left && !node->right，而非只判 node->ch != '\0'（内部节点也可能被赋值）：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
void generateCodes(Node* node, string code, unordered_map<char, string>& codes) {
if (!node) return;
if (!node->left && !node->right) {
codes[node->ch] = code;
return;
}
generateCodes(node->left, code + "0", codes);
generateCodes(node->right, code + "1", codes);
}
- 初始调用为
generateCodes(root, "", codes)，空字符串起步 - 若字符集含
'\0'（比如二进制数据），不能用char做 key，应改用unsigned char或int - 编码表大小严格等于叶节点数，即不同字符数；重复字符在建树前已统计合并，不会多映射
贪心选择性质在这里很“脆”，别在中间改频率或重排
哈夫曼算法的贪心本质是：每一步都选当前可用的两个最小频次节点合并，新节点频次为二者之和，并放回候选集。这个“当前可用”意味着——一旦某节点被取出，就不能再参与本轮比较；合并后的新节点必须参与后续轮次。任何试图跳过最小、或提前把高频节点拉进来合并的操作，都会破坏最优子结构。
- 典型错误：遍历
priority_queue查最小值（它不支持遍历），或用top()取两次却不pop()，导致重复使用同一节点 - 正确流程只能是：pop 两次 → 合并 → push 新节点 → 直到队列只剩 1 个
- 若输入频次含负数（虽不合理），
priority_queue仍会按数值排，但哈夫曼理论要求权值非负，否则无意义 - 浮点频率？不行。标准哈夫曼要求整数权值（或可缩放为整数），否则
double比较可能因精度失效
实际编码时字符类型要小心 signed char 的符号扩展
读文件统计频次时，如果直接用 char c = f.get()，在某些平台（如 x86_64 Linux GCC）下，char 默认是 signed，当读到字节 0xFF 时会变成 -1，作为 unordered_map 的 key 就和 (unsigned)255 冲突。结果就是 0x80~0xFF 的字符全被映射到负数区间，编码表缺失一半。
- 安全做法：统一用
unsigned char存储和索引，例如freq[static_cast<unsigned char>(c)]++</unsigned> - 输出编码字符串时，也需用
static_cast<unsigned char>(ch)</unsigned>查表，避免符号截断 - 如果只处理 ASCII 文本（0–127），这个问题不暴露，但一处理 PNG、ZIP 等二进制数据就立刻崩
构建完成的哈夫曼树本身不保存字符集顺序，也不隐含字典序；编码是否唯一取决于建树过程中对同频节点的左右分配策略——这在实际压缩中无关紧要，但调试时若发现相同输入产生不同编码，大概率是 priority_queue 对同频指针的地址比较引入了不确定序，加个稳定比较（如比指针地址）就能复现一致结果。
