如何配置Swagger UI使其带认证正常使用Try It Out功能？

首先得澄清一个关键误区：你没办法强制浏览器在CORS预飞的OPTIONS请求里携带Authorization头——这是浏览器同源策略的安全限制，预飞OPTIONS请求是浏览器自动发起的，按照W3C规范，它不会携带自定义的Authorization这类头部。所以你的问题核心不是让OPTIONS带Auth头，而是让后续的POST请求能正常带上Auth头，同时处理好预飞OPTIONS的问题。

下面给你两个最可行的解决方案：

1. 后端配置允许无认证的OPTIONS请求 #

因为预飞OPTIONS是浏览器的默认行为，后端必须兼容这个逻辑：对OPTIONS请求跳过Basic Auth校验，直接返回成功响应（比如200状态码）。不同后端框架的实现方式举例：

• Spring Boot：可以自定义一个过滤器，判断请求方法是OPTIONS时，直接返回200，不进入认证拦截链；
• Node.js/Express：使用cors中间件时，确保认证中间件（比如basic-auth）不拦截OPTIONS请求，或者在cors配置里显式允许预飞；
• 其他框架：找到请求拦截/认证的入口，给OPTIONS请求单独开绿灯。

当后端正确处理OPTIONS请求后，浏览器收到成功响应，就会自动发送带Authorization头的POST请求了。

2. 确保Swagger UI正确配置Basic Auth支持 #

要让Swagger UI在Try It Out时自动给POST请求带上Auth头，你需要在OpenAPI规范里定义Basic Auth的安全方案：

openapi: 3.0.3
info:
  title: 你的业务API
  version: 1.0.0
components:
  securitySchemes:
    basicAuth:
      type: http
      scheme: basic
# 全局启用Basic Auth，也可以给单个接口单独配置
security:
  - basicAuth: []

添加这段配置后，Swagger UI顶部会出现「Authorize」按钮，点击后输入你的用户名和密码，之后所有的Try It Out请求（包括POST）都会自动带上Authorization: Basic <base64编码的凭证>头部。

特殊场景的替代方案 #

如果你的后端业务逻辑硬要求OPTIONS请求也带Auth头（这其实不符合CORS规范），那只能绕过浏览器的跨域限制：

• 把Swagger UI部署在和API相同的域名/端口下，这样不会触发CORS预飞；
• 使用代理服务器，让Swagger UI通过代理访问API，避免跨域问题。

总结下来，最标准且易维护的方案就是：后端兼容OPTIONS无认证请求 + 配置OpenAPI的Basic Auth安全方案，这样就能完美实现带认证的Try It Out功能了。

内容的提问来源于stack exchange，提问作者Reddy SK