Bech32m 不能与 Bech32 混用，根本原因在于它们的校验和算法不兼容，且比特币地址格式的规范要求按隔离见证（SegWit）版本严格区分编码方式：版本 0 的地址（P2WPKH、P2WSH）必须用 Bech32，版本 1 及以上的地址（包括 Taproot 的 P2TR）必须用 Bech32m。一条有效的 Bech32 字符串和一条有效的 Bech32m 字符串，即使长度相同，也至少会有三个字符不同，不可能同时通过两种校验。允许混用会直接削弱地址的错误检测能力。
为什么不能"两个都认"
BIP350 在解释为什么不允许版本 0 地址同时接受 Bech32 和 Bech32m 时，给出的理由很具体：允许两种编码共存，会让校验和的有效位数等效于只剩 29 位，而不是原本设计的 30 位。地址校验的核心价值在于，当你手抄或复制粘贴地址时，一个字符的差错能被大概率拦截。混用规则相当于主动降低这道拦截的灵敏度。
钱包软件的解码逻辑也印证了这种不兼容是设计上的硬性要求。以常见的实现为例，解码器会先尝试验证 Bech32m 校验和，失败后再尝试 Bech32，然后根据解出的见证版本号做二次检查：如果版本是 0 但用了 Bech32m，抛出错误；如果版本大于等于 1 但用了 Bech32，同样抛出错误。编码方式与版本号必须配对，没有"都可以"的余地。
为什么需要 Bech32m 这个新格式
Bech32 在 2017 年随隔离见证引入，但它有一个后来才被发现的弱点：当字符串的最后一个字符是 p 时，在它前面紧邻的位置插入或删除任意数量的 q 字符，校验和不会被破坏。这个插入弱点在版本 0 的地址上影响有限，因为 P2WPKH 和 P2WSH 地址的长度是被锁定的，攻击窗口很窄。但对于未来可能引入的新版本地址，长度限制不再那么死板，这个弱点就可能被利用。
Bech32m 的修改幅度极小：只改了校验和计算中最后异或的那个常数，从 1 换成 0x2bc830a3，其他编码规则全部保持不变。这个改动足以消除插入弱点，同时保留了 Bech32 对替换错误的检测能力。
如果钱包不区分，会发生什么
BIP350 的兼容性章节记录了一个关键判断：在 Taproot 提案的实验中发现，几乎没有钱包和服务支持向更高版本的隔离见证输出付款，而部分实现如果在收到版本 1 地址时按旧规则处理，可能导致用户资金被销毁（burn funds）。这正是选择"干净断裂"而非"兼容过渡"的实际理由——让新地址与旧的 Bech32 校验不兼容，旧软件在遇到 Bech32m 地址时会直接报错拒绝，而不是"看似成功"地把币打进一个它无法正确理解的输出里。
反过来，新软件在解码时同时支持两种校验算法，是为了能读旧地址；但它必须根据解出的版本号来判断编码是否匹配，不匹配就拒绝。这种"读得懂，但不认错"的设计，是混用不被允许的技术实现方式。
对你意味着什么
作为用户，你不需要手动判断一个地址该用哪种编码。钱包在生成地址时会自动按版本选择正确的格式。你需要留意的是发送环节：如果你使用的钱包或交易平台版本较旧，在向一个 bc1p 开头的 Taproot 地址（版本 1，Bech32m）转账时，它可能无法识别或提示地址无效。这不是地址错了，而是发送方的软件还没有更新到支持 Bech32m。此时不要尝试用任何方式"绕过"校验，也不要把地址改成 Bech32 格式去试——那只会导致交易被网络拒绝或资产损失。更新钱包软件，或者换一个确认支持 Taproot 地址的发送渠道，是唯一正确的处理方式。
参考资料
- Bitcoin BIPs·BIP 350: Bech32m format for v1+ witness addresses，2026-10-26
- Bitcoin Optech·Bech32(m)，2026-10-26
- Bitcoin.org·BIP 350，2026-10-26
