ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

首页/资讯中心/资讯详情

深入解析跨域问题：从同源策略到CORS、Nginx代理与WebSocket实战

发布时间：2026/8/11 7:09:29 拓冰企业网站定制
深入解析跨域问题：从同源策略到CORS、Nginx代理与WebSocket实战

1. 从一次线上故障说起：为什么“跨域”让前端开发者头疼？

那天下午，我正在工位上喝着咖啡，突然钉钉群里炸开了锅。前端同事小张发来一串截图，浏览器控制台里赫然躺着几个刺眼的红色错误：“Access to fetch at ‘https://api.other-domain.com/user’ from origin ‘https://www.my-app.com’ has been blocked by CORS policy”。紧接着，运营反馈用户无法加载第三方地图服务，产品经理也跑来问为什么新上的H5活动页在微信里打不开。整个团队的目光瞬间聚焦到我这个后端身上——又是“跨域”问题。

这场景对Web开发者来说太熟悉了。无论你是刚入门的新手，还是摸爬滚打多年的老鸟，“跨域”这个词就像幽灵一样，时不时跳出来给你制造点麻烦。它不是什么高深的算法，也不是复杂的架构设计，但就是这种看似简单的“安全策略”，在实际开发中却能卡住整个项目的进度。很多人背过“JSONP”、“CORS”、“Nginx代理”这几个名词，也照着网上的教程配过，但一旦遇到稍微复杂点的场景，比如预检请求失败、携带Cookie失效、WebSocket连接被拒，就又一头雾水。

所以，今天我们不聊那些干巴巴的概念，就从实际开发中的一个个“坑”出发，彻底搞明白：浏览器到底为什么要多此一举地限制跨域？以及，面对这个限制，我们手头到底有哪些“武器”可以选用，每种方案的原理是什么，最适合用在什么场景，又有哪些需要特别注意的“坑”？我会结合我这些年踩过的雷、填过的坑，把JSONP、CORS、Nginx反向代理、WebSocket、PostMessage这些常见的解决方案，掰开了揉碎了讲清楚。无论你是前端、后端还是运维，看完这篇，下次再遇到跨域问题，你就能像老中医一样，快速诊断，对症下药。

2. 追根溯源：浏览器同源策略的“良苦用心”

要解决跨域，首先得理解为什么会有跨域问题。这得从浏览器的“同源策略”说起。你可以把它想象成小区严格的门禁系统。

2.1 同源策略：Web安全的基石

同源策略是浏览器最核心、最基本的安全功能之一。它的规则很简单：如果两个URL的协议、域名、端口三者完全相同，则认为是同源，否则就是跨源（跨域）。

举个例子：

  • https://www.example.com/index.html请求https://www.example.com/api/data->同源（协议https，域名www.example.com，端口443默认，都相同）。
  • https://www.example.com请求http://www.example.com->跨域（协议不同，https vs http）。
  • https://www.example.com请求https://api.example.com->跨域（域名不同，二级域名不同）。
  • https://www.example.com:8080请求https://www.example.com:3000->跨域（端口不同）。

这个策略限制了什么？主要是三方面：

  1. DOM访问限制：来自不同源的脚本无法读取或修改另一个源的页面DOM。这防止了恶意网站通过iframe嵌入你的银行页面并窃取输入信息。
  2. 网络请求限制：通常，通过XMLHttpRequest或Fetch API发起的跨域HTTP请求会被浏览器拦截。这是我们今天讨论的重点。
  3. 数据存储访问限制：如localStorage、IndexedDB等，每个源都有自己独立的空间。

注意：有些标签天生具有跨域能力，如<img>、<link>、<script>。这是历史遗留特性，也是JSONP等方案的基础，但也带来了安全风险（如CSRF攻击）。

2.2 为什么需要这个限制？一个生动的比喻

假设没有同源策略会怎样？想象一下： 你登录了https://your-bank.com，浏览器里保存了登录凭证（Cookie）。此时，你不小心访问了一个恶意网站https://evil-site.com。这个恶意网站里的脚本，可以悄无声息地向https://your-bank.com/transfer发起一个POST请求，请求头里会自动带上你在银行的Cookie。银行服务器看到合法的Cookie，以为是你本人在操作，于是执行了转账。这就是恐怖的“跨站请求伪造”攻击。

