同事说：正常情况下登录接口不返回用户信息，是这样吗

他是不是 get 获取资源,delete 删除资源

看场景吧，大多数情况都是值返回 token 。如果你这个场景需要用户信息，直接返回能省很多事那也不是不可以

碰到这样同事，难搞哦，顺手的事情都不愿意支持

这都是看业务了，不过如果非要说的话我支持分离获取

登录警察虽迟但到
登录警察统计：
使用登录：7 人
使用登陆：4 人

一般不返回，要获取用户信息单独请求；
token 里面最多带上用户静态信息比如 id ，其它动态信息随时会改

可以返回用户脱敏信息,主要不能有密码,或者采取 token 存用户 id 然后二次查询用户脱敏信息,看业务需求

auth 服务通常只会返回基本信息，够客户端做一般初始化操作，小应用同表一起返回也可以，大应用一般是区分接口返回的，

一般是不返回的

不返回啊

一般是不返回的，没有 getUserInfo 的接口都是魔鬼。每次刷新都不知道当前用户是谁

是的，正常来说 app 端只会返回 token ，在 heade 里面，然后去获取 userInfo 信息。从后段微服务架构来说就是这样的设计的。 但是其实也可以聚合的。也不是绝对的，他那边可以多写一个接口聚合，如果有现成的接口 你直接几下写了就完事。也不复杂。些许小事罢了。我现在就是 你咋个设计我就咋个写 不愿意争论这些了。客户端就一个人 很难犟得过后端几个人。

反正都能做 ，无所谓了。懒得麻烦。

这个其实都行，看后端心情，前端有什么用什么就行了。
因为用户信息这个接口，复用率非常高，有些后端会觉得提供了专门接口了，就不会在附加返回这个信息给前端了，这种流派的后端一般比较坚持模块化、接口单一性。
但是往往很多前端比较喜欢的是面向页面提供接口，希望后端一个接口就把当前页面需要的数据全部返回来。

我们是这样的：登录只返回成功，不返回 token 这个字符串，token 由后端在账号密码校验之后写到当前域的 cookie 里（开发、测试、线上的域名和 cookie 键是不同的，后端配置后端写）

前端拿到登录接口的 ok 返回，就直接跳转首页开始调接口，同时也不用前端手动把 token 携带到 header 里之类的，http 请求会自动携带当前域的 cookie ，后端根据配置的 cookie 键取，然后校验

最终流程是这样：用户访问首页，前端不判断是否有 cookie （前端不关心任何登录状态，由后端判断），直接调 UserInfo 接口，后端发现没有 cookie 返回特定 code ，前端跳转登录页

用 cookie 的好处是：最简单最原生的方案实现多个二级域名站点的单点登录

不给用户信息也是有充分理由，单一原则。登录就是登录

选择困难症初期患者

一般这种时候就是前端去搞 BFF 的契机了

不一定.
图方便的话登录之后给返回用户信息没毛病.

但是如果按照接口职责单一原则, 用户信息接口单独获取也无可厚非.

登录实体未必是用户，未必关联了用户，未必有权限获取用户信息
登录服务器未必有用户的信息