如何分离同一资源的公开与授权路由？以用户信息接口为例

你的三个方案逐一拆解 #

方案1：独立路由+独立处理器 #

• 优点：路由语义一目了然，/user/{id}专门给认证用户拿带私有信息的数据，/public/user/{id}拿公开资料，前后端对接时不用额外沟通，一看就懂；两个处理器各干各的事，逻辑清晰，出问题好排查。
• 缺点：如果两个路由都要查用户的基础信息（比如昵称、头像），容易写重复代码，后期改基础逻辑得改两个地方，有点麻烦。

方案2：单路由+双处理器（按认证状态分支） #

• 优点：只用一个路由，前端调用简单，不用记两个地址。
• 缺点：处理器里会混着「判断用户有没有认证」和「返回对应数据」的逻辑，代码揉在一起，以后加权限规则（比如管理员能看更多字段）的话，代码会越来越乱，维护起来头大。

方案3：拆分用户表+双路由 #

• 优点：从数据库层面就把公开和私有信息分开了，根本不会出现误把邮箱返回给陌生人的情况；公开表字段少，查起来更快，传输的数据也更少。
• 缺点：数据库多了一张表，创建、更新用户时得同时操作两张表，关联查询还要JOIN；要是分布式系统，还要操心两张表的数据一致性，运维成本上去了。

最推荐的方案：方案1 + 核心逻辑复用 #

保留两个独立路由的设计，但把查询用户基础数据的代码抽成公共函数，两个处理器都调用这个函数，再各自过滤返回的字段：

• 比如写个getUserFullInfo(id)函数，负责从数据库把用户的所有信息查出来；
• /public/user/{id}的处理器调用这个函数后，只返回昵称、头像、简介这些公开字段；
• /user/{id}的处理器调用后，返回包括邮箱在内的全部字段，同时还要额外判断：当前登录的用户是不是目标用户本人，或者有没有权限看别人的私有信息，防止越权。

这种方式既保留了路由清晰、职责分开的好处，又避免了代码重复，是可读性、可维护性和安全性都兼顾的最优解。

其他可选方案 #

单路由+字段过滤 #

用同一个路由/user/{id}，在处理器里根据用户的认证状态和身份过滤字段：

• 没登录的用户：只返回公开字段；
• 登录了且是自己：返回全部字段；
• 登录了但看别人的资料：还是返回公开字段。
  这个方案路由统一，但一定要把权限校验写死，别让坏人伪造身份拿到敏感数据；后期如果权限规则变复杂，得注意别让处理器代码太臃肿。

用参数/请求头区分范围 #

同一个路由/user/{id}，通过查询参数（比如/user/{id}?scope=public）或者自定义请求头（比如X-Scope: public）来指定要返回的是公开还是私有数据。但这种方式不如独立路由直观，前端容易传错参数，而且得在处理器里严格校验参数的合法性，防止有人瞎改参数拿私有信息。

内容的提问来源于stack exchange，提问作者Ahmet Yazıcı