同源策略就像给你的每个“源”（网站）划定了一个独立的沙箱。沙箱内的资源可以自由交互，但想和沙箱外的世界通信，必须经过一套明确的、受控的规则允许。这从根本上杜绝了上述场景的发生。

所以，跨域问题不是Bug，而是Feature，是浏览器为了保护用户安全和隐私主动设置的一道安全屏障。我们开发者要做的，不是“干掉”它，而是在理解其安全意图的前提下，为那些合法的、必要的跨域通信需求，找到合规的“通行证”。

3. 解决方案一：JSONP —— 古典时代的“奇技淫巧”

当Ajax技术刚兴起，CORS标准还未诞生时，前端开发者们为了跨域获取数据，发明了一种非常巧妙的“漏洞利用”方案——JSONP。

3.1 JSONP的工作原理：借道<script>标签

前面提到，<script>标签的src属性不受同源策略限制。JSONP正是利用了这一点。

核心思想：客户端不是直接发起XHR请求，而是动态创建一个<script>标签，其src指向目标服务器的API地址，并在URL中携带一个回调函数名（如callback=handleResponse）。服务器收到请求后，不返回标准的JSON，而是返回一段JavaScript代码，这段代码的内容是调用那个客户端指定的回调函数，并把真正的数据作为参数传入。浏览器加载并执行这个<script>，就相当于调用了本地的回调函数，从而拿到了数据。

客户端代码示例：

function handleResponse(data) { console.log('收到数据：', data); } // 动态创建script标签 const script = document.createElement('script'); script.src = 'https://api.other-domain.com/data?callback=handleResponse'; document.body.appendChild(script);

服务端响应（PHP示例）：

<?php $data = ['name' => '张三', 'age' => 25]; $callback = $_GET['callback']; // 返回的是一段JS代码，而非JSON echo $callback . '(' . json_encode($data) . ')'; ?> // 实际响应内容：handleResponse({"name":"张三","age":25})

3.2 JSONP的优缺点与适用场景

优点：

  • 兼容性极佳：在所有支持JavaScript的浏览器上都能运行，甚至包括一些老旧的IE版本。
  • 实现简单：前后端改造量都很小。

缺点与注意事项：

  1. 仅支持GET请求：这是最大的限制，因为<script>标签加载资源本质上是GET。无法进行POST、PUT等操作。
  2. 安全性问题：由于完全信任并执行了来自外域的脚本，如果服务器被攻破，返回了恶意代码，客户端将直接受害。这是一种“远程代码执行”风险。
  3. 错误处理困难：<script>标签加载失败（404，500等）很难被标准的onerror事件完美捕获，不同浏览器表现不一。
  4. 缺乏灵活性：无法像Fetch API那样方便地设置请求头、读取响应头。

适用场景：

  • 需要兼容极度老旧浏览器（如IE8及以下）的项目。
  • 仅需要跨域获取公开数据（如获取天气、股票信息），且数据量小，使用GET请求足矣。
  • 快速原型验证，临时解决跨域问题。

实操心得：在现代Web开发中，JSONP已基本被CORS取代。除非有极强的历史兼容性要求，否则不建议作为首选方案。如果使用，务必确保请求的目标服务器是完全可信的。

4. 解决方案二：CORS —— 现代跨域的“官方护照”

CORS是“跨源资源共享”的缩写，它是W3C的标准，也是目前解决跨域问题最主流、最正规的方案。它允许服务器声明哪些外部源有权访问自己的资源。

4.1 CORS的工作原理：预检请求与简单请求

浏览器将CORS请求分为两类：简单请求和非简单请求。

1. 简单请求满足以下所有条件的请求被视为简单请求：

  • 方法为 GET、HEAD、POST 之一。
  • 请求头仅包含：Accept, Accept-Language, Content-Language, Content-Type (值仅限于application/x-www-form-urlencoded,multipart/form-data,text/plain)。
  • 没有使用自定义头（如X-Token）。

