绕过浏览器“安检”：JSONP 跨域实现与避坑指南

前端日常交互里最常撞墙的，就是浏览器的同源策略。域名、协议或端口哪怕差一个小数点，Fetch 或 Axios 发出的请求都会被直接拦截。在 CORS 成为标配之前，开发者靠 <script> 标签的“免检特权”硬生生劈开了一条路，这便是 JSONP。它原理简单，但落盘细节多，稍不留神就会引发内存泄漏或安全隐患。

核心机制并不玄乎：利用动态插入的 <script> 标签不受同源策略限制的特性，让后端将数据包裹成函数调用的格式返回。 浏览器解析到这段脚本后会立即执行，你预先注册的回调函数便顺势拿到 payload。整个过程就像寄信而非当面递送，绕过前台审查，直接送达收件人手里。

实际动手封装时，抓准四个关键节点就能跑通完整链路：

定义带命名空间的临时回调函数。不要直接用死板的 callback，拼上时间戳与随机后缀写入 window 对象，避免并发请求时互相覆盖。

动态创建 script 节点并拼接查询参数。将目标地址与 callback=自定义名称 组合赋值给 src，随后将节点塞进 document.head。

绑定生命周期钩子完成收尾。onload 触发意味着数据已安全交付，此时需同步清除 window 上的函数引用与 DOM 节点；onerror 则负责捕获网络异常或接口 404，防止任务悬空。

补齐超时降级策略。脚本标签加载失败不会抛出传统 XHR 错误，必须手动设定阈值（如 8 秒），超时未响应则主动触发错误回调并清理现场。

function fetchByJsonp(url, params = {}) {
  return new Promise((resolve, reject) => {
    const cbKey = `jsonp_cb_${Date.now()}_${Math.random().toString(36).slice(2, 8)}`;
    window[cbKey] = (res) => resolve(res);

    const qs = Object.entries(params)
      .map(([k, v]) => `${encodeURIComponent(k)}=${encodeURIComponent(v)}`)
      .join('&');

    const el = document.createElement('script');
    el.src = `${url}?${qs}&callback=${cbKey}`;

    el.onload = () => {
      delete window[cbKey];
      el.remove();
    };
    el.onerror = () => reject(new Error(`JSONP fetch failed for ${url}`));

    setTimeout(() => {
      el.onerror && el.onerror();
    }, 8000);

    document.head.appendChild(el);
  });
}

模板能跑通不等于能上线。很多团队在此处踩坑，主要源于对协议边界认知模糊。JSONP 天生仅支持 GET 请求，因为 <script> 发起的是资源抓取，HTTP 方法被底层锁定。若业务需要传递表单或大体积载荷，强行塞入 URL 参数会导致长度截断与缓存混乱，这时候应果断切换至 CORS 或代理中转。

安全层面的盲区同样隐蔽。如果后端直接拿前端传过来的 callback 值拼接字符串，攻击者完全可以在构造链接时将函数名改为 fetchCookies() 或篡改全局变量，造成数据渗漏。稳健的做法是在网关层限制回调名格式（仅允许字母数字开头），或在签名阶段加入时效验证。

如今新项目极少再引入 JSONP，但它留下的设计思路依然有价值。理解这套机制，等于摸清了浏览器安全沙箱的历史演进脉络。维护老系统时能快速定位拦截根因，编写第三方 SDK 时能兼容低版本环境，面对技术选型也能清楚知道何时该守旧、何时该革新。

跨域从来不是非黑即白的判断题。把 JSONP 的执行链路亲手跑通一遍，那些曾被拦截的报错信息会瞬间变得透明。下次再碰到历史接口握手失败，拆开看看参数挂载与回调清理的节奏，往往比盲目升级依赖库来得干脆。