太长不看
JSONP 就是个 dirty hack ，吃枣药丸，能不碰就不碰。不服来辩！
细节
即将接手一个前端项目。
这项目之前是用 Rails + Angular1 做的，现在我们打算把 Rails 干掉，所有数据都让前端直接从 api.example.com 取。
后端 api.example.com 一定是我们自己 serve ，但前端的话：
- 可能部署 NGINX 到各个客户服的务器上
- 也可能是我们自己的 admin.example.com
- 当然更有可能同时会有好几套，这还不确定
之前的思路是，前端判断一下其所处的环境是否支持 CORS ，不行的话用 JSONP 当做 fallback 。至于 GET 以外的请求，这边用 JSONP 模拟了一套实现，看起来相当完善，前后端都有支持。并且我们的请求都很小，似乎不用考虑 413 的问题。
而现在我个人的想法是，无论部署在哪，都让跑这个项目的那个 NGINX 做一次 proxy_pass ，反代到 api.example.com （对应 1 ），或是反代到我们私有网络跑 api 的那台机器上（对应 2 ）。这样的优点至少有：
- 跨域这件事情根本不存在了，也不用去考虑 CORS 的各种坑
- 客户方面，只需要跑 NGINX 的那台机器连得到 api.example.com 就行，跑浏览器的机器可以是纯内网环境
缺点：
- 多了一次代理转发，做反代的机器机器会有额外性能开销（如果和 api 不是同一个 NGINX 的话）
- 本来前端所有的文件可以都交给 CDN ，现在则必须要一台服务器了
总之在我印象中，JSONP 这玩意就是落后于时代（亦或是超前于时代）的一个 hack 。以前、现在、未来都未曾、没有、不会出现在 W3C 或是 RFC 标准中，应该被抵制才对。
我目前还没有说服团队成员放弃 JSONP ，尤其是用 JSONP 模拟实现了一整套非 GET 请求的前辈。
请各位 dalao 赐教。
1
Select Language