用途：对 Web 项目各层进行系统性 CORS 配置审计，在问题进入生产前发现错误配置、重复响应头与安全问题。适用于部署或改配置后浏览器控制台出现 CORS 错误、新项目跨域 API 调用、审查现有 CORS 设置、迁移到网关代理架构，以及嵌入微应用（Qiankun、single-spa、Module Federation）等场景。
主要能力：按六阶段推进——架构发现、配置收集与静态校验、单层规则验证、最佳实践校验、环境特定校验、生成报告。核心原则是 CORS 响应头只能由一层设置，重复头是最常见缺陷；需选定权威层（有网关则网关，无网关则后端，CDN/边缘则边缘），并让非权威层保持静默，必要时剥离上游头（Caddy 用 header_down -Access-Control-Allow-Origin，Nginx 用 proxy_hide_header）。检查项涵盖 Origin 策略（带凭证时禁用 *）、预检 OPTIONS 返回 204 并含 Max-Age、Allow-Headers/Methods 覆盖前端用法等。问题按 Critical、Warning、Info 分级，可输出 JSON 报告。
使用方式：先运行预检 python scripts/validate_cors.py preflight，再对配置文件执行 python scripts/validate_cors.py validate --config path/to/Caddyfile，对在线端点执行 python scripts/validate_cors.py validate --url https://your-api.com/health --origin https://your-frontend.com。脚本仅依赖 Python 标准库，需 Python 3.7+。
限制：端点不可达时跳过在线校验，仅做静态分析，并需告知用户跳过原因；脚本退出码反映执行状态而非审计严重性，严重性见 JSON summary 字段。CORS 仅作用于浏览器，服务端调用不受影响。具体报告格式选项与批量、微应用测试示例见随附参考文档。