如何用 JavaScript 调用免费天气 API 并处理跨域问题？

Question

常见问题： 调用免费天气 API（如 OpenWeatherMap、WeatherAPI）时，前端 JavaScript 直接发起 `fetch()` 请求常报错 “CORS policy: No 'Access-Control-Allow-Origin' header”，即跨域被浏览器拦截。根本原因在于这些 API 默认不支持浏览器直连（服务端未配置 `Access-Control-Allow-Origin: *`），且多数免费 tier 明确禁止前端暴露 API Key。强行在客户端硬编码 key 不仅违反安全策略，还易被滥用导致配额耗尽或账号封禁。此外，部分 API（如 NOAA）甚至完全拒绝跨域请求。因此，“前端直连免费天气 API” 本身就是一个典型的设计误区——它混淆了客户端与服务端职责边界。正确解法不是绕过 CORS（如用代理插件或 JSONP，后者已基本淘汰），而是通过自建轻量后端代理（如 Express/Nginx）中转请求，由服务端统一鉴权、限流并注入 CORS 头，既合规又安全。

Answer 1

```html

一、现象层：前端直连天气 API 的典型报错与表象特征

开发者在 Vue/React 项目中直接使用 fetch('https://api.openweathermap.org/data/2.5/weather?q=Beijing&appid=xxx') 时，控制台高频出现：

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://api.openweathermap.org/... (Reason: CORS header ‘Access-Control-Allow-Origin’ missing).

该错误非网络不通，而是浏览器主动拦截——HTTP 状态码常为 200 OK（服务端已响应），但响应体被丢弃。此即“CORS 预检通过但响应头缺失”的典型症状。

二、协议层：CORS 机制的本质与浏览器强制约束

• CORS 是 W3C 标准，由浏览器强制执行，服务端无法绕过，客户端无法禁用；
• 关键响应头 Access-Control-Allow-Origin 必须由目标服务器（如 OpenWeatherMap）返回，前端无法伪造；
• 免费 tier API 明确在 Terms of Service 中禁止客户端暴露 key：“You must not expose your API key in client-side code”；
• NOAA API 更激进：对所有非白名单 Origin 返回 403 Forbidden 并拒绝预检请求（OPTIONS）。

三、架构层：职责错位——前端承担了本应由服务端履行的职责

职责维度	前端直连（错误模式）	后端代理（正确模式）
密钥管理	硬编码于 JS bundle，可被反编译提取	存于环境变量或密钥管理服务，运行时注入
请求限流	无法感知全局调用量，单页多次刷新即超限	按 IP/用户/Token 统一限流（如 Express-rate-limit）
错误归一化	OpenWeatherMap 404、WeatherAPI 429、NOAA 503 各自格式不兼容	统一转换为 {code: 200, data: {}, error: null} 标准结构

四、实践层：轻量代理方案对比与选型决策

以下为生产就绪的三种实现路径（按运维复杂度升序）：

1. Nginx 反向代理（零代码，适合静态站点）：
   location /api/weather { proxy_pass https://api.weatherapi.com/v1/; proxy_set_header X-Forwarded-For $remote_addr; }
2. Express 中间件代理（推荐，灵活可控）：
   

   app.get('/api/weather/current', async (req, res) => {
     const { q } = req.query;
     const url = `https://api.openweathermap.org/data/2.5/weather?q=${q}&appid=${process.env.OWM_KEY}`;
     const resp = await fetch(url);
     const data = await resp.json();
     res.header('Access-Control-Allow-Origin', '*').json(data);
   });

3. Serverless 函数（无服务器，自动扩缩容）：Vercel Edge Function 或 Cloudflare Workers。

五、安全层：超越 CORS 的纵深防御设计

graph LR
  A[前端 fetch /api/weather] --> B{Express Proxy}
  B --> C[API Key 检查]
  C --> D[IP 白名单校验]
  D --> E[速率限制中间件]
  E --> F[缓存策略：Redis TTL 300s]
  F --> G[转发至 WeatherAPI]
  G --> H[响应脱敏：移除 raw headers/raw body]
  H --> I[注入 CORS 头并返回]

六、演进层：从代理到领域服务的架构跃迁

当业务增长，单一代理将暴露瓶颈：

• 多源聚合：需同时调用 OpenWeatherMap（实时）、AccuWeather（预报）、国家气象局（中文行政区划）；
• 语义增强：将 “北京” 自动解析为经纬度，并缓存地理编码结果；
• SLA 保障：某 API 故障时自动降级至备用源，响应时间 >2s 则触发熔断；
• 可观测性：集成 Prometheus 指标（成功率、P95 延迟、key 调用量）与 Sentry 错误追踪。

此时，代理应升级为独立的 Weather Domain Service，遵循 Hexagonal Architecture，对外提供 gRPC/REST 接口，内部封装适配器与策略模式。

```