4.
@罐子，哦你说消息推送没反应啊。以后再说吧，今天不想看。
5.
@老虎会游泳，点击上面链接跳这个页面报错https://hu60.cn/q.php/www.minedeed.com
一加8Pro
8.
@罐子，已经交换了提示文字的顺序，希望用户这次能够找到正确的点击位置。
10.
@罐子，我想这样就没问题了。
用户可能注意不到二选一，那三选一的话，应该不可能注意不到吧。
12.
@tasy5kg，目前的问题不是推送失败，是从数据库读取新信息经常失败，用什么推送都没用。要解决问题，可能需要更换新版本的ali canal。
13.
@老虎会游泳，大致瞅了瞅hu60wap6/src/service/wechat-push.php，
为啥不用 redis 列表呢？记得你以前有两台 hu60 主机，是因为这个吗？
14.
抱歉，由于开发人员的各种不小心，该页面在执行过程中发生了一些错误。
错误代码：1404
错误信息：页面 'www.minedeed.com' 不存在
错误发生在 /www/wwwroot/hu60.cn/src/class/page.php 的第 222 行
错误追踪信息：
0 /www/wwwroot/hu60.cn/src/q.php(79): page->load()
1 {main}
16.
@无名啊，redis列表中不可能凭空出现数据，必须要有程序进行写入。我不想进行双重写入（mysql+redis）。
17.
@老虎会游泳，新手，经验不多，整理下想法
看起来，是因为：
-
不想写冗余代码/执行重复操作（实际由 mysql 的 binlog 干了）？
-
微信推送的功能可以相对独立，以后不想要了，不开这个服务就行？
或以后若再来几个QQ/短信/邮箱/GitHub/Gitee/镜像站推送服务，再开几个服务就好？很容易扩展？
感觉这是不是设计模式里的观察者模式/发布订阅模式？
类似 js的addEventListener？安卓的广播接收器？钩子？
只不过是靠监听数据库的更改，从中寻找感兴趣的部分（『发布』了啥？），再执行推送（『订阅』后干啥？）。
若是这样，感觉这个调度有点重。若再来几个服务，每个都在茫茫数据库日志中查找自己感兴趣的部分，无用功是不是做了很多？有点像数据库分表前和分表后的查询……
而且还严重依赖 MySQL。若是有啥功能不依赖数据库（暂时没想到），就用不了这个
说这些，也不是批判啥（反正我又不运行hu60，占用100 GB内存，或每秒扫硬盘一万次，也不关我事。。），只是学习整理下应用场景
18.
@无名啊，
设计模式里的观察者模式/发布订阅模式
是
以后不想要了，不开这个服务就行
是
每个都在茫茫数据库日志中查找自己感兴趣的部分
ali canal 有一个基于表的过滤器，不感兴趣的表的数据不会被它读取
而且还严重依赖 MySQL
我感觉只有一个数据库（mysql）比有多个数据库（mysql+redis+……）好多了。
19.
@老虎会游泳，
ali canal 有一个基于表的过滤器，不感兴趣的表的数据不会被它读取
嗯，我说清楚些，应该是监听的表的所有操作（新增、修改、删除等），都要自己过滤一下。
相比发布订阅模式而言，总会多了点『丢弃不感兴趣的操作』的冗余步骤
我感觉只有一个数据库（mysql）比有多个数据库（mysql+redis+……）好多了。
你是说代码里操控多个数据库的复杂度？就『微信推送』这个功能而言，改造成redis的话，多几十行代码搞得定吗？
若说基础设施体积的话，JRE + canal，比 redis 大多了吧
