活动页分享到群里，标题成了一串英文参数，缩略图还是灰色的默认图——客户看到截图当场就炸了。这个锅多数时候不在美工，而在微信公众号开发里JS-SDK签名的配置，一个经常被留到最后一晚才处理的环节。
invalid signature的常见来源
签名报错排第一的原因，是参与签名的URL和当前页面URL不一致。安卓拿的是进入页面时的地址，iOS在某些入口会缓存首次地址，页面做过跳转或带hash路由的，两边极易对不上。正确做法是前端把当前完整URL去掉#号后面的部分传给后端，后端按这个算签名。第二常见的是jsapi_ticket缓存没做好，ticket和access_token一样有有效期和调用限制，每次现取迟早出事。第三是时间戳单位错了，秒不是毫秒，这种低级错翻车一次能记一辈子。还有一种少见但存在的情况：页面被微信内置浏览器缓存了旧JS文件，加个版本号参数强制刷新，能省掉一场乌龙。
分享卡片的三个字段
签名通了之后，用updateAppMessageShareData和updateTimelineShareData分别配置发给朋友和分享到朋友圈的内容。标题控制在两行以内，把利益点放前面；描述补一句活动规则；图片用300乘300左右的正方形，比例不对会被裁切。这些字段要在页面加载完成后立刻配置，别等用户点了分享按钮才注册，会来不及。另外别忘了，分享链路的落地页要和卡片承诺一致，标题写着领福利点进去却找不到，用户举报一次，后续分享的展示就受影响。
缓存刷新的时机别忽视
代码发布后有个经典事故：新版本上线，签名还是老的，用户分享出去全乱码。原因是jsapi_ticket在服务端缓存着，发布不会自动清。养成习惯，每次发版后手动刷一次缓存，或者缓存过期时间设短一点，高峰活动期间宁可多请求几次，也别让旧签名撑到活动结束。
- 签名URL由前端实时传，别用后端写死的地址
- access_token和jsapi_ticket统一缓存，集中刷新
- 上线前用真机在安卓、iOS各测一遍分享链路
- 发布新版后手动刷新ticket缓存，防止旧签名残留
分享是H5活动免费的传播渠道，卡片难看等于主动放弃流量。自查有个土办法：把页面链接发给自己，看卡片显示对不对，十秒钟的事，别等用户截图找上门才发现，那是最被动的方式。这类签名和缓存问题排查有套路，比格网络这些年做微信公众号开发处理过的活动页没有一百也有八十，上线前让有经验的人过一遍，能把最丢脸的环节守住。签名这套东西看着繁琐，配顺了一次之后就不用再碰，怕的就是从来没配顺过，每次活动都现查。
