循环创建redis的订阅，为什么一种写法卡在了循环这，另一种则正常？

Question

需求：个人是想法是启动一个进程，通过主进程向子进程中通信，在子进程中用协成redis订阅一个channel，发现这种写法会因为while循环不能订阅。后来换了一个思路 就是先订阅一个主订阅号，通过发布订阅的内容再创建子协成去订阅，发现这个功能正常。第一个问题：现在不明白为什么两个都是有while循环的第二种就能正常？第二问题：一般订阅发布中订阅的逻辑是不是像第二种思路实现不同用户去订阅内容呢？
①第一种方法代码

②第二种写法

Answer 1

Q1:第一个同步阻塞的while($pipe->read())中的局部变量在下一次循环的时候可能被回收/释放，非得这么写的话，猜想变通的办法是订阅的Coroutine放在这个while外面(前面)，$Channel作为全局变量或者类属性可以在while($pipe->read())循环体里被修改，这样俩循环都在跑，go(while(...))里面的循环可以采用另一个循环制造的数据...(在脑子里面运行了，没在机器上测试)。
Q2:一般实现不同用户订阅更好的办法是：Channel不是根据用户来分，而是根据处理的事务类型来分。即处理同类事情的所有用户订阅同一个频道（或者说订阅环节不考虑用户）。Publish端往频道塞消息的时候，在消息中携带用户标识/信息，Subscribe端应用拿到消息再根据用户分别处理。就好像你从数据库查到数据，里面有User_id字段来告诉你后续怎么区分用户处理逻辑，而不是每个用户一张表...