手写 JSONP 教程：带你回望跨域的早期岁月

今天，我要亲手实现一个 JSONP，不仅是为了学习一段代码，更是为了触摸那段历史，理解前辈们是如何用智慧绕过限制，点亮了早期 Web 应用的交互之光。

JSONP 的核心思想

同源策略限制了 XMLHttpRequest，但它有一个“漏洞”：它并不限制带有 src 属性的标签，比如 <script>、<img> 和 <iframe>。它们天生就具备从任何地方加载资源的能力，否则你就无法在你的网站上使用 CDN 的图片或脚本了。

JSONP 正是利用了 <script> 标签的这个特性。它的核心思想可以概括为以下对话：

• 前端页面：（对服务器喊话）“你好，我需要一些数据。但我不能直接用 AJAX 拿。这样吧，我动态创建一个 <script> 标签来请求你的一个地址。另外，我已经在我的页面上准备好了一个叫 myCallbackFunction 的函数，请你把数据作为参数，放进这个函数调用里，然后把整个 myCallbackFunction({ ...data... }) 作为一段 JavaScript 文本返回给我。”
• 服务器：（收到请求后）“好的，没问题。这是你要的数据，我已经用你指定的回调函数名‘包裹’（Padding）好了。”

于是，当前端页面加载完这个 <script> 标签后，它实际上是在执行一段从服务器返回的 JavaScript 代码，这段代码恰好调用了我们预先定义好的全局函数，数据也就自然而然地被传递了进来。

整个过程没有使用 XMLHttpRequest，完美绕过了同源策略。

封装我们自己的 JSONP 工具

让我们来封装一个通用的 jsonp 函数。它应该接收一个包含 url、params 和 callback 的配置对象。

/**
 * 一个简单的 JSONP 实现
 * @param {object} options - 配置对象
 * @param {string} options.url - 请求的 URL 地址
 * @param {object} [options.params] - 需要传递的参数
 * @param {string} [options.callbackKey='callback'] - 与后端约定的回调函数参数名
 * @param {function} options.callback - 成功时调用的回调函数
 */
function jsonp({ url, params = {}, callbackKey = 'callback', callback }) {
 // 1. 生成一个独一无二的回调函数名，防止并发请求时冲突
 const callbackName = `jsonp_callback_${Date.now()}_${Math.floor(Math.random() * 100000)}`;

 // 2. 将回调函数挂载到 window 上，使其成为全局函数
 // 这是最关键的一步，因为服务器返回的脚本将直接调用这个函数
 window[callbackName] = function(data) {
    // 成功接收到数据后，调用我们真正的回调函数
    callback(data);

    // 3. 清理工作：用完即焚
    // 移除挂载到 window 上的函数，避免内存泄漏和全局污染
    delete window[callbackName];
    // 移除注入的 script 标签
    document.head.removeChild(scriptElement);
  };

 // 4. 准备参数，并将其拼接到 URL 上
 const paramsArray = [];
 for (let key in params) {
    paramsArray.push(`${encodeURIComponent(key)}=${encodeURIComponent(params[key])}`);
  }
 // 加上与后端约定的回调函数名参数
  paramsArray.push(`${callbackKey}=${callbackName}`);

 const paramsString = paramsArray.join('&');
 const finalUrl = url.includes('?') ? `${url}&${paramsString}` : `${url}?${paramsString}`;

 // 5. 创建并注入 <script> 标签，发起请求
 const scriptElement = document.createElement('script');
  scriptElement.src = finalUrl;
 document.head.appendChild(scriptElement);

 // （可选）错误处理
}

如何使用它？

假设我们有一个第三方天气服务，它支持 JSONP。

// 发起一次 JSONP 请求
jsonp({
 url: 'https://api.xxx.com/jsonp/city',
 params: {
    name: 'Beijing'
  },
 // 后端接口约定的回调参数名，默认为 'callback'
 // callbackKey: 'cb', 
 callback: function(data) {
    // 在这里，我们成功拿到了跨域数据！
    console.log('当前天气:', data);
    // 预期的 data 格式: { temperature: '35°C', condition: '晴' }
  }
});

// 此时，浏览器网络面板会看到一个类似这样的请求：
// https://api.xxx.com/jsonp/city?name=Beijing&callback=jsonp_callback_1752844122915_12345

// 服务器会返回这样的内容（Content-Type: application/javascript）：
// jsonp_callback_1752844122915_12345({ "temperature": "35°C", "condition": "晴" });

当浏览器加载并执行这段返回的脚本时，我们挂载在 window 上的 jsonp_callback_... 函数就被调用了，数据被成功捕获，而那个临时的 <script> 标签和全局函数也随之被销毁，整个过程干净利落。

JSONP 的局限性

尽管 JSONP 非常巧妙，但它终究是特定历史时期的产物，带着明显的时代烙印和局限性：

1. 只支持 GET 请求：因为 <script> 标签的 src 只能发起 GET 请求，所以 JSONP 天然无法实现 POST、PUT 等操作。
2. 安全性问题：JSONP 的安全性是它最大的软肋。你必须完全信任提供 JSONP 服务的第三方。如果该服务器被恶意攻击，返回的不再是数据，而是一段恶意脚本，你的网站将毫无防备地执行它，这可能导致 XSS 攻击。
3. 简陋的错误处理：我们无法像 XMLHttpRequest 那样精确地捕获 HTTP 状态码（如 404, 500）。我们只能通过 onerror 事件或者设置一个计时器（timeout）来判断请求是否失败，但这并不能告诉我们失败的具体原因。

随着 Web 的发展，我们需要更安全、更强大、更标准的跨域解决方案。于是，CORS 应运而生，它通过标准的 HTTP 头部字段，让服务器和浏览器进行协商，从而安全地实现了跨域资源访问。CORS 支持所有 HTTP 方法，提供了完善的错误处理机制，成为了现代 Web 开发的事实标准。

以上关于手写 JSONP 教程：带你回望跨域的早期岁月的文章就介绍到这了，更多相关内容请搜索码云笔记以前的文章或继续浏览下面的相关文章，希望大家以后多多支持码云笔记。