根据评论更新：

简短版： 没关系，但可能取决于他们托管的内容。它们都托管不同的东西：Google 不托管 jQuery.Validate，Microsoft 不托管
jQuery-UI，自 2016 年以来他们托管了！！，Microsoft
提供了原本可以通过它们提供服务的脚本，ScriptResource.axd并且更容易集成（例如ScriptManager 与 ASP.净
4.0）。

重要提示： 如果您正在构建 Intranet 应用程序，请远离 CDN 方法。谁来托管它并不重要，除非您在内部 非常
超载的服务器上，否则没有 CDN 可以为您提供比本地 100mb/1GB 以太网更高的性能。如果您将 CDN 用于严格的内部应用程序，则会 损害性能
。 正确设置缓存过期标头并忽略仅
Intranet 方案中存在的 CDN。

被阻止的机会似乎大致相同，几乎为零。我处理过的合同并非如此，但这似乎是个例外。此外，自从最初发布此答案以来，围绕它的上下文发生了很大变化，Microsoft
CDN 取得了很大进展。

我目前正在进行的项目同时使用了最适合我们解决方案的 CDN。有几个因素在其中起作用。按照 HTTP
规范的建议，使用 较旧浏览器
的用户仍然可能会在每个域中同时发出 2
个请求。对于任何运行任何支持流水线的新东西（每个当前浏览器）的人来说，这都不是问题，但基于另一个因素，我们也正在消除这个限制，至少就
javascript
而言。

我们使用的 Google 的 CDN：

• jquery.min.js
• jQuery-ui.min.js。

我们使用的微软 CDN：

• 微软Ajax.js
• MicrosoftAjaxWebForms.js（直到 4.0 我们没有完全删除所有更新面板）
• jQuery.Validate.min.js

我们的服务器：

• Combined.js?v=2.2.0.6190 (Major.Minor.Iteration.Changeset)

由于我们构建过程的一部分是合并和缩小所有自定义
javascript，因此我们通过自定义脚本管理器执行此操作，该管理器包括这些脚本的发布或调试（非缩小）版本，具体取决于构建。由于 Google 不托管
jQuery 验证包，这可能是不利的一面。MVC 在其 2.0 版本中包含/使用它，因此您可以完全依赖 Microsoft 的 CDN
来满足您的所有需求，并且所有这些都通过 ScriptManager
自动完成。

唯一要提出的其他论点是 DNS 时间，这在页面加载速度方面是有代价的。 平均而言：
仅仅因为它被使用得更多（它的使用时间更长）ajax.googleapis.com可能会比 更早地被 DNS
返回ajax.microsoft.com，仅仅是因为本地 DNS 服务器更有可能收到它的请求（这是该地区的第一个用户惩罚） . 这是一件 非常
小的事情，只有在性能非常重要时才应考虑，精确到毫秒。
（是的：我意识到这一点与我同时使用两个 CDN 是相反的，但在我们的例子中，DNS 时间远被发生的 javascript/阻塞的等待时间所掩盖）

最后，如果您还没有看过它，最好的工具之一是Firebug和一些插件：Page
Speed和YSlow。如果您使用
CDN，但由于没有缓存标头，您的页面每次都请求图像，那么您就错过了唾手可得的果实。Firebug 的 Net
面板可以快速为您提供页面加载时间的快速细分，Page Speed/YSlow 可以提供一些很好的建议来帮助您。