Rails自定义视图@user无法访问问题：与current_user对比及原因排查

嘿，我来帮你拆解这几个Rails新手常踩的典型问题，一个个说清楚～

核心问题出在你的路由定义上：
你写的get 'mygroups' => 'users#mygroups'这个路由，URL里没有:id这个动态占位符。当你访问/mygroups时，params[:id]是空值，User.find(params[:id])自然会抛出「Couldn't find User with 'id'=」的错误——因为根本没传id给它啊！

对比下标准动作（比如show/edit）：它们的路由是resources :users自动生成的，比如GET /users/:id，这里的:id是动态片段，当你访问/users/123时，Rails会把123塞进params[:id]里，所以User.find(params[:id])能精准找到对应用户。

如果你的mygroups是让用户看自己的分组，那其实不用从params拿id，直接在控制器写@user = current_user就行；如果以后要支持查看其他用户的分组，就得把路由改成get 'users/:id/mygroups' => 'users#mygroups'，这样URL里的id就能传到params里，控制器的代码就正常了。

这得看你的业务场景，但普遍有几个需要注意的点：

• 灵活性受限：如果以后需求变了（比如要让管理员查看其他用户的分组），直接依赖current_user的代码就没法用了，得大面积重构。而用@user的话，只要路由带id，就能轻松切换到任意用户的分组页面。
• 测试成本更高：写控制器测试时，用@user可以直接传不同的id来测试各种场景；但依赖current_user的话，每次测试都得先模拟用户登录，步骤变多，复杂度上升。
• 职责不够清晰：控制器的核心职责是「获取并传递资源给视图」，直接用current_user相当于把「获取当前登录用户」的逻辑和「处理分组页面」的逻辑混在了一起，代码的可读性和可维护性会打折扣。

当然，如果你的mygroups页面永远只允许用户查看自己的分组，那用current_user完全没问题，只是要提前考虑未来的扩展性。

因为Rails的resources :users会自动生成带:id动态占位符的路由，比如：

• GET /users/:id → 对应show动作
• GET /users/:id/edit → 对应edit动作
• PATCH /users/:id → 对应update动作
• DELETE /users/:id → 对应destroy动作

这些路由里的:id会把URL中的数值（比如/users/456里的456）赋值给params[:id]，所以控制器里的User.find(params[:id])能精准定位到对应用户。而你自定义的mygroups路由没有这个动态片段，params里自然找不到id，也就查不到用户了。

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