业务流程大致是需要小程序端与服务端建立长链接，然后有多次数据交互，即：小程序发送 - 服务端接收 - 服务端发送 - 小程序接收 如此循环。 而在这个过程中，每一次的数据交互对延时要求非常高，不能超过 90ms。即小程序发送信息到小程序接收返回信息的过程不能超过 90ms，超过时间则信息的会被判断失效。 为此都分别使用过WebSocket、TCPSocket来建立长链接通信，在网络特别好（5G、WiFi）时没有问题，网络稍差点时，出错率非常高，发现都是超时导致的。注：是在发布的版本、预览调试模式时，并非真机调试模式。 在 4G 网络情况一般的环境下，通过服务器、抓包分析： 服务器在接收、处理、发送信息的过程一般用时就 4、5ms 抓包手机通信，发送、接收过程在 10ms 左右 但在小程序的 socket 中反应出来的时间就有 100+ ms，且浮动范围大，有时能达到3、400。 目前怀疑是因为在微信框架里的原因，即通信需要通过微信的服务器转发：小程序 <——> 微信 <——> 开发者服务器。 所有增加的耗时，感觉都是因为在微信官方哪儿转了一遍（估计因为要监控信息），但我不介意，关键是效率不要这么离谱行不行，或者搞个异步\开个其他线程，我收我的信息，你收集你的！！！ 请官方出来解释一下哇。（抱拳~~~） 另外，也希望遇到过这种问题、有解法的大佬能不吝赐教。（抱拳~~~）

在开发插件时，miniprogram 文件里登录的是开发者的测试号，即在开发时测试号作为插件的宿主小程序。 然后插件中通过 wx.pluginLogin 拿到微信用户登录 code 后传给后台，后台服务器调用 wx.getPluginOpenPId 换取用户唯一标识 openid。这个过程中 wx.getPluginOpenPId 报服务器错误，即无法获取 openid。 经测试，若宿主小程序为非测试号，则可正常运行。 但如此给插件开发造成了极大不便之处，官方出来表下态！！！希望尽快修改下！！！

NfcA.connect()、NfcB.connect()，执行时都是失败， 返回错误没有错误代码，只说 connect:fail:not supported [图片] 我猜的话，应该是手机的问题，换一个好点的手机就能连接成功。 但这个手机是有 NFC 功能的，想知道当前这个问题是什么原因，不然只晓得有些手机可以，有些不行，这个不好交代啊。 求助大佬萌，帮忙指点下迷津