Cookie确实是浏览器会自动带上的，不用前端写代码去塞，看起来省事又自动化。但现在的绝大多数前后端分离项目，非要费劲巴力地把 Token 放在 Authorization 里传过去，主要还是 Cookie 自身局限性太多了

1.CSRF 攻击这是不用 Cookie 最直接的安全理由。

Cookie 是只要你向域名发请求，浏览器就会无脑、自动地带上 Cookie，根本不管这个请求是谁发起的。假如你登录了银行网站 http://bank.com，token 存在 Cookie 里，你手滑点开了一个钓鱼网站http://bad.com，钓鱼网站里有一个隐藏的 img 标签或者是自动提交的 form 表单，地址指向http://bank.com/transferto=hacker&money=1000000。浏览器看是发给 http://bank.com 的请求自动带上你的 Cookie，完犊子了，你100万零花钱被划走了。 因为后端也分不清这是你点的转账还是钓鱼网站帮你点的转账。这就是 CSRF 跨站请求伪造。前端显示的在请求 Header 加上 Authorization ，钓鱼网站在厉害，也没办法指挥你的浏览器去读 LocalStorage 里的 token 并在发请求时塞进 Header，因为有同源策略限制着呢。

2. 跨域Cookie 在跨域场景下也不太友好。

现在很多浏览器比如 Chrome 为了安全，对跨域 Cookie 的SameSite 策略限制越来越严。你想跨域传 Cookie，要么配置 HTTPS 和 SameSite=None，要么被浏览器拦截。后端也得跟着配置这玩意，必须配置 Access-Control-Allow-Credentials: true，而且 Access-Control-Allow-Origin 还不能是 *，必须是具体域名。一旦配置错一点，token 就传不过去。

3. 多端兼容性

如果你的后端 API 只需要服务 Web 浏览器，那用 Cookie 勉强还行。但现在的业务，往往是 Web + App + 小程序开发 + IoT 设备 + 第三方调用。iOS 和 Android 的网络库默认还没有 Cookie ，如果用它客户端开发还得专门写代码去模拟浏览器的 Cookie 行为，他们会骂娘的。好像微信小程序的 wx.request 也不支持Cookie。服务端对服务端调用，A 服务调 B 服务，上哪整 Cookie？Authorization Header 应该算是 HTTP 协议的标准语义。不管你是浏览器、手机、还是一个 Python 脚本，大家都能轻松构造一个 Header。通用性非常好。

4. 灵活度高

Cookie可是跟域名绑定的，发请求时全量携带。某些复杂场景下，我们需要更精细的控制，比如用户同时登录了个人版和企业版两个账号，想在同一个浏览器里切换。用 Cookie 就很难搞，因为 Cookie Key 可能会冲突，或者需要复杂的 Path 设置。Header 传前端代码里存两个 Token，想用哪个账号发请求，就在 Header 里塞哪个 Token。控制权在开发手里，不在浏览器手里。

所以，对于绝大多数常规业务来说，把 Token 放 Header 里，是目前性价比最高、坑最少的业界标准。