小程序消息总被折叠？14年运维老手三步重构通讯链路

　　掘金这地方，老运维凑一块儿，真话都夹在句子里吐——去年六月份，我们消息通道又塌了半边，折叠率冲到八成以上，PM 拿着截图蹲我工位三小时，最后那张图上连“服务通知”四个字都缩成三个点，我盯着看十八秒，没动。

　　我原以为是模板库里那个带 emoji 的 fallback 逻辑漏判了，结果翻完全链路日志，发现根本没进模板引擎。消息压根没活到那里。它卡在中间——不是卡在 push gateway，也不是卡在 unionid 映射层，是卡在微信侧下发前最后一道「折叠策略」判定里。这个我敢打包票：你拿同一个 template_id、同一个 openid、同一秒发三次，第一次展开，第二次折叠，第三次又展开。不是你代码的事，是它今天心情不好。

　　第三杯咖啡凉透了，杯底一圈浅褐色渍，像某次灰度失败后监控大屏上滞留的绿光。那绿光持续了三百七十二秒，没人敢点鼠标关掉。我就盯着它，一边等 ops 同事把 redis cluster 里某库某表的过期策略临时改成永不过期，一边在钉钉里跟后端老李互怼：“你确定没在 unionid 后面拼了个空格？”他回：“我拼了你祖宗。” 我回：“那麻烦你祖宗把那段 JSON 响应体里多余的换行删了。”

　　三步？不，第一步是先认怂：承认折叠不是 bug，是规则。第二步才是动手——但别碰小程序端，别改 template_id，别去求运营加白名单。你唯一能动的，是「消息的呼吸节奏」。我们干了三件事：一、把原来按事件触发就立刻推的模式，全切进一个本地队列；二、给每类消息打权重标签（比如“支付成功”标为 S1，“订单提醒”标为 A3）；三、再套一层滑动窗口聚合器，窗口时长四分钟，只对同一用户同类型消息做合并，且合并后必须含一个显式动作引导（“点击查看订单”“立即核销”），不含任何“温馨提示”“友情提示”“小贴士”这种词。这个我说不准，但试跑三天后，折叠率从八成掉到两成，而点击率翻了两倍多——说明用户不是不看，是懒得点三个点再点“展开”。

　　有天凌晨两点，我执行了恢复演练：手动清空某库某表里七千八百条待发状态记录，然后把聚合器窗口临时调到三十秒，观察消息体结构变化。工单号是#OP20240617-093822，挂了一小时五十七分，因为值班开发睡死在会议室沙发上，手机静音，充电线还插着，屏幕一直亮着《Git 提交规范指南》PDF 第 47 页。

　　最烦的是那种“用户未授权，但消息仍下发”的假阳性折叠。其实微信根本没下发，它在服务端就直接丢弃并返回 success=0，但响应包里 status 字段被设成“200”，content-type 是 application/json，body 里却只有 {"errcode":0,"errmsg":"ok"}。你查日志查半天，查到最后发现 errcode=0 和折叠率上升之间，纯属时间巧合。这个细节我反复核过三次，就是个玄学。但凡哪天它真返回了 45015 或 43101，我反而心里踏实——问题可定位。现在这样，你连告警阈值都设不出来。

　　上周我把方案甩给另一个业务线，对方架构师说：“你这不符合我们消息中台设计规范。” 我说：“你们中台是不是还要求所有推送必带 campaign_id？”他说是。“那 campaign_id 是字符串还是数字？”他愣了一下，说“string”。我打开 Postman，往 header 里塞了个 X-Campaign-ID: 0xdeadbeef，再发一次，折叠率降了十五个百分点。他当场把文档链接撤了，五分钟后群里发了个红包，备注是“致敬野生协议解构者”。

　　优胜劣汰？不是靠谁跑得快，是靠谁先认出来——有些淘汰根本没发鸣枪，哨子早被风吹跑了，你站原地等发令，别人已经扛着整个 channel 跳槽到企业微信去了。我们上周刚切掉最后一个小程序订阅消息入口，全量走企微应用+自建 Bot 网关。折叠？不存在的。它连折叠功能都没有，只有一串 raw markdown 链接和自动重试次数上限。运维同事说太糙，我说：“糙点好，糙的东西不容易被折叠。”

　　我现在桌上摆着两台显示器，左屏开着内网复盘通报系统，右屏是 V2EX 某个帖子，标题叫《为什么小程序模板消息的文案长度不影响折叠率》，楼主还在论证“只要用了‘尊敬的’开头就必然折叠”。我没回帖。但我昨天把我们新 bot 的 welcome message 改成了“hi”，首字母小写，没加标点。今天早会，运营说打开率涨了，我点点头，把第三杯咖啡倒进绿植盆里，土面立刻泛起细泡。

文章配图，仅供参考

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!