如何在Rails Turbo Stream局部视图获取current_user等上下文

无法直接在broadcast_append_to渲染的局部视图内部获取当前接收端的用户/账户上下文。

日志里显示的[User 8] [Account 3]标签，是ActionCable往客户端发消息的环节，给每个独立连接打日志时附加的连接标识，和Turbo Stream的渲染环节完全是两个独立的执行阶段：

• broadcast_append_to触发时，服务端会一次性渲染完整段HTML片段，之后这段完全相同的内容会被推送给所有订阅了对应流的客户端，根本不会针对每个接收用户单独跑一次渲染逻辑。
• 你写的locals: { user: user }里的user，永远是触发这次广播的评论发布者，不可能动态匹配每个接收端自己的登录账号，自然没法实现不同用户看到不同权限按钮的效果。

• 客户端做权限判断（性能最高）
  广播出去的评论局部视图只渲染所有用户都能看到的公共内容，在DOM节点上附带评论作者ID等必要标识；页面加载时提前把当前登录用户的ID、基础权限信息注入到全局，客户端收到Turbo Stream追加的评论节点后，用JS判断当前用户是否有编辑/删除权限，动态插入对应操作按钮就行。
• 给每个用户发私有流广播（不用写前端逻辑）
  不要直接往公共的[commentable, :comments]流推送带操作按钮的内容。新评论创建后，遍历所有当前在线、有权限访问该评论页的用户，给每个用户的专属流（比如流名拼接用户ID：[current_user, commentable, :comments]）单独渲染局部视图，渲染时传入对应用户对象走Pundit权限判断，保证每个用户收到的内容都是匹配自身权限的。
• 自定义Turbo Streams Channel发送逻辑（复杂度高，非必要不选）
  Rails 7.1以上版本可以重写Turbo::StreamsChannel的消息发送逻辑，给每个连接推送内容前，基于连接本身持有的current_user、current_account上下文重新渲染局部模板，实现渲染阶段读取接收端上下文的效果。但这个方案会侵入框架默认实现，后续升级维护成本很高，没有特殊需求不推荐用。

不要尝试通过修改Current这类线程全局变量的方式实现需求，ActionCable的连接和广播渲染不在同一个执行线程，这种写法会出现严重的线程安全问题，导致用户上下文错乱。

内容的提问来源于stack exchange，提问作者Dan Tappin