要回答这个问题便绕不开 OAuth2.0 和 OIDC （上述两者是较为庞大的话题就不过多引入了）。这里先阐明一个前提：OAuth2.0 （ RFC 6749 ）中规范的双 token 是用在授权场景的并没有提到过任何相关认证的话题。而我们通常意义上见到的双 token 认证个人认为是从 OAuth2.0 协议中演化出来的一个变种（实际上 Cookie+Session 能很好的完成安全认证的相关流程，RFC 6896 提供了一系列的措施来补充整个流程的安全漏洞，为啥不用呢），网上很多文章充斥的都是方便跨域，更安全，扩展性强等话题来吹捧 JWT Token 认证方式，但我们试想下整个使用 JWT 认证(或其他什么 token)流程，就会发现，为了达到 Cookie+Session 的效果不得不去做些违背 JWT Token 设计之初的原意（把 Token 缓存起来）（扯远了）。单 JWT Token 配合缓存确实能达到认证的效果，但存在泄露的可能，我们不能签发一个很长时间的 JWT token 这会增加泄露时的风险，引入 Refresh Token 后那么每次刷新的时候可以同时换取新的 Access Token + Refresh Token 产生新的后旧的便会失效，而且刷新的时候可以做一些审计（判断上次的访问地址，频次等推断是否是合法访问）从而拒绝并提示用户登录或者换出新的 JWT token ，双 token 即使泄露顶多换取用户一次重新登录，而单 token 的话由于 JWT 的自包含性在签发时间内都是有效的无法快速的撤销其授权，会让其在泄露之后长时间有效。事实上 OAuth 2.0 协议中对于 Public Client （浏览器端的单页应用等）并没有强制签发双 Token ，基于 Cookie+Session 配合 OIDC 协议中的 prompt=none 策略，也可以无感的换取新的 token 。并且 OAuth2.0 中提供了 Token Introspection 端点和 Token Revocation 端点用来主动撤销 Token 防止泄露或用户主动中断授权后避免三方系统继续持有有效的访问凭据。回答有些简要，希望不会因为引入的一些拗口话题造成困惑~

支持一下

为什么不行呢？ https://dev.mysql.com/blog-archive/mysql-with-docker-performance-characteristics/