对于简单请求，浏览器直接发出请求，并在请求头中自动添加一个Origin字段，表明请求来源。服务器需要检查这个Origin，如果允许，就在响应头中包含Access-Control-Allow-Origin: *或Access-Control-Allow-Origin: https://www.my-app.com。

2. 非简单请求（需预检的请求）不满足简单请求条件的，就是非简单请求。例如使用了PUT、DELETE方法，或Content-Type是application/json，或设置了自定义头。

对于这类请求，浏览器会先使用OPTIONS方法发起一个“预检请求”到服务器，以获知是否允许实际请求。预检请求头会包含：

  • Origin: 请求来源。
  • Access-Control-Request-Method: 实际请求将使用的方法。
  • Access-Control-Request-Headers: 实际请求将携带的自定义头。

服务器必须响应这个OPTIONS请求，并在响应头中明确声明允许的源、方法和头：

HTTP/1.1 200 OK Access-Control-Allow-Origin: https://www.my-app.com Access-Control-Allow-Methods: GET, POST, PUT, DELETE Access-Control-Allow-Headers: X-Token, Content-Type Access-Control-Max-Age: 86400 // 告诉浏览器，1天内可以缓存这个预检结果，无需重复发起

只有预检请求通过后，浏览器才会发出真正的请求。

4.2 服务端如何配置CORS

这里以几种常见后端框架为例：

Node.js (Express):

const express = require('express'); const app = express(); // 使用CORS中间件（最简单） const cors = require('cors'); app.use(cors()); // 默认允许所有源 // 或进行精细控制 app.use(cors({ origin: 'https://www.my-app.com', // 允许的源 methods: ['GET', 'POST', 'PUT'], // 允许的方法 allowedHeaders: ['Content-Type', 'X-Token'], // 允许的头 credentials: true, // 允许发送Cookie（重要！） maxAge: 86400 }));

Spring Boot (Java):

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") // 针对哪些路径 .allowedOrigins("https://www.my-app.com") .allowedMethods("GET", "POST", "PUT", "DELETE") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

PHP (手动设置响应头):

<?php header('Access-Control-Allow-Origin: https://www.my-app.com'); header('Access-Control-Allow-Methods: GET, POST, OPTIONS'); header('Access-Control-Allow-Headers: Content-Type, X-Requested-With'); if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') { // 预检请求，直接返回200 exit(0); } // ... 你的业务逻辑 ?>

4.3 CORS实战中的关键细节与“坑”

  1. 关于Access-Control-Allow-Origin：

    • 设置为*表示允许任何源，但当请求需要携带凭证（如Cookie）时，不能使用*，必须指定明确的域名。
    • 在生产环境中，强烈建议使用白名单机制，动态判断请求的Origin头是否在允许列表中，而不是固定写死或全开。

  2. 携带凭证（Cookies/HTTP认证）：

    • 前端：在发起Fetch请求时，需要设置credentials: 'include'。在XHR中需要设置withCredentials = true。
    • 后端：响应头必须包含Access-Control-Allow-Credentials: true，并且Access-Control-Allow-Origin不能为*，必须是具体的源。
    • 否则，即使Cookie在请求中发送了，服务器返回的响应也会被浏览器忽略。

  3. 预检请求缓存：

    • 合理设置Access-Control-Max-Age可以大幅减少非简单请求的预检次数，提升性能。但要注意，如果允许的源、方法、头经常变化，缓存时间不宜过长。

  4. 非标准头与Access-Control-Expose-Headers：

    • 默认情况下，前端只能通过JS访问到CORS安全列表中的响应头（Cache-Control, Content-Language, Content-Type, Expires, Last-Modified, Pragma）。如果你在响应中设置了自定义头（如X-Total-Count），前端需要读取，则服务器必须通过Access-Control-Expose-Headers: X-Total-Count将其暴露出来。

踩坑实录：我曾遇到一个诡异的问题，前端一切配置正确，但就是收不到Cookie。排查了半天才发现，是后端Nginx配置中，在转发请求到应用服务器时，漏掉了Access-Control-Allow-Credentials和具体的Access-Control-Allow-Origin头。记住，所有经过的网关、代理、负载均衡器，都必须正确传递和设置CORS头。

