直接用std::vector存叶子会导致o(n)重建，因无法局部复用；需指针树结构+dirty标记+自底向上懒更新，并严格对齐目标链的哈希算法、字节序与并发控制。
为什么直接用 std::vector 存叶子会卡在增量更新？
因为每次插入新叶子，传统实现要重算整棵树——从叶子层一路向上逐层哈希，时间复杂度是 O(n)。实际场景里，一笔交易进来就重建整个树，吞吐立刻崩掉。
真正可行的增量更新，得让节点能「局部复用」：只重算从新叶子到根路径上的那些父节点，其余分支保持原哈希值不变。
- 必须用指针或索引管理父子关系，不能靠数组下标硬推（比如
parent = (i-1)/2在动态增删时失效） - 推荐用带父指针的二叉树结构，每个节点存
hash、left、right、parent四个字段 - 叶子插入位置不是末尾追加，而是按「完全二叉树」逻辑找空位：从根开始，优先填左子，再右子，保证结构紧凑
MerkleTree::addLeaf() 怎么避免重复哈希已计算过的节点？
核心是懒更新 + 自底向上标记。新增叶子后，只把它的父节点设为「dirty」，后续每次访问该节点的 hash 时才触发重算，并同步标记它的父节点为 dirty —— 这样多次连续 addLeaf() 不会反复重算同一层中间节点。
- 每个节点加一个
bool dirty字段，初始为true；只有被getHash()调用且dirty == true时，才重新拼接子哈希并计算自身 - 注意：如果叶子支持删除，还得维护子节点数量（
childCount），否则单子节点的父节点哈希规则和双子不同（比如以太坊要求单子节点先哈希自身两次） - 别用递归重算整条路径——容易栈溢出；改用 while 循环从叶子往上跳
parent指针
用 SHA256 还是 Keccak256？校验时字节序和填充怎么对齐？
区块链上下文里，默克尔根必须和链上一致，否则校验永远失败。以太坊用 Keccak256，比特币用 SHA256(SHA256(...))，选错算法等于白做。
立即学习“C++免费学习笔记（深入）”；
- 确认目标链的哈希函数和输入格式：比如以太坊对单叶子先做
Keccak256(0x00 || leaf_data)，拼接两个子哈希时是Keccak256(left_hash || right_hash)，不是裸拼 - C++ 用 OpenSSL 或 CryptoPP 库时，默认输出是大端字节序，但某些链（如早期比特币实现）要求反向字节序（little-endian）再哈希——得手动
std::reverse()哈希结果 - 测试时拿已知区块的交易哈希列表，跑一遍你的树，比对根哈希是否等于
eth_getBlockByNumber返回的receiptsRoot或transactionsRoot
为什么多线程并发 addLeaf() 会出错？
因为节点 hash 计算依赖子节点状态，而多个线程可能同时修改同一父节点的 left/right 指针或 dirty 标志，导致哈希不一致或空指针解引用。
- 最简方案：对整个树加一把
std::shared_mutex，读操作用lock_shared()，写操作用lock()—— 别图省事用std::mutex，否则getRootHash()也会阻塞addLeaf() - 更优但复杂：用 CAS 操作原子更新节点的
hash和dirty，但要求所有哈希计算无副作用、幂等，且底层哈希库线程安全 - 切记：哈希计算本身耗 CPU，别在锁内调用
EVP_DigestFinal_ex()这类慢函数——先释放锁，算完再加锁更新字段
增量更新真正的难点不在算法，而在哈希函数选择、字节序处理、并发控制这三处细节。漏掉任意一个，树看起来能建，但跟链上根对不上。
