关键在优先队列比较逻辑、左右子树赋值方向、路径拼接顺序三处对齐：需用a->weight > b->weight确保最小堆，左子树赋'0'右子树赋'1'，dfs传值拼接path+'0'避免副作用，且须判空递归、用unsigned char防越界。
哈夫曼树在 C++ 中能正确构造并生成前缀编码，关键不在“写完所有类”，而在于三处必须对齐：优先队列的比较逻辑、节点合并时的左右子树赋值方向、以及遍历生成编码时的路径拼接顺序。任意一处错位，编码就不是前缀码，解压必然失败。
std::priority_queue 的自定义比较必须反向
很多人用 std::greater 或直接写 operator>，结果构建出的树权值小的反而沉底——因为 std::priority_queue 默认是最大堆。哈夫曼要求每次取最小两个，所以必须让最小权值“浮在顶部”。
正确做法是定义一个仿函数或 lambda，返回 a.weight > b.weight（注意是大于号），然后传给 priority_queue 的第三个模板参数：
struct CompareNode {
bool operator()(const Node* a, const Node* b) {
return a->weight > b->weight; // 小权值优先
}
};
std::priority_queue<node std::vector>, CompareNode> pq;</node>
- 别用
std::less或默认构造，它会让大权值先出队 - 节点指针比较时，务必检查
a和b非空，否则调试时可能崩溃 - 如果用 lambda 初始化，需用 decltype 包裹，且不能捕获变量，否则编译失败
合并节点时 left/right 赋值顺序影响编码唯一性
标准哈夫曼编码约定左支为 '0'、右支为 '1'，但很多实现把频率小的当 left、大的当 right，这没问题；可一旦在多节点权值相等时没统一策略，生成的编码表就不可复现。
例如字符 'a' 和 'b' 频率都是 5，若某次 'a' 先入队、某次 'b' 先入队，priority_queue 不保证稳定排序（底层是堆，非稳定），就会导致左右颠倒。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
解决办法只有两个：
- 在
CompareNode中加入第二排序键：比如当 weight 相等时，按字符值或插入序号升序，确保行为确定 - 不依赖字符原始顺序，而是在建树后统一用 DFS/BFS 遍历生成编码，只要遍历逻辑固定，编码就固定
- 避免在合并时做 “if (a->weight == b->weight) then swap” 这类临时判断——它无法覆盖所有相等情况
DFS 生成编码时字符串拼接位置极易出错
常见错误是写成 path += '0'; dfs(node->left, path);，这样 path 是引用传参，递归回来时已被修改，右子树拿到的是带左支字符的 path。
正确方式是传值或使用回溯：
void dfs(Node* node, std::string path) {
if (!node->left && !node->right) { // 叶子
codeMap[node->ch] = path;
return;
}
if (node->left) dfs(node->left, path + '0');
if (node->right) dfs(node->right, path + '1');
}
- 用
path + '0'而非path += '0'，避免副作用 - 必须判空再递归，否则访问空指针会段错误
- 如果字符集含
'\0'或控制字符，别用char存储，改用unsigned char或int作 key
最易被忽略的是：哈夫曼树本身不保存字符到编码的映射，它只是一棵树；真正用于压缩的是那个 std::unordered_map<char std::string></char> 编码表。而这个表是否完整、是否覆盖全部输入字符、是否把 EOF 或填充位也纳入统计——决定了你写的“压缩器”到底能不能还原原文。别急着写文件 I/O，先拿 "aabbc" 这种短串跑通 encode/decode 循环再说。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
