关键不是“加头”，而是“不走后端”：用RewriteRule在rewrite阶段拦截OPTIONS请求，返回204空响应，并通过Header always set精准注入CORS头，避开后端处理，将延迟压至1毫秒内。
Apache核心层优化OPTIONS预检响应速度，关键不是“加头”，而是“不走后端”。把预检拦截在rewrite阶段，用204空响应直接返回，并精准注入CORS头——这样能避开PHP/Python等应用层，将延迟从百毫秒压到1毫秒内。
用RewriteRule在最前端截断OPTIONS请求
让Apache在重写阶段就终止处理，不进入路由、不加载模块、不调用后端：
- 确保mod_rewrite已启用（运行
a2enmod rewrite并重启） - 在虚拟主机配置或
.htaccess中添加以下三行（顺序不能错）：RewriteEngine On<br>RewriteCond %{REQUEST_METHOD} OPTIONS<br>RewriteRule ^(.*)$ - [R=204,L] -
-表示不改路径，R=204强制返回无响应体的204状态，L确保后续规则全部跳过 - 切勿用
Redirect 204——它不支持204，会退化成302重定向
用Header always set注入CORS头，绕过响应阶段限制
普通Header set对204响应无效，因为Apache在内容生成阶段才执行它；而always强制在所有响应阶段注入：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 必须搭配
<IfModule mod_headers.c>使用，且开启mod_headers - 推荐写法（放在
<VirtualHost>内或.htaccess中）：<IfModule mod_headers.c><br> <Limit OPTIONS><br> Header always set Access-Control-Allow-Origin "*"<br> Header always set Access-Control-Allow-Methods "GET,POST,PUT,DELETE,OPTIONS"<br> Header always set Access-Control-Allow-Headers "Content-Type,Authorization,X-Requested-With"<br> Header always set Access-Control-Max-Age "86400"<br> </Limit><br></IfModule>
- 若需动态Origin（如白名单校验），可用
%{HTTP:Origin}e变量配合SetEnvIf，但要避免反射漏洞
关掉后端CORS中间件，防止逻辑冲突
Apache已响应OPTIONS，后端再处理同一请求，容易导致头重复、状态码错乱或鉴权误判：
- Express用户：设置
cors({ preflightContinue: false })，或完全移除app.use(cors()) - Django REST Framework：禁用
CorsMiddleware，或在中间件中跳过OPTIONS方法 - 验证方式：用
curl -I -X OPTIONS http://yoursite/api/test，确认只返回204和你Apache显式设置的头，无多余X-Powered-By或Server干扰
检查缓存生效条件，避免Access-Control-Max-Age失效
即使设置了Access-Control-Max-Age，浏览器仍频繁发OPTIONS，往往是因为缓存前提被破坏：
- 浏览器只在
Origin完全一致（协议+域名+端口）时复用预检结果，localhost:3000和127.0.0.1:3000视为不同源 - 若启用了
Access-Control-Allow-Credentials: true，则Access-Control-Allow-Origin不能为*，必须精确匹配，否则缓存被忽略 - 检查CDN或反向代理是否清洗了
Access-Control-Max-Age头——有些CDN默认不透传自定义头 - 可通过Chrome开发者工具的Network面板，查看OPTIONS响应头中是否有
access-control-max-age，且后续同源请求未再触发OPTIONS
