本文详细解析了Ajax跨域访问的安全限制原因，并系统梳理了五种常见的跨域解决方案。包括Web代理方式、动态Script标签方式（JSONP）、iframe嵌入方式、用户本地转储方式以及服务端动态加载JS小工具方式。每种方案均分析了其适用场景、优缺点及实现原理，帮助开发者根据实际需求选择最合适的跨域处理策略。
Ajax跨域访问概述
当Ajax请求的目标地址与当前页面不同（协议、域名或端口任意一项不一致）时，即发生跨域访问。例如，通过Ajax调用城市天气预报或IP查询等公共服务接口时，便涉及跨域场景。出于安全考虑，浏览器会拒绝此类非本域的资源请求授权。
与Ajax不同，script和iframe标签的src属性不受跨域限制。因此，Ajax跨域的一种常见思路是利用这一特性以及JavaScript对JSON的支持。外部服务只需返回一段JavaScript代码或JSON数据，即可被Ajax成功获取。
出于安全机制，客户端JavaScript通过XMLHttpRequest只能向同源网站发送请求。例如，从www.readlog.cn向test.readlog.cn请求数据会被浏览器阻止。尽管存在限制，但仍有多种方法可以解决跨域问题，下文将逐一整理。
Web代理方式
解决方式1：Web代理方式（部署在服务器A）
该方案由服务器A代替用户页面与外部服务交互，并返回处理后的结果。此方法能解决大多数跨域访问问题，但前提是服务器A必须提供Web代理支持，且服务器A与服务器B需紧密协作。此外，该方式会增加服务器A的负担，且无法代为保存用户的Session状态。
动态Script标签方式
解决方式2：动态Script标签方式（部署在服务器A）
MYMSN门户曾采用此方式，尽管其当时未涉及跨域访问问题。该方法通过在页面内动态生成新的script标签来实现跨域数据获取。
iframe嵌入方式
解决方式3：iframe嵌入方式（部署在服务器A）
参考JavaEye上一篇关于跨域访问的帖子，作者提到已使用iframe方式解决跨域问题。通过iframe进行数据提交和获取是可行的，但由于父窗口与子窗口在跨域情况下无法直接交互，因此难以对父窗口的界面效果产生直接影响。
在页面内嵌或动态生成指向其他网站的iframe后，两个网页可以通过修改对方的anchor hash fragment（锚点哈希片段）来传输消息。修改锚点不会导致浏览器重新加载页面，从而保持网页状态。网页本身可通过定时器（timer）检测锚点变化，进而相应地改变自身状态。
用户本地转储方式
解决方式4：用户本地转储方式（客户端本地处理）
利用IE依附于Windows平台的特性，提供了一种基于iframe并利用内存“绕行”的方案。两个window之间可通过Windows剪贴板进行数据传输，只需在接受数据的一方设置Interval进行轮询，获取结果后清除Interval即可。然而，Firefox的平台独立性导致其不支持剪贴板方式，且旧版Firefox的插件漏洞已被修复，因此无法通过内存实现此技巧。此外，Firefox也不支持文件操作（无法通过Cookie跨域传递数据），使得这种技巧性方式仅能在IE中使用。
服务端动态加载JS小工具
解决方式5：服务端动态加载JS小工具（实质仍为服务器A通过iframe与服务器B通信）
该方案旨在解决用户向Bookmark服务器提交网页URL（包括Tag、Notes等）时的问题。
关于URL的提交，至少存在以下三种方式：
1. 登录Bookmark服务器的提交页面，通过该页面将URL提交给服务器。 2. 安装浏览器插件，通过插件将URL提交给服务器。 3. 从Bookmark服务器动态加载JavaScript小工具到当前页面，通过该工具完成提交工作。
第一种方式开发最简单，但对用户而言较为繁琐，每次均需先登录Bookmark服务器才能提交；第二种方式涉及插件开发，且用户通常不喜欢浏览器中安装过多插件；第三种方式开发难度适中，且避免了频繁登录服务器的麻烦，因此最终采用此方案。该动态加载的JavaScript小工具除生成供用户填写信息（URL、tag、notes等）的用户界面外，还需在用户点击提交时完成与服务器的通信功能。