5. 解决方案三：Nginx反向代理 —— 前端的“隐身衣”

如果后端服务不方便修改（比如使用的是第三方服务，或者老旧系统），或者你想在前端层面统一解决跨域问题，那么Nginx反向代理是一个极其强大和优雅的方案。

5.1 反向代理如何解决跨域？

其核心思路是“欺骗”浏览器。浏览器不是有同源策略吗？那好，我不让前端直接请求https://api.other-domain.com，而是让它请求一个和自己同源的地址，比如https://www.my-app.com/api-proxy/。然后，我们在www.my-app.com的服务器上（通常是Nginx），配置一个反向代理规则，将所有发往/api-proxy/的请求，透明地转发到真正的目标服务器https://api.other-domain.com。

对于浏览器来说，它始终是在和https://www.my-app.com通信，完美避开了跨域限制。而Nginx作为中间人，负责请求的转发和响应的回传。

5.2 Nginx配置详解

一个基础的解决跨域的反向代理配置如下：

server { listen 80; server_name www.my-app.com; location /api/ { # 核心：将 /api/ 开头的请求，代理到目标服务器 proxy_pass https://api.other-domain.com/; # 以下是一些关键配置，用于正确处理请求和响应 # 1. 修改请求头，确保目标服务器能收到正确的原始主机信息（可选） proxy_set_header Host $proxy_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 2. 处理CORS（如果目标服务器本身没有设置，可以在Nginx这里统一加） # 但更常见的做法是，因为代理后同源了，所以不需要CORS头。 # 如果目标服务器响应了CORS头，Nginx需要正确传递它们。 proxy_hide_header Access-Control-Allow-Origin; # 隐藏上游可能设置的不正确CORS头 add_header Access-Control-Allow-Origin * always; # 或者按需设置 add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS, PUT, DELETE' always; add_header Access-Control-Allow-Headers 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization' always; add_header Access-Control-Expose-Headers 'Content-Length,Content-Range' always; # 3. 非常重要！处理OPTIONS预检请求 if ($request_method = 'OPTIONS') { add_header Access-Control-Allow-Origin *; add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS, PUT, DELETE'; add_header Access-Control-Allow-Headers 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization'; add_header Access-Control-Max-Age 1728000; # 20天缓存 add_header Content-Type 'text/plain; charset=utf-8'; add_header Content-Length 0; return 204; # 直接返回204 No Content，不转发到后端 } } }

前端代码无需任何特殊处理，只需将请求地址从https://api.other-domain.com/user改为https://www.my-app.com/api/user即可。

5.3 Nginx方案的优劣与进阶用法

优势：

  • 对前端透明：前端代码无需关心跨域，就像访问本地接口一样。
  • 集中管理：可以在网关层统一处理认证、限流、日志、跨域等横切关注点。
  • 绕过客户端限制：可以代理那些不支持CORS的第三方服务。
  • 便于本地开发：开发时配置一个本地Nginx代理，可以无缝对接测试/生产环境API，避免本地起服务。

劣势：

  • 增加架构复杂度：需要维护Nginx配置。
  • 单点故障风险：代理服务器成为关键节点。
  • 性能开销：多了一次网络转发。

进阶场景：

  • 负载均衡：proxy_pass可以指向一个 upstream 组，实现负载均衡。
  • 路径重写：使用rewrite指令修改请求路径。
  • WebSocket代理：Nginx从1.3版本开始支持WebSocket代理，需要添加proxy_http_version 1.1;和proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";等配置。

注意事项：在配置中处理OPTIONS请求时，使用return 204;而不是proxy_pass，可以避免不必要的后端调用，提升效率。另外，add_header指令在if块中的行为有坑（继承问题），上述写法是经过实践检验的可靠写法。

6. 解决方案四：WebSocket —— 全双工通信的“绿色通道”

WebSocket是一种在单个TCP连接上进行全双工通信的协议。它本身不受同源策略限制。这意味着，你可以直接从https://www.my-app.com的页面，建立到wss://api.other-domain.com的WebSocket连接，而不会触发CORS错误。

6.1 为什么WebSocket可以跨域？

同源策略主要限制的是不同源之间的文档对象模型和XMLHttpRequest/Fetch请求。WebSocket协议在设计之初就被赋予了更高的权限，因为它建立的是一个持久的、双向的通信通道，其安全模型更多依赖于握手阶段的Origin验证，而非后续通信。

在建立WebSocket连接时，客户端会在握手请求头中携带Origin。服务器有权在握手阶段根据这个Origin决定是否接受连接。如果服务器不接受，它可以拒绝握手（返回非101状态码）。一旦连接建立，后续的数据帧传输就不再受同源策略约束。

6.2 服务端如何验证WebSocket的Origin？

这是确保WebSocket连接安全的关键。服务器必须在握手阶段检查Origin或Sec-WebSocket-Origin头。

Node.js (ws库)示例：

const WebSocket = require('ws'); const wss = new WebSocket.Server({ port: 8080 }); wss.on('connection', function connection(ws, request) { const origin = request.headers.origin; const allowedOrigins = ['https://www.my-app.com', 'https://dev.my-app.com']; if (!allowedOrigins.includes(origin)) { // 拒绝连接 ws.close(1008, 'Origin not allowed'); // 1008是策略违规状态码 return; } // 连接合法，处理业务逻辑 ws.on('message', function message(data) { console.log('received: %s', data); }); });

Nginx代理WebSocket： 如果你使用Nginx代理WebSocket，配置和普通HTTP代理略有不同：

location /ws/ { proxy_pass http://backend_ws_server; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # 重要：在代理层也可以进行Origin验证 if ($http_origin !~* (https://www.my-app.com|https://dev.my-app.com)) { return 403; } proxy_set_header Origin $http_origin; # 可选，传递给后端 }

6.3 WebSocket的适用场景与局限

适用场景：

  • 实时应用：聊天室、实时协作编辑、在线游戏、股票行情、监控仪表盘。
  • 推送服务：替代长轮询，实现服务器向客户端的主动消息推送。

局限与注意事项：

  1. 不是HTTP的替代品：WebSocket适合持续、高频的双向数据交换。对于传统的请求-响应模式（如获取用户信息、提交表单），RESTful API + CORS 更合适。
  2. 连接管理复杂：需要处理连接建立、断开、重连、心跳保活等状态。
  3. 服务端资源消耗：每个活跃连接都会占用服务器资源（内存、文件描述符）。
  4. Origin验证是必须的：绝对不要在生产环境中开放一个不验证Origin的WebSocket服务，否则可能成为攻击入口。

实操心得：对于现代实时应用，除了原生WebSocket，还可以考虑更上层的解决方案，如Socket.IO（提供了自动重连、房间、命名空间等特性）或云服务商提供的WebSocket服务。它们底层也是WebSocket，但封装了更多易用功能。

7. 其他方案与场景化选择

除了上述四大主流方案，还有一些特定场景下的解决方案。

7.1 PostMessage：跨窗口/跨iframe通信

如果你需要的是同一个浏览器内，不同标签页或iframe之间的通信，那么window.postMessage()API是官方推荐的安全方式。

原理：它允许来自不同源的窗口之间进行安全的、异步的消息传递。发送方指定目标窗口的origin，接收方通过监听message事件并验证事件的origin属性来决定是否处理消息。

示例：

// 父页面 (https://parent.com) const iframe = document.getElementById('myIframe').contentWindow; iframe.postMessage('Hello from parent!', 'https://child.com'); // 子页面 (https://child.com) 内 window.addEventListener('message', function(event) { // 重要：验证消息来源！ if (event.origin !== 'https://parent.com') return; console.log('收到消息：', event.data); // 可以回信 event.source.postMessage('Hello back!', event.origin); });

7.2 修改document.domain (已过时)

这是一个非常古老且限制极大的方法：如果两个页面拥有相同的基础域名（例如a.example.com和b.example.com），它们可以通过将各自的document.domain设置为example.com来实现同源，从而相互访问DOM。但此方法仅适用于同基础域名的子域之间，且现代浏览器中限制越来越多，不推荐使用。

7.3 图像Ping与表单提交

利用<img>标签的src或表单提交也可以发起跨域GET/POST请求，但无法读取响应内容，通常只用于数据上报、跟踪等单向通信场景。

8. 方案选型决策树与常见问题排查

面对一个具体的跨域需求，如何选择最合适的方案？可以参考下面的决策流程：

  1. 需求是否涉及不同浏览器标签/iframe？

    • 是-> 使用window.postMessage。
    • 否-> 进入下一步。

  2. 是否是全双工、持续的实时通信（如聊天、推送）？

    • 是-> 使用WebSocket（注意服务端Origin验证）。
    • 否-> 进入下一步。

  3. 你是否有权修改后端服务的响应头？

    • 是-> 首选CORS。这是最标准、最灵活的现代方案。
    • 否-> 进入下一步。

  4. 你是否能控制一个与前端同源的代理服务器？

    • 是-> 使用Nginx反向代理。这是解决第三方API跨域或统一管理的不二之选。
    • 否-> 进入下一步。

  5. 请求是否非常简单（仅GET）且对老旧浏览器兼容性有极端要求？

    • 是-> 考虑JSONP（务必注意安全风险）。
    • 否-> 重新评估需求，或考虑让有权限的人配置CORS或代理。

8.1 常见跨域问题排查清单

当跨域请求失败时，打开浏览器开发者工具的“网络”选项卡，按照以下顺序排查：

问题一：根本看不到请求发出？

  • 可能原因：请求被浏览器同源策略在发起前就拦截了（通常发生在复杂请求的预检阶段失败）。
  • 排查：检查控制台错误信息。如果是OPTIONS请求失败，重点检查服务端对OPTIONS方法的响应是否正确配置了CORS头。

问题二：请求发出了，也收到了响应，但被浏览器拦截了？

  • 可能原因：响应头中缺少或错误的CORS头。
  • 排查：
    1. 检查响应头是否有Access-Control-Allow-Origin，其值是否包含了请求的Origin（或为*）。
    2. 如果请求携带了凭证（Cookie），检查Access-Control-Allow-Origin是否为具体的源（非*），且Access-Control-Allow-Credentials是否为true。
    3. 如果是非简单请求，检查Access-Control-Allow-Methods和Access-Control-Allow-Headers是否包含了实际使用的方法和头。

问题三：预检请求（OPTIONS）成功了，但真实请求还是失败？

  • 可能原因：预检请求和真实请求的CORS头配置不一致，或者服务端对真实请求的处理逻辑中覆盖/删除了CORS头。
  • 排查：对比OPTIONS请求和真实请求的响应头，确保CORS相关头完全一致且正确。检查后端中间件或代码逻辑，确保在所有响应路径上都添加了CORS头。

问题四：本地开发正常，部署后跨域？

  • 可能原因：生产环境和开发环境的域名、端口不同。或者生产环境有CDN、网关、负载均衡器等中间层，它们没有正确传递或设置CORS头。
  • 排查：检查生产环境请求的完整路径和Origin。使用浏览器开发者工具查看网络请求和响应头的详细信息。逐一检查从浏览器到应用服务器之间的每一层（CDN、Nginx、API网关、应用服务器）的配置。

问题五：WebSocket连接失败？

  • 可能原因：握手失败。
  • 排查：
    1. 检查URL协议是否正确（ws://或wss://）。
    2. 检查服务端是否在握手阶段验证了Origin并允许当前源。
    3. 如果使用了Nginx代理，检查代理配置是否正确支持WebSocket（Upgrade和Connection头）。

跨域问题就像Web开发中的一道必修关卡，理解其背后的安全逻辑，掌握几种核心解决方案的原理和适用场景，就能在遇到问题时从容应对。记住，没有银弹，最好的方案永远是最适合你当前项目上下文的那一个。从简单的CORS配置开始，遇到复杂场景再考虑Nginx代理或WebSocket，在兼容性要求特殊的角落或许会用到JSONP，但务必把安全放在第一位。

网站建设 企业官网 运营推广
返回列表