用户发的消息后台收到了，内容却是一串看不懂的密文；偶尔又能收到明文，时灵时不灵。十有八九是消息加解密模式没配对。这是微信公众号开发里文档写得清楚、实践中却最常配错的一块。
三种模式，先分清
明文模式消息裸传，调试方便，安全性最弱；兼容模式同时推送明文和密文两份，过渡期用；安全模式只推密文，最安全也最考验实现。生产环境建议直接上安全模式，开发调试用明文，两个环境用不同配置即可，没必要在生产留兼容模式。选定后在公众平台后台和代码两边同时改，只改一边就会出现时好时坏的灵异现象。切换前把队列里的存量消息处理完再动，低峰期操作，改完立刻发消息验证，别周五晚上改完就下班。
高频报错对着查
- 签名校验失败：检查token是否与后台一致，时间戳是否用了秒
- 解密后乱码：确认AES密钥的Base64解码方式没搞错
- XML解析失败：收到的报文里可能有特殊字符，用规范的XML库处理
- 偶发收不到：回复超时五秒被微信判定失败，重试机制要留
- 服务器配好NTP时间同步，签名错误少一半
还有一类报错和时间有关：服务器时间漂移几分钟，签名就全错，给服务器配好NTP同步，一劳永逸。还有个隐蔽坑：切换模式的瞬间，队列里积压的旧格式消息会按新逻辑处理，报一波错是正常的，别当成新故障去修。加解密涉及的算法文档里都有参考实现，直接用官方SDK，别手搓，手搓的坑官方文档可不会替你踩。
安全模式的附带收益
密文模式下，伪造消息直接被签名挡在门外，菜单点击、支付通知这些敏感事件的可信度大增。一家做投票活动的客户曾被刷票团伙伪造事件推送，切到安全模式后伪造请求全部失效。顺手把消息接收的日志按天归档，排查问题时按时间段检索，效率完全不同。加解密配置一次做好，长期受益。自查方法很简单：后台发条消息看日志格式对不对，再让同事从不同网络环境各发一条。多环境并行开发的团队还要注意：开发、测试、生产三套环境各用各的配置，加密密钥和token分开管理，别为了图省事共用一套，出了问题排查时互相干扰，浪费的时间远比省下的多。比格网络接手微信公众号开发项目时，这一项永远排在排查清单第一位，配置不对，后面所有的消息逻辑都是空中楼阁，配置检查放进每次发版的例行清单，五分钟的事，换来的是安心。
