jsonp能绕过跨域限制，靠的是浏览器对标签的特殊豁免，其核心是前端声明回调函数、动态创建标签、服务端返回callback({...})格式的可执行js，由浏览器自动执行完成数据传递。
JSONP 能绕过跨域限制，靠的是浏览器对 <script></script> 标签的特殊豁免——它加载远程 JS 时不受同源策略约束。这不是“破解”限制，而是利用了浏览器设计中本就允许的例外机制。
JSONP 的核心执行流程
整个过程依赖前后端协同，关键在“函数包裹 + 动态脚本加载”：
- 前端先声明一个全局函数（如
handleData），用于接收和处理数据 - 动态创建
<script></script>标签，src指向目标接口，并附带参数callback=handleData - 服务端收到请求后，不返回纯 JSON，而是返回一段可执行 JS：例如
handleData({"name":"张三","age":28}) - 浏览器加载该脚本后立即执行，相当于调用
handleData并把数据作为参数传入
手动实现 JSONP 请求的要点
不依赖框架时，需注意几个易错细节：
- 回调函数名必须是全局作用域下可访问的（不能写在 IIFE 或模块内部）
- 每次请求应清理已插入的
<script></script>标签，避免重复加载或内存泄漏 - 需手动处理超时和错误（
<script></script>标签无原生error事件监听，可用setTimeout模拟） - URL 中的
callback参数名需和服务端约定一致，常见还有jsonp、cb等
JSONP 与 CORS 的本质区别
二者解决的是同一问题，但思路完全不同：
- CORS 是浏览器与服务器协商的结果：服务器通过响应头（如
Access-Control-Allow-Origin）明确授权，浏览器据此决定是否放行请求 - JSONP 是“借道执行”：不走
XMLHttpRequest或fetch，而是假装加载第三方脚本，把数据藏在函数调用里“捎带”进来 - CORS 支持任意 HTTP 方法（GET/POST/PUT/DELETE）和自定义请求头；JSONP 只能发 GET 请求，且无法设置请求头
- CORS 有完善的错误捕获机制（如
catch）；JSONP 几乎无法区分网络失败、脚本语法错误或服务端返回异常
为什么现在很少直接用 JSONP
它曾是跨域主力，但已被更安全、更灵活的方案替代：
- 安全性风险高：服务端返回的 JS 会被无条件执行，若被劫持或注入恶意代码，会直接危害页面
- 服务端必须配合改造：每个支持 JSONP 的接口都要识别
callback参数并拼接响应，增加维护成本 - 现代浏览器全面支持 CORS，连 IE10+ 都可用，旧版兼容已不再是强需求
- 无法与现代前端生态深度集成（如 Axios 拦截器、React Query 数据流等）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
