登录态失效那一刻，通过用户骂娘，获户信你查日志，取用发现token过期时间设成了30秒。通过这种事故我见过不下十次。获户信

token是取用啥？说白了就是服务器发你的一张临时门票。你输入账号密码，通过服务器验明正身，获户信甩给你一串加密字符串——这就是取用token。之后你每次请求接口，通过把这串字符串往请求头里一塞，获户信服务器一看token有效，取用就知道“哦，通过是获户信那个注册过的家伙”，不用再重复输密码了。取用

那“通过token获取用户信息”这个操作，本质上就是拿着门票去窗口换你的个人档案。流程不复杂，但坑不少。

最典型的做法是，前端把token放在Authorization请求头里，格式一般是`Bearer xxxxxx`。后端拿到token，先验签名，再查过期时间，最后从token里解析出用户ID，拿着这个ID去数据库捞用户记录。捞出来的是啥？用户名、头像、邮箱、手机号，看你的业务需求。

但这里有个分岔路。有些团队图省事，把用户昵称、头像直接塞进token里。我见过一个项目，token里放了用户手机号、家庭住址、甚至会员等级。这他妈就是给自己埋雷。token是会泄露的，前端日志、第三方统计脚本、浏览器插件，哪个都可能截获它。你把敏感信息放token里，等于把家门钥匙挂在门外。

正确做法是token里只放一个用户ID，其他信息都靠这个ID现查。多一次数据库查询？对，但安全系数高一个量级。别嫌慢，那点延迟用户感知不到，但数据泄露事故能让公司上头条。

还有个细节容易被忽略——token失效后的处理策略。比如用户修改密码，你之前的token还管用吗？有些系统不管，照样放行。这就有问题了。别人捡到你旧token，即使你改了密码，他还能继续操作你的账号。正确做法是在用户表里存一个token版本号，改密码时版本号+1，校验token时对比版本号，不一致就拒绝。

再聊聊缓存。高频接口每次都查数据库，压力大。你可以把用户信息缓存到Redis，key用用户ID，value放用户信息的JSON序列化。过期时间设个15分钟。这样token校验通过后，先查缓存，命中就直接返回，没命中再查库，然后回填缓存。我见过一个日活百万的应用，就靠这招把用户信息接口的响应时间从80毫秒压到了5毫秒。

但缓存有坑。用户更新头像后，缓存里还是旧图。你得在更新操作时主动删缓存，或者让缓存短一点。取舍看业务——头像这种低频修改的，15分钟缓存没问题；但用户改了密码，你最好立刻把相关缓存全清了。

最后说个真实案例。之前帮一个电商平台排查问题，用户反馈下单后看不到收货地址。查了半天，发现前端调用户信息接口时，token是拿对了，但后端代码里把用户ID写死了——从配置中心读的，根本没解析token里的ID。那段时间所有用户看到的都是同一个测试账号的地址。这种低级错误，代码review的时候就该拦住。

token获取用户信息，听着简单，但每一步都有讲究。别嫌啰嗦，该验签验签，该查库查库，该设过期设过期。真出事了，你返工的成本比写代码时多花的那点时间高得多。