吐槽贴-微信公众号那些让人想起神兽的坑

       

　　  恍惚之间，距离上次写博客已通过去差很少两个月了。最近忙成狗，自从书出版后关注微信接口的时间就不多了，一方面，公司的事情实在太忙，如今是求生存的阶段，只能一心扎在项目中。另外一方面，书发行后，好像忽然少了点继续关注微信的动力，一种被微信折磨了大半年而后终于释然的感受。最近也不多在群里说话了，但也一直关注着群里的动态。看着那些被微信一次次坑的体无完肤、茶饭不思的小伙伴，内心顿时一群神兽（羊驼）飘过，但我有时也挺力不从心的，虽然他们问的问题我基本上都遇到过，大部分也都解决过，也都帮早进群的伙伴解决过，但每次仍是有不少人络绎不绝地问着重复的问题，回着回着就麻木了，由于好屡次都是回复一样的问题。也曾试着改变这种局面，个人作法是这样的：首先提供一个能够问问题的论坛，让有问题的同窗把问题发到论坛里，而后把帖子地址发到群里，而后我再去群里回复，这样下次再有人问相同的问题时，就能够直接把连接地址发他了。但貌似绝大多数人仍是以为麻烦，如今论坛也没多少人气了，也怪我本身没有运营的经验。

         额，貌似废话有点多，开始讲重点吧，这篇博客是在开发的过程当中一些比较常见的bug了，或者说是微信设计不合理的地方，我相信有不少人都想吐槽下微信，但我一直没在园子里看到相关吐槽的博客，鄙人不才，献丑了。（这些只是目前我能想到的，以前遇到的坑基本上没整理，之后尽可能都整理下，先发一部分吧。）。

1、素材管理中的修改永久图文素材接口

这个接口其实不能说是bug，只能说是设计上的缺陷（从个人角度来看）。下面是此接口的文档截图：

 

从上图能够看出，要调用此接口，须要传的参数有media_id（表示一条图文的id），index（表示要修改的某条子图文的索引），articles（表示的图文实体）。表面上看上去没什么不对，修改一条图文素材，须要传一个素材的ID，这是毋庸置疑的，要修改哪条子图文，那就须要把对应的索引传了，貌似也没问题，问题是修改的内容为何要用articles呢，这里已经写了索引了，那就应该是article了，表示的是修改某条多图文中的指定索引的自图文。感受有点绕了吧。不要说我纠结，再仔细想一想，若是我添加多图文消息时，添加5条子图文，那么我如今想修改这个多图文，我想加一个，变成6条子图文的多图文，我发现这个接口没法知足了，由于这里要传的参数有index（索引），找遍了全部文档，也没办法解决这个问题。我也已经无力吐槽了。

2、上传图文素材后，不返回图文url。

这个接口也是设计上的缺陷。你们用过微信图文消息的应该都知道每一条多图文的子图文都包含n（n<=10）个子图文，每一个子图文都有一个对应的url（形如：https://mp.weixin.qq.com/…………），按理说添加图文消息成功后，对应的url应该也已经生成了，但坑爹的是，当咱们调用完添加图文消息接口时返回的信息却只有一个media_id，若是您想获取子图文对应的url，则必须根据media_id调用获取永久素材接口来进行获取。获取永久素材接口这里还有一个大坑，你们能够去试试看。新增图文素材时每个子图文都是须要一个缩略图的media_id的（调用上传图片素材接口进行获取的，形如DFJDFUIEUIURFEORHHz……之类的，反正就是一串比较长的字母数字组合），坑爹的话，当根据多图文的media_id调用获取永久素材接口时，每一个子图文对应的缩略图的ID神奇的编程了一串相似于时间戳的数字。坑爹至极。

3、测试帐号调用群发无权限

这个绝对是个bug，相信确定也坑过很多人。 我记得以前这个接口是没问题的，不知道从何时出现问题的。来讲说具体的问题吧。因为群发这个接口在开发测试的时候不太方便使用运营中的公众号，因此大多人都会选择使用测试号来进行测试，但不知道从何时开始调用测试号的这个接口会出现申请的48003错误（user not agree mass-send protocol）意思是用户不一样意这个群发协议，也许部分人应该会留意到，在刚刚申请的公众号第一次使用群发功能时，须要赞成一个协议，你们点赞成就能够了。坑爹的事，测试公众号没有这个入口啊，我想赞成也没办法赞成啊。真是心累的。

4、添加客服时，不能添加头像。

