坐等楼下来喷楼上😂

@also24 14# 那要这么说，严格意义上的推送是不可能的，但广义上能做到“推送”的行为。
要么 client 变 server ，服务器端按照 client 的方式找 server ，随便推。
或者 client 跟 server 保持密切关系，维持连接，http 长连接，包括这个 IDLE 。
再不济，那就是轮询，ajax ，邮件每 15 分钟检查。

@also24 10# 按照 11#所属的 IDLE ，那也是客户端维持一个服务器端的连接，然后服务器端通知客户端。这个机制遇到应用被杀死、网络变化——即连接断开了，那也是无济于事的。何况文章还说了更多的情况，比如监控多个文件夹，需要创建多个连接，然后就更加复杂了。

其实根本问题还是 server-client 的模式，server 永远不可能主动找到 client 。

一提起萧峰 /乔峰，你们想起谁？
一提起白娘子，你们想起谁？

主要是剧荒（文艺不发达）的年代，一部好剧给我们的印象太深刻了。现在的电视剧，角色<>演员的固化，已经很淡很淡了。

1# 3# 把问题看明白，他的核心点是云主机的流量问题，而不是端口问题。
端口问题可以通过二级域名解决，二级域名走反代，但是走了反代意味着流量都要过云主机。家宽的端口是硬伤，绕不过去，要么端口化，要么云主机流量化。

找个开放 80 、443 的，nignx 上发 HTTP 301 ，但非 http 无效

修正 13# JSON.stringify(---).indexOf(---) > -1
遍什么历。。。

JSON.stringify(---).substring(---) > -1

难道这不是设置邮件 APP 的定时获取，然后开后台以及通知么？
IMAP 和 POP3 都是获取的协议，没有推送的丁点功能。

两张图片，过渡动画擦除
你这图还没有对齐，对齐了效果更好一些。

这么玩，瞬间感觉没有意思了，刚 2 个小时，我还是慢慢折腾吧

别急，MIS ，就是增删改查

这你就没办法控制了，本身 M3U8 就是个顺序执行机制，m3u 就是个顺序播放列表么，你永远无法知道用户什么时候播放下一个视频（因为可以播放可以暂停，除非你不提供暂停机制）。
除非你上负载均衡做运行时均衡，nginx upstream 各类机制，或者 SRS 边缘节点之类的。

相比较，这就是成本问题，你不能既要熊掌又要鱼。