My WebAPI部署在Intranet环境中。这意味着安全性不是我关心的问题。
CORS似乎对客户端更加友好，而且更易于实现。
我可能遗漏了其他问题吗？
这是一个相当宽泛的问题，可能需要一个独立的wiki。谷歌上也有很多关于这两者的内容，但我认为我可以抓住几个关键点。
- 如果您需要到服务器的只读ajax接口，并且需要支持IE<9、Opera<12或Firefox<3.5或其他各种较旧或晦涩的浏览器，CORS已过时，请使用JSONP。IE8和IE9排序支持CORS，但有问题，请参阅下面第一条评论中的链接
- 另一方面，如果您的web API是读/写（例如，完整的REST或仅POST/GET），而不是仅读（即GET），则JSONP将退出。使用CORSJSONP本质上是只读的
如果这两者都不是问题，我只会选择你最简单或最熟悉的。如果这是一种失败，请尝试CORS，因为它是一种更"现代"的解决方案，而JSONP更像是一种黑客攻击，将数据转换为脚本以绕过跨域限制。然而，CORS通常需要更多的服务器端配置。
如果您使用的是jQuery，我不确定您是从哪里想到CORS"对客户端更友好，更容易实现"的。请参阅https://gist.github.com/3131951。jQuery抽象了JsonP的细节，而CORS实际上在服务器端的实现可能有些棘手，这取决于您使用的技术。
我最近开发了一个web应用程序，使用jquery和backbone.js，它从我们控制的各种跨域web服务中读取信息，并最终使用Json-p而不是CORS，因为我们需要支持IE7，而且它在服务器端更简单（我们运行Django w/DjanoRestFramework），在客户端使用jquery几乎相同。
你说得很对。如果你不必支持遗留浏览器（6年多前发布的浏览器），我肯定会选择CORS。
CORS更容易实现，因为如果API还不支持JSONP或CORS，那么只添加几个静态头比修改响应主体更容易。
此外，使用CORS更容易缓存请求。即使有memcached内容，每个JSONP请求也需要是动态的。
JSONP仍然是一个脚本标记，因此无论它会导致某种程度的同步行为。CORS不会。
JSONP只能是GET。和CORS一样，你可以使用任何方法。
最后但并非最不重要的是，如果您使用的是jQueryv1.x，请考虑在某些常见情况下（例如网络错误），仍然不会为JSONP请求调用error和complete（或更好的fail和always）处理程序。当然也有变通办法（超时设置、jQuery JSONP插件），但我发现CORS不那么烦人，尤其是当跨域请求只来自移动设备（即混合应用程序）时，这样你就不需要支持不走运的浏览器了。
根据Spring文档，JSONP是一种黑客攻击，而不是跨源资源共享的适当解决方案。因此，如果您不关心安全性，那么只需在服务器上检查您的域名来源，并添加Access Control Allow origin Response标头。
我们的Web API无法在带有Windows身份验证的Safari（iOS 9.1）上工作。它适用于Safari+iOS 8.4。当我们改为JSONP时，Safari又开始工作了。有关详细信息，请查看此链接。