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 楼说得更清楚

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