最稳妥是因为priority_queue（小根堆）天然支持O(log n)插入和O(1)取最小，严格保障贪心选择性质，时间复杂度稳定O(n log n)，避免手写模拟导致的排序不稳定、逻辑错误及性能退化。
为什么直接用 priority_queue 实现哈夫曼树构建最稳妥
因为哈夫曼算法本质是贪心：每次合并频率最小的两个节点。而 priority_queue（默认小根堆）天然支持 O(log n) 插入和 O(1) 取最小，时间复杂度稳定在 O(n log n)。手写链表或数组模拟堆容易漏掉重复频次节点的稳定排序逻辑，导致编码不唯一甚至错误。
常见错误现象：priority_queue 默认是大根堆，忘记传 greater<int></int> 或自定义比较器，结果先合并最大频率节点，完全背离贪心策略。
- 必须用
priority_queue<node vector>, Compare></node>，不能存值，要存指针，否则合并时无法维护父子关系 -
Compare要重载operator()，严格按freq升序；若freq相等，需额外规则（如按字符 ASCII 或插入顺序）避免 undefined behavior - 合并后新节点的
freq是左右子节点之和，左子节点标0、右子节点标1是约定，但必须在建树后统一做 DFS/BFS 遍历生成编码，不能边建边拼接
如何从哈夫曼树安全导出每个字符的二进制编码字符串
建完树只是中间状态，真正要用的是字符到 string 的映射。直接递归遍历比迭代更直观，但要注意：空树、单节点（所有字符相同）这两种边界情况必须单独处理，否则 root->left 或 root->right 解引用会崩溃。
使用场景：压缩前预处理、编码表序列化、调试输出验证前缀性质。
立即学习“C++免费学习笔记（深入）”；
- DFS 递归函数参数必须带当前路径
string& code（引用传递，避免拷贝开销） - 到达叶子节点才写入
map<char string></char>，且只在node->left == nullptr && node->right == nullptr时判断 - 非叶子节点递归调用前分别 push
'0'和'1'，返回前 pop，保证路径正确 - 不要用
stringstream拼接路径——高频调用下分配开销明显；string的+=和.pop_back()更轻量
贪心选择性质在哈夫曼算法中到底怎么被保证
不是“看起来像贪心就对”，而是有严格证明支撑：任意最优前缀码中，频率最小的两个字符必然处于树中最深且兄弟的位置。所以第一步合并它们不会丢失最优性。C++ 实现里这个性质体现在——你永远不能跳过当前堆顶的两个最小节点去合并其他组合。
性能影响：如果误用 vector::min_element 每次扫一遍找最小，复杂度退化为 O(n²)，10⁵ 字符输入就会超时；而堆结构让每轮合并代价可控。
- 每次
pop两个节点后，必须push回一个新节点，且该节点freq精确等于两者之和 - 不能把原字符节点和合并节点混在同一个容器里却不更新比较逻辑——比如用
vector+sort，排序后前面的低频节点可能被后续更高频的合并节点覆盖位置 - 测试时务必用含重复频次的数据（如
"aabbc"），验证是否仍能生成合法前缀码（即任意编码不是另一编码的前缀）
完整可运行源码里最容易被忽略的内存管理细节
所有 new Node 出来的节点，最终必须由用户手动 delete，尤其在频繁构建/销毁哈夫曼树的场景（如流式压缩）。C++ 标准库不负责释放你塞进 priority_queue 的裸指针。
容易踩的坑：在 DFS 生成编码后直接 delete root，但没递归释放子树，造成内存泄漏；或者在 priority_queue 还持有某些节点指针时提前 delete，后续 pop 触发野指针访问。
- 推荐在类封装时用
unique_ptr管理树节点，但注意priority_queue不支持移动语义的智能指针比较器，需额外包装 - 更务实的做法是：建树完成后，用后序遍历一次性释放整棵树，且确保释放前
priority_queue已空（所有节点都被pop过） - 调试阶段可在
Node构造/析构里加计数器或日志，确认 new/delete 成对出现
Node 的数据成员——要不要存 char？要不要存原始频次？要不要区分叶子/内部节点？这些细节一旦定错，后面遍历和释放全跟着错。 