这个也是无力吐槽的设计上的问题，简单说下吧。我不知道你们设计程序的时候习惯。在建立一个用户或者一个客服时，我确定会把用户的用户名，密码，头像等其余信息一个接口实现，由于这些都是基本信息（前台面向客户的产品上可能会设置头像或注册会分开，可添加客服这功能有必要要分开设置吗？），微信他们本身提供的后台再添加新客服的时候就是工号，昵称，头像，密码等信息一块儿设置的，不明白为啥写的接口是分开的，表示心塞的不行了。上图看看：

 

5、微信支付相关接口

微信支付的坑不知道坑了多少码农的时间（原本能够撸下其余的，却不得不撸代码），终于废了九牛二虎之力解决了签名错误的问题，感受天都亮了。但当遇到js报fail时，感受整我的都很差了。从签名错误到chooseWXPay:fail（有的时候这个fail都不显示，干脆没任何反应，或者闪一下loading，就没了），再到异步回调和js回调，真是一坑更比一坑深啊。运气好的搞个三两天搞好了（笔者先后调试了两个晚上），运气很差的恐怕要一个星期，还不必定能搞的定，最后颇有可能会被某些眼高手低的技术领导或者不懂技术的老板嫌弃。心中又是一群神兽飘过，程序员何苦为难程序员呢。

还有一个你们可能不多遇到的状况，在微信支付的部分接口里出现了诸如****_$n的参数，以下图所示：

 

我以为这个真的要骂街了，微信支付使用的xml格式在进行签名时，比较好的方法就是现建立对应的实体，而后进行下一步的签名，获取返回值时将xml转换成对应的实体也方便进行开发。坑爹的是，这个$n符号让咱怎么建立对应的实体映射，nnd，这个n仍是不固定的。

6、微信支付相关配置

或许不少人在这里也跌了很多跟头，明明代码没问题，彻底按照文档作的，什么预支付id之类的都获取到了，js调用也没问题，但就是否是fail错误就是没任何响应，想一想都记得抓狂。这里说下我遇到的几个坑。

首先是受权目录的设置，官方的说是是，加入你的支付目录是http://www.cnblogs.com/a/a.aspx，那么受权目录应该设置成http://www.cnblogs.com/a/，也就是发起支付的上一层目录。之前在没有用angularjs时，这个说法彻底没问题，用了angularjs才发现再一次被微信坑。用过angularjs作单页程序的朋友应该都知道，每一个页面的切换其实只是切换了view，而页面没有真实的跳转，只是根据#后面的信息来加载不一样的view，如首页的地址若是是http://www.cnblogs.com/index.aspx#/，那商城页有可能就是http://www.cnblogs.com/index.aspx#/shop，支付页面多是http://www.cnblogs.com/index.aspx#/pay，正常的理解是这个受权目录应该就是根目录（http://www.cnblogs.com/），的确如此，在ios上没有任何问题，但是在安卓的机器上就必须是http://www.cnblogs.com/index.aspx#/，假如你发起支付的页面url是http://www.cnblogs.com/index.aspx#/a/b/c，那么你须要设置两个受权目录：http://www.cnblogs.com/index.aspx#/和http://www.cnblogs.com/index.aspx#/a/b/。

还有一个很难被发现的坑。说说我是怎么发现的吧。个人一个客户作了一个商城，这个商城是使用一个认证了的服务号作的，而且开通了微信支付。付款什么都没问题了，但他的需求是想让他的订阅号也能够有这个功能，我当时想的是这很简单嘛，只须要将那个商城的连接搞过来就好了，从订阅号里跳转进来应该也是同样的，支付的时候仍是使用原有的服务号对应的商户信息，逻辑上没有任何问题。但以前据说过不能跨号支付的问题，一直没怎么理解，今天就测试了下。首先从服务号里访问连接是能够正常支付的。而后我就试了下从订阅号（未认证）里进入，结果报fail错误，而后以为很奇怪，就到别从服务号进入，发现没有问题能够正常支付，最后我又试了下从认证了的订阅号进入，发现也能够正常支付（微博认证的报fail错误），那如今获得的结论是，微信支付不能挂在未认证的公众号里。准确的说应该是微信网页内支付接口是没办法在未认证的订阅号中进行支付的。

 

7、终极bug，腾讯客服

　　说多了都是泪，每次发现微信的坑时，我老是天真的抱着一种拯救腾讯的思想去跟他们反馈bug，腾讯的客服老是很亲切说一句：“请阅读相关文档”，那时，全世界的羊驼仿佛从我脑海里通过。哎，人艰不拆啊。

　　不过仔细想一想是不是咱要求过高，人家免费给我们用的东西咱是否是应该抱着宽容的心态来共同来创造将来呢？毕竟腾讯给了咱一众码农一个机会，用不了多久咱就会升职加薪、当上总经理、出任CEO、迎娶白富美、走上人生巅峰哒！