为何SVGZ对象的#document在本地服务器可访问但远程服务器不可用？附代码实例与问题补充

这事儿我太熟了！你遇到的问题本质就是浏览器的同源安全策略在搞鬼，咱们一步步捋清楚：

为什么本地正常、远程失效？ #

浏览器的同源策略会严格限制脚本访问来自不同域的资源内部内容——哪怕这个资源（比如你的SVGZ）能正常渲染。当SVGZ和网页在同一个本地服务器时，它们属于同域，浏览器默认允许脚本通过contentDocument访问其内部的#document；但远程服务器的SVGZ和你的网页域名不同，浏览器就会拦截脚本的访问请求，返回null。

至于你说控制台打印svgholder能看到#document，但脚本拿不到？这是浏览器控制台的特殊待遇——为了方便调试，控制台可以绕过同源策略展示资源的内部结构，但普通JS脚本没有这个权限，所以实际代码里还是拿不到。

解决思路 #

1. 让远程服务器配置CORS（最直接的方案） #

说服远程服务器的管理员在返回SVGZ文件时添加**跨域资源共享（CORS）**响应头，告诉浏览器允许你的网页域名访问这个资源的内部内容。

需要添加的HTTP头示例：

Access-Control-Allow-Origin: https://你的网页域名.com

如果是测试环境或者不在乎域名限制，也可以用*（生产环境不推荐，风险较高）：

Access-Control-Allow-Origin: *

不同服务器的配置方式：

• Apache：在.htaccess或服务器配置文件中添加

  <FilesMatch "\.svgz$">
      Header set Access-Control-Allow-Origin "https://你的网页域名.com"
  </FilesMatch>
  

• Nginx：在对应location块中添加

  location ~* \.svgz$ {
      add_header Access-Control-Allow-Origin "https://你的网页域名.com";
  }
  

2. 用自己的服务器做反向代理 #

如果没法修改远程服务器的配置，可以在你的服务器上设置反向代理，把远程的SVGZ文件通过自己的域名转发出去。这样对浏览器来说，SVGZ和网页属于同域，就不会有跨域限制了。

比如Nginx的反向代理配置示例：

location /svgz-proxy/ {
    proxy_pass https://outserver.com/;
    proxy_set_header Host outserver.com;
}

之后页面里的object标签就可以改成：

<object data="/svgz-proxy/1234567.svgz" id="svgholder" type="image/svg+xml"></object>

3. 把脚本嵌入SVGZ内部（备选方案） #

如果你有权修改远程SVGZ的内容，可以把操作SVG的脚本直接写到SVG文件里（SVG本身支持内嵌JavaScript）。这样脚本运行在SVG的上下文里，不需要跨域访问contentDocument，但这种方式维护起来比较麻烦，适合静态SVG的场景。

注意事项 #

• 确保远程服务器在返回压缩的SVGZ文件时，正确添加了CORS头——有些服务器可能会对压缩文件的响应头配置单独处理。
• 测试前记得清空浏览器缓存，避免旧的无CORS头的响应影响结果。

内容的提问来源于stack exchange，提问作者Chevelho51