jsonp通过动态创建script标签、利用其不受同源策略限制的特性实现跨域，服务端将json数据包裹在回调函数中返回，前端执行该函数获取数据；它仅支持get、无错误处理、有xss风险，现已被cors等现代方案取代。
JSONP 是 JavaScript 早期应对 Ajax 跨域限制的一种“曲线救国”方式，它不真正绕过同源策略，而是巧妙避开——因为 <script></script> 标签天生不受该策略限制。
JSONP 的核心思路：用 script 加载执行代替 XMLHttpRequest
浏览器禁止 Ajax 向非同源地址发请求，但允许加载任意域名的 JS 文件。JSONP 就是把数据包装成函数调用语句，让服务端返回可执行的 JS 代码，前端提前定义好接收函数，等脚本一加载就自动执行并传入数据。
- 前端动态创建
<script></script>标签，src 指向跨域接口，并附带回调函数名参数（如?callback=handleUser） - 服务端收到请求后，不再返回纯 JSON，而是拼出类似
handleUser({"id":1,"name":"张三"})的字符串 - 浏览器下载并立即执行这段 JS，相当于调用了你预先写好的
handleUser函数，数据自然就进来了
典型实现步骤（原生 JS）
不需要引入任何库，几行代码就能跑通：
- 先声明全局回调函数，例如：
window.handleResponse = function(data) { console.log(data); }; - 构造 script 标签：
const s = document.createElement('script'); - 设置 src：
s.src = 'https://api.example.com/users?callback=handleResponse'; - 插入页面：
document.head.appendChild(s); - 为避免重复加载，可加逻辑移除已存在的同名 script 标签
为什么 JSONP 逐渐被弃用？关键局限很明确
它不是真正的 Ajax 替代方案，而是一种受限的“伪请求”机制：
- 只支持 GET 方法：无法发送 POST、PUT、DELETE，也不能带自定义请求头或 Cookie
- 无错误捕获能力：script 加载失败（404、超时、语法错误）时，不会触发 error 事件，只能靠定时器或 onerror 粗略判断
- 依赖服务端配合：必须要求接口支持 callback 参数，并按指定格式包裹响应体，否则无法使用
- 安全风险较高：执行的是第三方脚本，若服务端被劫持或注入恶意代码，会直接危害当前页面
- 无法设置请求超时或取消：一旦插入 script，就只能等执行或失败，没有 abort() 方法
它适合什么场景？现在还有必要用吗？
仅在极少数遗留系统或简单数据读取中仍有价值：
- 老项目兼容 IE6–8，且后端不支持 CORS 头配置
- 调用公开的、只读的第三方 API（如早期百度地图、天气接口），且明确提供 callback 参数
- 做快速原型验证，不涉及敏感操作或复杂交互
现代开发中，CORS 已成为标准解法；开发阶段可用本地代理（如 Webpack DevServer 的 proxy 或 Vite 的 server.proxy）；生产环境推荐由 Nginx 或网关统一处理跨域头。JSONP 更像是一个理解浏览器机制的历史切片，而非实用工具。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
