Rails 5+ActionCable+Sidekiq聊天消息样式区分异常问题

看起来你遇到的问题核心在于Sidekiq运行在独立的后台进程中，没有HTTP请求的上下文，所以current_user这个依赖请求的变量在Sidekiq任务里是无法直接访问的——这就是为什么页面刷新时（有请求上下文）样式正常，但Sidekiq渲染时判断失效的原因。下面给你两个可行的解决方案：

方案一：在Sidekiq任务中显式传递用户ID #

既然Sidekiq里没有current_user，那我们可以在触发任务时把当前用户的ID传进去，在任务内部查询出用户对象后，再传给局部视图。

步骤1：修改Sidekiq任务 #

假设你的任务是用来渲染消息并通过ActionCable推送，调整任务代码如下：

class MessageRenderJob
  include Sidekiq::Job

  def perform(message_id, current_user_id)
    # 找到对应的消息和用户
    message = Message.find(message_id)
    current_user = User.find(current_user_id)

    # 渲染局部视图时显式传入current_user
    rendered_html = ApplicationController.render(
      partial: 'messages/message',
      locals: { message: message, current_user: current_user }
    )

    # 这里把渲染后的HTML通过ActionCable发送到前端
    ActionCable.server.broadcast('chatroom_channel', html: rendered_html)
  end
end

步骤2：调用任务时传递用户ID #

在触发任务的地方（比如控制器或ActionCable频道里），把当前用户的ID一起传进去：

MessageRenderJob.perform_async(message.id, current_user.id)

这样局部视图里的message.user == current_user判断就能正常工作了，因为我们已经把用户对象显式传给了视图。

方案二：前端处理样式判断（更推荐） #

其实这类样式判断完全可以放在前端做，这样后端不需要处理用户上下文，也能避免Sidekiq里的上下文问题。

步骤1：后端传递必要数据 #

在ActionCable广播时，只传递消息的body和user_id，而不是渲染好的HTML：

# 比如在消息创建后直接广播（或者在Sidekiq任务里做）
ActionCable.server.broadcast('chatroom_channel', {
  body: message.body,
  user_id: message.user.id
})

步骤2：前端判断并添加样式 #

在你的ActionCable前端订阅代码里，对比当前登录用户的ID和消息的user_id，动态添加对应的class：

App.chatroom = App.cable.subscriptions.create("ChatroomChannel", {
  received: function(data) {
    // 页面加载时注入当前用户ID（ERB里直接输出）
    const currentUserId = <%= current_user.id %>;
    const messageClass = data.user_id === currentUserId ? 'bubble' : 'bubble bubble-alt';
    
    // 创建消息元素并添加到页面
    const messageElement = document.createElement('div');
    messageElement.className = messageClass;
    messageElement.textContent = data.body;
    document.getElementById('messages').appendChild(messageElement);
  }
});

这种方式的优势在于：减少后端渲染的压力，把样式逻辑放在更适合的前端层，同时彻底避免了后台任务的上下文问题。

为什么页面刷新时正常？ #

页面刷新是一个标准的HTTP请求，此时控制器会处理请求并设置current_user，渲染局部视图时处于请求上下文里，所以current_user是可用的，判断自然生效。而Sidekiq是脱离请求的后台进程，没有session、cookie这些请求相关的数据，所以无法获取current_user。

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