写给银行前端——免输卡号绑卡开发中的坑

背景:地方银行上线微信中的免输卡号绑卡功能，微信文档一惯的仅供参考，虽然拉了群，群内有微信方的技术助手，但一些问题能帮上忙，绝大多数问题还得靠自己推理解决。

直接上干货

坑一：拉起验短方法，不能按照文档写。

也是大意，文档已经写明了“请求示例”，大概就是留下了最终解释权的意思吧。
验短方法属于隐藏的js-sdk，需要像《微信网页开发 /JS-SDK说明文档》中的操作方式，先请求接口验签，然后wx.config，再在wx.ready内调用。而调用方式依旧不是文档中的wx.phoneBindCardVerifySms，而是使用WeixinJSBridge.invoke("phoneBindCardVerifySms", {}）

坑二：拉起验短IOS端报错invalid signature
如果前后分离项目并且双方都是首次开发微信绑卡，则大概率遇此坑。
免输卡号绑卡页面参数很长，且有类似于“+”、“==”、等特殊符号。正常获取微信签名的接口入参传window.location.href.split("#")[0]就可以，但这种参数很长且有特殊符号的情况下，IOS端会报错。debug模式下可看到realAuthUrl...errMsg:'config:invalid signature' 由此可推断大概率为url入参的问题。
首先取后端加工signature的各个字符串在微信提供的验证signature正确性的工具页面验证，得到结果是加工方式是正确的，结果也是正确的。那么为什么验证失败呢？那就从debug提示的另一条重要信息入手，realAuthUrl。对比发现：realAuthUrl与加工signature使用的url是不同的，前端传入的url入参经过浏览器自动编译，出现了一些%号等符合，原本的“+”等也被转译了。而realAuthUrl是原本的URL参数字符串。由此可得：微信与IOS端交互时，取用的url参数是未经转译的原本URL参数。然后后端同学对收到的url入参进行加工，decode后“+”需要手动再转一下。验证：IOS通过，安卓通过。（安卓是全自动的，怎么着都行）