PHP中CORS与JSONP选哪个_两种跨域方案对比与选择【详解】

jsonp仅支持get请求，无法处理post；php需用cors替代，正确设置access-control-allow-origin、headers等响应头，并注意代理层和cdn影响。

jsonP在PHP里根本没法处理POST请求

JSONP只是个“骗浏览器”的技巧，靠动态插入<script></script>标签加载远程JS，所以它天然只支持GET。你哪怕在PHP里写了$_POST接收逻辑，前端用JSONP发过去，实际发的还是GET请求，$_POST永远为空。

• 想传表单数据、文件、长参数？JSONP直接歇菜
• PHP后端用header('Content-Type: application/javascript')返回带回调函数的JS，这是唯一能走通的路
• 现代浏览器对<script></script>标签的CSP策略越来越严，某些配置下JSONP会直接被拦截，连错误都不报

PHP设置CORS头必须覆盖所有必要字段

光写Access-Control-Allow-Origin: *只够应付最简单GET请求。一旦前端发了带Authorization头的请求，或用了Content-Type: application/json，PHP就得同步放开Access-Control-Allow-Headers和Access-Control-Allow-Credentials，否则预检（OPTIONS）一定失败。

• Access-Control-Allow-Origin设为*时，Access-Control-Allow-Credentials必须为false，否则浏览器拒绝响应
• 要带cookie登录态，得把Access-Control-Allow-Origin改成具体域名（如https://myapp.com），不能用*
• PHP里建议在入口统一加头，而不是每个接口单独判断；漏加一个Access-Control-Max-Age，每次请求前都得跑一次OPTIONS

PHP里JSONP容易被xss利用，CORS则依赖浏览器校验

JSONP的回调函数名来自用户输入（比如URL里的callback=alert），如果PHP没过滤就直接拼进响应体，等于把<script></script>执行权交给了攻击者。而CORS机制完全由浏览器控制，PHP只要按规范返回头，浏览器自己决定放不放行——前提是你的域名、协议、端口确实匹配。

• JSONP必须手动校验$_GET['callback']，只允许字母数字和下划线，拒绝callback=alert(1)这种
• CORS头若写错（比如Access-Control-Allow-Origin多了一个空格），chrome开发者工具Network面板里看不到任何提示，只会显示“CORS Error”——得翻console里的完整错误信息才能定位
• 本地开发时用file://协议打开HTML，CORS会被强制禁用，JSONP反而能跑通，但这不是解决方案，是掩耳盗铃

现代项目别硬套JSONP，除非真要兼容IE8

IE8/9连XMLHttpRequest跨域都不支持，只能靠XDomainRequest或JSONP。但2024年还在维护需要IE8兼容的PHP后台，基本意味着整个技术栈已冻结。这时候还选JSONP，等于主动放弃fetch、AbortController、streaming响应等所有现代能力。

立即学习“PHP免费学习笔记（深入）”；

• Vue/React项目默认用fetch，它根本不认JSONP；强行封装一层“JSONP适配器”，后期维护成本远高于初期改CORS
• 如果PHP接口同时被Web和App调用，App通常走原生HTTP库，压根不解析JSONP格式，只认标准JSON+状态码
• 真正卡住的往往不是PHP配置，而是nginx/apache反向代理层没透传CORS头，或者CDN缓存了带CORS头的响应导致污染

事情说清了就结束。