一个困扰Rails开发者多年的问题，直到最近才被完整解开。当你刷信息流时，系统怎么知道哪条帖子你已经点过赞？传统做法要查两次数据库，用户一多直接卡死。
这个问题叫「用户关联预加载」——既要查出所有帖子，又要标记出当前用户点赞过的那些。表面看简单，实际藏着Ruby on Rails框架里最隐蔽的性能陷阱之一。
一位开发者在技术社区写下这句话：「我找遍全网，没找到真正直接的答案。」
他的方案最终只用了几行代码，却让查询效率提升数十倍。更关键的是，这招能复用到几乎所有「判断用户是否已操作」的场景——好友关系、收藏状态、阅读记录，全部通用。
CurrentAttributes：被低估的全局通行证
Rails 5.2引入了一个鲜为人知的模块：ActiveSupport::CurrentAttributes。它像一张临时通行证，能在单次请求周期内，把数据贴到任何需要的地方。
开发者创建了一个Current类，只存一个user_id。为什么不存整个用户对象？他的解释很克制：「Current Attributes不应该被滥用。」
设置方式取决于你的认证系统。用Devise的话，在ApplicationController里加一行before_action，每次请求前把当前用户ID塞进去。代码不到10行，却打通了后续所有操作的关键链路。
这里有个细节容易踩坑。CurrentAttributes的生命周期严格绑定单次请求，线程安全由框架保证，但跨请求绝对隔离。这意味着你不用担心用户A的数据漏给用户B——除非你自己在代码里开了后门。
「我们只需要ID，所以保持简单。」这位开发者在注释里写道。
关联定义的精妙陷阱
真正的魔法发生在Post模型里。开发者定义了一个叫liked的关联，写法让新手困惑：
has_many :liked, -> { where(id: Current.user_id) }, through: :likes, source: :user
拆解一下。through: :likes表示借道likes表，source: :user说明最终要拿的是用户数据。但中间那个lambda才是核心——它动态注入当前用户ID作为过滤条件。
结果很反直觉：liked关联永远不会返回nil，要么空数组，要么含一个元素。这正好配合Rails的any?方法，在视图里写判断时干净利落。
对比传统方案。以前的做法是先查所有帖子，再循环查每条帖子的点赞状态——经典的N+1查询，100条帖子就是101次数据库往返。现在eager_load(:liked)一次性搞定，SQL层面做了优化连接。
一位评论者算过账：「从101次查询降到2次，响应时间从800毫秒压到40毫秒。」
为什么这招藏了这么久
CurrentAttributes的官方文档 buried 在Rails指南的角落，例子全是关于时区和多租户。把它和关联预加载结合起来用，属于典型的「框架能力组合创新」——单个功能都文档齐全，拼在一起却没人写过。
更深层的原因是思维定式。大多数开发者遇到「判断是否点赞」的需求，第一反应是写实例方法或装饰器模式。他们没意识到，这个问题本质是数据关联问题，该用关联层解决。
开发者在文章里埋了个彩蛋：这个技巧不止用于点赞。判断好友关系？把Current.user_id扔进User模型的关联条件。检查收藏状态？同样的模式套到Bookmark模型。甚至阅读进度、投票记录、关注状态，全部可以复用。
唯一的前提是：你的认证系统能在请求开始时把用户ID塞进Current。
「它可以用在其他方式，不只是这一种。」作者特意强调。
社区反馈验证了这个判断。文章发布两周内，被引用到Stack Overflow的7个相关问答里，有人用它解决了GraphQL的N+1问题，有人套用到StimulusReflex的实时更新场景。
一位团队技术负责人在评论区写道：「我们把这个模式抽成concern，现在全平台的「用户是否已X」判断都统一了。」
当然也有争议。部分开发者担心CurrentAttributes的「全局变量」属性会隐藏依赖关系，让测试变复杂。作者回应得很直接：「只在请求周期内有效，测试时重置就行。」
Rails核心团队成员在GitHub issue里提过，CurrentAttributes的设计初衷就是解决这种「请求上下文传递」场景，而非替代参数显式传递。用对地方，它是利器；滥用，才是问题。
回到最初的那个场景。当你下次刷信息流，看到心形图标自动点亮时，背后可能正跑着这段代码。它不发通知、不弹窗，只是安静地省下了几百毫秒——以及服务器上本该疯狂转动的风扇。
那位开发者最后更新了一次文章，加了行备注：「如果Current.user_id为nil，关联会返回空数组，不会报错。但建议控制器里做好认证检查。」
你的项目里，有多少处「判断用户是否已操作」还在用循环查询？
热门跟贴