企业官网建设流程全解析

前一阵子帮客户折腾一个老项目，背景是典型的JEECMS门户站，内容采编都在后台，图片量一大，服务器磁盘和带宽都吃紧，就把图片分发到独立的FTP图片服务器上。结果刚上线就被人找上门：“首页的轮播图裂了，后台传图正常，前台就是显示不出来”。我打开浏览器F12一看，控制台里赫然一行红字——跨域访问被拒绝。后来花了半天时间把整条链路捋了一遍，从JEECMS的图片路径生成规则，到FTP存储策略，再到前端的加载方式，最后用一套组合方案把问题彻底解决掉。

这篇文章就把我这次完整的排查过程和解决方案写出来。不管你是刚接手JEECMS项目的新手，还是被图片跨域问题折磨过的老手，按照这里的思路走一遍，基本都能搞定。

1. 问题本质：为什么会出现“跨域显示失败”

先别急着复制配置，搞清楚原理比什么都重要。很多人在这一步就翻车，改了一堆配置，结果更乱。

1.1 同源策略到底是什么

浏览器有个核心安全机制叫“同源策略”。所谓同源，指的是协议（http/https）、域名（example.com）、端口（8080）三者完全一致。只要有一个不一致，浏览器就视为跨域。

在JEECMS的默认安装里，前台页面、后台管理、上传图片都在同一个应用下，协议域名端口全一致，所以图片的 标签能正常加载。但一旦把图片丢到独立的FTP图片服务器上，图片地址就变成了类似http://img.example.com/upload/2025/03/18/xxx.jpg，而页面本身是http://www.example.com/，域名不一致，跨域就出现了。

这里有个容易混淆的地方：普通的<img src="http://img.example.com/xxx.jpg">标签加载图片，其实不受同源策略的严格限制，浏览器允许这种“跨域读取”。那为什么还会出现“跨域访问被拒绝”？

1.2 真正的触发点

我这次遇到的情况，问题出在JEECMS后台生成的图片路径，不是直接的<img>标签，而是经过了一层动态拼接。有些模板里用了JavaScript动态注入图片地址，或者用了canvas处理图片，这时候浏览器会以更严格的策略来校验跨域请求。

还有一种很常见的情况是：图片URL走的是/upload/xxx.jpg这类相对路径，但JEECMS在生成静态页时，会把路径补全成带域名的绝对地址。如果补全时用的是后台配置的“网站域名”而不是实际的访问域名，那生成的图片地址自然就不对了。

这句话你细品一下——大多数“跨域显示失败”根本不是浏览器拦截了图片，而是URL地址本身就拼错了，或者走了AJAX/JS的方式去拉取图片资源。

1.3 影响范围有多大

跨域问题的影响不只是图片裂掉。在JEECMS里，FTP图片服务器还关联着：

• 前台页面的列表缩略图
• 内容详情页的大图
• 后台内容编辑时预览图片
• 部分模板调用了图片接口获取焦点图数据

如果路径生成有偏差，以上所有位置全部失灵。所以这个问题的排查面其实很广，不是改一个地方就能解决的。

2. 方案盘点：三条主流解决路径怎么选

我当时把市面上的常见方案整理了一遍，总结下来就是三条路。每条路都能用，但适用场景完全不同。

2.1 前端反向代理方案

思路：不改动JEECMS的图片路径生成逻辑，只在前端Nginx层做一个反向代理，把/img/开头的请求转发到FTP图片服务器的实际地址上。

这种方式最推荐，理由有三点：

1. 图片路径在页面里看起来是同域的，浏览器根本不会触发跨域校验
2. 不需要改动JEECMS的系统代码，风险最低
3. 后续如果更换图片服务器域名，只要改Nginx配置，前后端代码都不用动

2.2 后端统一入口转发方案

思路：在JEECMS的Java代码层面，新增一个图片访问的Controller，通过流的方式从FTP服务器拉取图片再输出给前端。

这个方案的缺点很明显：图片请求是高并发场景，每张图都走一次Java层的流转发，对应用服务器的性能和带宽消耗都很大，会拖垮原本就紧张的Tomcat线程池。只适合图片量很小、且没有Nginx可用的极端场景。

2.3 改造JEECMS路径元数据方案

思路：从源头解决，让JEECMS在生成图片路径时直接生成为图片服务器的完整地址，配合FTP服务器自身的跨域响应头（比如Access-Control-Allow-Origin）来放行。

这方案适合图片服务器独立配置了CORS响应头的情况，但有个前提：你要能控制图片服务器的Nginx或Apache配置。而且只要存在JS动态加载图片、canvas跨域污染这类场景，光靠服务端CORS头是不够的，依然会有浏览器拦截。

2.4 我的最终选择

综合考量之后，我选了Nginx反向代理为主，JEECMS路径配置为辅的组合拳。既解决跨域问题，也让前台图片路径保持整洁统一，后续维护成本最低。

