我注意到我们的代码以cookie的形式将访问令牌/授权令牌添加到响应中，使用((HttpServletResponse) response).addCookie(accessTokenCookie);
我做了一些研究，发现了这个信息:
请求cookie是从浏览器发送到服务器的cookie
响应cookie是发送出去的cookie(从服务器到浏览器)。
如果是这种情况，难道我的请求拦截器/doFilterInternal不需要在请求通过之前将访问令牌cookie应用于请求，而不是响应吗?
更令人困惑的是访问令牌cookie是通过使用request.getAttribute获取访问令牌值来创建的。如果请求已经将访问令牌作为属性，为什么还需要将cookie添加到响应中?
你误解了cookie的工作原理。
浏览器向某个服务器上的某个资源发送请求。
服务器返回组成资源的字节。
这是基本流程。现在，我们来谈谈cookie:
当服务器返回这些字节时，它可以发送报头。事实上，这是必须的;例如，讨论数据表示什么。例如，如果您请求/img/background.png，服务器返回图像数据并发送Content-Type: image/png。因为浏览器实际上不会做整个'扩展指示数据是什么'的事情，这就是Content-Type头的作用。
其中一个头是Set-Cookie头。
Set-Cookie报头告诉浏览器:获取此数据并将其保存在某处。下次加载此资源时，请再次发送它。有一些关于何时发送它的控制(你可以在服务器响应request/foo/bar时发送Set-Cookie头，使浏览器即使在请求/foo/baz时也发送该cookie)，或者当foo.myserver.com发送cookie时，它可以告诉浏览器:当从bar.myserver.com请求资源时也发送该cookie。不过也有限制;当在myserver.com上响应请求时设置cookie时，您不能告诉浏览器在发送到google.com时将其发送回去。浏览器是复杂的野兽;他们提供了一个巨大的顶级域名列表，不让你这样做。
你不'添加' cookie到'请求' -请求的东西(你可以从HttpServletRequest对象获得的数据)只是代表什么浏览器发送给服务器。HttpServletRequest/Response的模型严格分为两个阶段:浏览器发送请求，服务器响应。就是这样。这不是一个很长的谈话。每条信息只有一条，这就是你所得到的。
所以，你在'response'中添加了一个cookie，这意味着将来由同一浏览器发出的请求将在'request'中发送它。