The ipadchat-api from fastgoo

因登录二维码有效期非常短，服务端没有做清除策略。建议：

1、服务器端直接返回二维码的文本，无需生成图片，由客户端自行生成（可避免暴露服务器端地址）
2、生成后服务器检测二维码的扫码状态，进行清理冗余图片。

登录成功后，获取联系人时失败

登录成功后，获取联系人时失败，如：

哥们来个联系方式

哥们来个联系方式，发我github公开邮箱也可以。

使用 wx_data 和 token 登录，返回状态无效！

采取 token 登录方式会导致接口 -500 和 -2017

重现步骤：

用扫码登录正确获取到 wx_data、token 并持久化存储；
用第 1 步存储的 wx_data 与 token 进行 token 登录（短线重链接），这时返回请求登录成功（但回调地址收不到任何有关 push 的信息，包括 login_success 事件也无法接收到）。
若再实例化，采取 token 登录，则会一直提示-500 和 - 2017

关于登录的建议
账号登录，作为项目/应用保障安全，降低封号风险的重要手段，应严格按照微信设备规则进行交互及校验，也是项目落地的重要环节和因素，毕竟再强大的功能，协议，若无法尽最大可能保障安全，就难以有真正的业务落地。
通过我之前接触的其它类似产品，对登录部分相关的大量实际业务实践，提出以下建议，仅供作者和其它开发者参考：

将登录方式按权重优先级顺序设置为： token、request、qrcode

其中，表现形式为：

token（短线重链）：就是无需确认，无需扫码，直接登录，相当于在 iPad 上按 home 回到桌面，又点击微信进去，所以无需任何验证。
request（二次登录）：无需扫码，需要确认，同意后登录。相当于在 iPad 上登录的设备，被其它设备（如PC，非当前 iPad）挤下线，现在进入微信要手机点击一下同意。
qrcode（二维码登录）：这个场景非常多，如果携带了 wx_data 设备参数，则代表这个 iPad 之前被号主在手机端强制下线或在设备管理里删除了。如果没有携带 wx_data ，一般代表第一次在这个 iPad 上登录。

以上场景仅供参考，注意所有的登录方式都应支持传递 wx_data ，且强列建议非首次登录均传递该值以降低封号风险。