3. 完整实操：JEECMS + FTP + Nginx反代配置全记录

下面进入正题。按照我的操作步骤一步步来，基本不会再踩坑。

3.1 前置准备

我这次的环境如下，方便你对照：

3.2 Nginx反向代理配置

在Nginx的配置文件里，增加一个location规则。以我这次为例，我希望前台图片地址是http://www.example.com/img/upload/xxx.jpg，实际图片文件在FTP服务器http://img.example.com/upload/xxx.jpg。

server { listen 80; server_name www.example.com; # 其他配置省略 location /img/ { proxy_pass http://img.example.com/; proxy_set_header Host img.example.com; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 30s; proxy_read_timeout 60s; } }

这里有几个细节必须注意：

• proxy_pass后面的URI很关键。http://img.example.com/结尾带/，表示把/img/upload/xxx.jpg里的/img/前缀替换掉，转发到http://img.example.com/upload/xxx.jpg。如果不带/，转发过去就是http://img.example.com/img/upload/xxx.jpg，FTP服务器上根本没有这个目录，照样404。
• proxy_set_header Host要设置成图片服务器域名，否则部分FTP服务器的虚拟主机配置会找不到对应的站点。
• 必须要测试一下大图片的加载。图片文件动辄几百KB甚至几MB，proxy_read_timeout如果设置太短，大图会加载一半断掉。

配置改好之后，执行以下命令让Nginx生效：

nginx -t nginx -s reload

然后在浏览器里直接访问http://www.example.com/img/upload/xxx.jpg，如果能看到图片，说明反向代理已经通了。

3.3 JEECMS后台的FTP和域名配置

接下来处理JEECMS侧。登录后台，找到配置管理的相关菜单，不同版本位置略有差异，但核心设置项是一致的。

第一处，是FTP服务器配置。这里需要填写FTP服务器的连接信息：

• FTP地址：填写FTP服务器的IP或域名
• FTP端口：默认21
• FTP用户名/密码：有上传权限的账号
• FTP目录：对应服务器上存储图片的根目录，比如/data/ftpdata

第二处，是图片访问URL前缀。这个字段决定了前台展示图片时拼接的完整地址。这是整个方案中最关键的一步。

这里有两种处理方式：

• 如果走Nginx反代方案，这个前缀就填写http://www.example.com/img，前台图片地址会生成为http://www.example.com/img/upload/xxx.jpg，触发Nginx转发到FTP服务器。
• 如果直接指向FTP的图片域名，就填写http://img.example.com，但这种情况下如果模板里有JS加载图片，跨域问题依然需要额外配置CORS来解决。

我选择的是第一种，这样所有图片请求都走主站域名，同源要求百分百满足。

3.4 模板层的调用方式

在JEECMS模板中，图片的标签一般长这样：

<img src="${contentUrl!}" alt="${content.title!}" />

或者取内容的第一张图片：

<img src="${content.typeImg!}" alt="${content.title!}" />

这里有个容易忽略的点：变量输出的是相对路径还是绝对路径，受JEECMS后台“生成静态页URL”相关配置影响。如果你在后台配置了域名补全，模板里输出的就是完整URL；如果没配置，输出的是/upload/xxx.jpg这类相对路径，此时浏览器会根据当前页面域名自动拼成http://www.example.com/upload/xxx.jpg，跟Nginx反代的路径就对不上了。

所以请在后台把“URL前缀”“域名”等配置统一为http://www.example.com，并且确保图片路径是以/img/开头的完整路径。模板语言本身不用大改。

3.5 验证整个链路

配置完成后，按以下顺序做验证：

1. 在后台新建一篇包含图片的内容，确认FTP上传成功
2. 在内容详情页右键查看图片地址，确认前缀是http://www.example.com/img/...
3. 直接访问该图片地址，看Nginx是否能正常转发
4. 清空浏览器缓存（包括CDN缓存），强制刷新页面，确认图片正常展示

整个链路如下：图片上传到FTP服务器 -> 后台数据库记录图片路径 -> 前台静态页生成图片URL -> 浏览器请求主站域名/img/路径 -> Nginx反代转发到FTP域名 -> FTP服务器返回图片内容。

4. 性能与安全：图片跨域方案之外的加固措施

图片能显示了只是第一步。真实生产环境里，还有两方面问题必须处理，否则后面肯定出事。

4.1 防盗链配置

图片域名一旦暴露在网络上，很容易被其他人直接引用盗图，消耗你的服务器带宽。Nginx里配置防盗链非常简单：

location ~* \.(jpg|jpeg|png|gif|webp)$ { valid_referers none blocked server_names www.example.com *.example.com; if ($invalid_referer) { return 403; } }

这条规则只允许来自主站域名的请求访问图片，其他来源一律403。需要注意的是，有些移动端App或小程序请求图片时不带Referer，所以none参数要保留，否则会影响正常用户。

4.2 浏览器缓存与Nginx缓存

图片资源的特点是变化频次低、文件体积大。如果不做缓存，每次刷新页面都去FTP服务器拉原始图片，压力很大。Nginx里可以加一层expires缓存：

location /img/ { proxy_pass http://img.example.com/; proxy_set_header Host img.example.com; expires 7d; add_header Cache-Control "public, max-age=604800"; }

这样浏览器会在本地缓存图片7天，Nginx层也会缓存转发响应，有效降低FTP服务器的请求量。

4.3 HTTPS协议下的跨域坑

如果站点启用了HTTPS，图片地址必须也用HTTPS，否则浏览器会出现“混合内容”警告，图片有可能被拦截。我在配置Nginx反代时，直接让/img/路径跟随主站走HTTPS：

location /img/ { proxy_pass http://img.example.com/; proxy_set_header Host img.example.com; proxy_redirect http://img.example.com/ https://www.example.com/img/; expires 7d; }

注意proxy_redirect这行。如果FTP服务器上某些接口返回了重定向，Nginx会把它改写成主站对应的HTTPS地址，避免用户浏览器被引导回HTTP链接。

5. 常见问题与排查技巧实录

这次实操过程里，我踩了好几个坑，也帮客户处理了几个典型的疑难杂症。整理成速查表，供各位直接对号入座。

5.1 问题速查表

5.2 排查思路：先定位是URL错误还是跨域拦截

这是最核心的判断方法。图片裂了之后，先右键图片选“在新标签页打开”，看浏览器地址栏的URL是否符合预期。

如果URL是http://www.example.com/img/upload/xx.jpg但访问报404，说明Nginx转发路径或FTP目录有问题，问题在服务器配置层。

如果URL是http://img.example.com/upload/xx.jpg然后浏览器直接拦截，说明JEECMS的URL前缀配置没生效，图片地址被改回了图片服务器域名，问题在JEECMS配置层。

按照这个方法，十分钟内就能把问题范围缩小一大半，避免无头苍蝇一样乱改配置。

5.3 一个容易踩的坑：Nginx缓存旧配置

Nginx的配置文件修改过后，执行nginx -s reload，有时会发现不生效。尤其在Docker容器里跑Nginx时，nginx -s reload可能压根没信号发给master进程。我遇到过几次这种情况，后来干脆用docker restart nginx容器名强制重启，反而更干脆。

另外，浏览器自身的缓存也容易误导排查。配置改好了，刷新页面还是老样子，换成无痕模式一看，好了，那就是本地缓存的问题，不是服务器配置的问题。

5.4 数据层面的路径修复

有一次客户的问题最棘手——图片FTP已经搭好了，Nginx反代也配好了，但历史内容里的图片地址已经存成了http://img.example.com/upload/xxx.jpg的绝对路径，走的是图片服务器域名，跨域问题依然存在。

这种场景下，我可以两条路走：

1. 在Nginx里再加一条规则，把img.example.com的请求也反向代理到主站（相当于图片域名也由主站Nginx接管），从根本上消除跨域源。
2. 用SQL批量更新数据库中所有图片路径，把http://img.example.com前缀替换成http://www.example.com/img。

实际处理中我两种都试过。改Nginx更快，但对DNS和证书有要求；改SQL更彻底，但需要谨慎操作，先备份数据库，然后小范围UPDATE测试，再全量执行。

6. 这类方案还能怎么扩展

JEECMS的图片跨域本质上是一个静态资源托管架构问题。搞明白这个方案后，你可以很容易把思路迁移到其他场景。

场景一：腾讯云COS/阿里云OSS替代FTP图片服务器。基本思路一样，Nginx反代路径改成proxy_pass https://bucket.cos.region.myqcloud.com/;，前台的图片URL仍然保持主站域名，跨域问题和防盗链问题同时解决。

场景二：视频和附件资源。JEECMS不只传图片，还有视频、PDF等附件。同样的思路，把附件URL前缀也指向Nginx反代路径，统一走主站域名，省心省力。

场景三：前后端分离架构的图片服务。如果你把JEECMS的模板页面改造成前后端分离的Vue项目，图片加载同样会存在跨域。这时候在Nginx层把/img/反代到图片服务器，前端项目里所有图片地址直接用/img/...相对路径，完美避坑。

从我个人的体会来说，跨域问题听起来玄乎，但80%的情况都是路径配置层面的低级错误，真正需要写CORS头、JSONP这种手段的场景反而少见。优先从Nginx反向代理入手，简单直接，不侵入业务代码，是这套方案最大的价值。

如果你在实操过程中还有拿不准的细节，欢迎在评论区直接留言，我看到就会回复。也建议你把这篇文章收藏起来，等真正遇到图片跨域问题时，拿出来照着走一遍，能少走不少弯路。