1 无脑堆机器 不行

2 大量用户 是多少 稍微多一点人 AC就是一具尸体了

3 这个不是框架能保证的 需要自己实现

AC 不知道客户端死活，可重复进入，并发差 这看起很可靠吗？

我的意思就是Pheonix Channel一开始就解决了这些问题。

至于为什么，不好意思我没研究过。

因为我用AC 和 PC 分别实现了一个聊天程序，这是我的一些直观感受。

1.ActionCable 只有服务端到客户端的心跳，客户端掉线不知道。这点 Phoenix Channel自带。

2.ActionCable 存在重复进入问题，同一个用户可以多次进入同一个频道.这点Phoenix Channel 自带去重。

3.ActionCable 的订阅机制是基于Redis Pub/Sub, 无法平行扩展，必须要连同一个的Redis存Session。这点Phoenix Channel也是自带的，基于PG2。

4.Phoenix Channel 可以回复给单独一个用户，这点ActionCable做不到，除非单独给用户一个频道。

5.Phoenix Channel 可以支持单机200万并发 可以Google，虽然用的硬件很好，但是也很厉害。据说Ruby 2.7 可以提升ws的并发性能。

6.Phoenix Channel 自带用户在线列表，不需要自己维护，可以在一个集群内监控用户的上下线。

你一定要说Actioncable有一点好，就是太TM简单了,快速出效果还是极好的，真的上线还是推荐Phoenix Channel！！！

http://fitzgen.github.io/erl-ot/ erlang OT算法

其实Phoenix LiveView 也可以实现

一说到可靠性 就不得不吹一波Phoenix Channel

httparty

此乃正解

我来挖下坟，根本原因就是在获取code之前获取了iv和encryteddata，导致secret_key不匹配。 先调wx.login获取到code的之后再调getUserInfo，然后把三个值传回后台就可以了 6楼说得更清楚

不好意思 我照着这个改的 改完还是不行