JSP 获取服务器下的图片路径，本质是拿到两套地址：服务器磁盘上的物理路径用 application.getRealPath("/images/a.jpg") 取，浏览器能访问的 URL 用 request.getContextPath() + "/images/a.jpg" 拼，前者给后端读写文件用，后者给 <img src> 用，一旦混用，页面必然白图或报 404。
为什么同一个图片会有两个路径
很多人第一次写这段代码，直接把 getRealPath 的结果塞进 <img src>，本地 Windows 上居然能显示，一部署到 Linux 服务器就全变成裂图，原因不复杂：浏览器拿到的 HTML 里写着一个 D:\tomcat\webapps\shop\images\logo.png 或者 /opt/tomcat/webapps/...，这个地址是服务器的内网磁盘位置,浏览器根本没权限也没法解析。
所以写 JSP 的图片路径,先分清两类路径的职责。
JSP获取服务器绝对路径和相对路径的区别
业内专家指出，Servlet 规范里说的“绝对路径”和前端说的“绝对路径”不是一回事,这也是初学者最容易绕晕的地方。
- 物理路径：真实存在于文件系统的位置，形如
/usr/local/tomcat/webapps/shop/images/logo.png，只能在后端用，new File(realPath)判断文件是否存在。 - Web 路径（URL 路径）：以项目上下文为起点的地址，形如
/shop/images/logo.png,是浏览器发请求时用的。 - 相对路径：相对当前页面 URL，
../images/logo.png，页面层级一变就失效,生产环境能不用就不用。
三种路径对应的取法也不一样：
| 路径类型 | 典型取值 | 主要用途 | 常见坑 |
|---|---|---|---|
| 物理路径 | application.getRealPath("/images/logo.png") |
后端读写、上传落盘 | WAR 未解压时可能返回 null |
| Web 路径 | request.getContextPath() + "/images/logo.png" |
<img src>、AJAX 请求 |
手动拼接时容易多写一个斜杠 |
| 相对路径 | images/logo.png |
原型页面、临时调试 | 页面目录变化即失效 |
记住一句话：给 Java 用的走 getRealPath，给浏览器用的走 getContextPath。
JSP获取服务器下的图片路径怎么写：按图片存放位置分场景
图片放哪儿，代码就怎么写，脱离存放位置谈路径,等于纸上谈兵。
图片在项目部署目录内
这是最常见的情况，图片放在 webapp/images/ 或者 Maven 项目的 src/main/webapp/static/img/ 下。
<%
// 物理路径，注意末尾不要带多余斜杠
String realPath = application.getRealPath("/images/logo.png");
// 例如得到：/usr/local/tomcat/webapps/shop/images/logo.png
// 浏览器访问地址
String ctx = request.getContextPath(); // 通常返回 /shop，ROOT 项目返回空串
String imgUrl = ctx + "/images/logo.png";
%>
<img src="<%=imgUrl%>" alt="logo">
这里有个细节值得注意： getContextPath() 部署在 ROOT 下会返回空字符串，如果你写死了 /shop，换环境就废，所以永远用 getContextPath() 动态取。
另外从 Servlet 3.0 开始，getRealPath() 对打包成 WAR 且未解压的应用可能返回 null，判断一下再使用,是稳妥做法：
if (realPath != null && new java.io.File(realPath).exists()) {
// 文件存在，可以继续处理
}
图片在服务器磁盘的其他目录
上传的图片一般不会放进项目目录，因为重新部署一覆盖就全丢了，常见做法是放到 D:/upload/images 或 /data/upload/images,然后单独配一个映射。
<%
String baseDir = "D:/upload/images/";
String fileName = "2026/cover.jpg";
java.io.File f = new java.io.File(baseDir + fileName);
if (f.exists()) {
// 后端可以读，但前端不能直接访问这个磁盘路径
}
%>
前端要访问，就得让 Tomcat 知道这个目录对外是一个 Web 路径，在 conf/server.xml 的 <Host> 内加一行：
<Context docBase="D:/upload/images" path="/pic" reloadable="false" />
页面里就可以写成：
<img src="${pageContext.request.contextPath}/pic/2026/cover.jpg">
Tomcat 9 之后更推荐把配置文件放到 conf/Catalina/localhost/pic.xml，避免直接改 server.xml 导致热部署失效，这也是 Tomcat 官方文档给出的建议。
JSP页面读取项目外网图片路径的几种方法
如果图片不在本机，而在图床、OSS 或者 CDN 上，那就跟服务器路径没关系了,直接在配置文件里存域名前缀即可。
- 纯字符串拼接：
String img = "https://cdn.example.com/" + fileName;，最简单,但域名换了要改代码。 - 配置项读取：把
img.base.url写进 properties，JSP 里用 EL 表达式取,换环境只改配置。 - 数据库存完整 URL：适合图片分散在多处的情况,缺点是历史数据迁移麻烦。
行业共识认为，图片资源一旦超过一定规模，就该从 JSP 所在的服务器里剥离出去，交给对象存储加 CDN，JSP 只负责渲染地址,这样部署和扩容都清爽得多。
Tomcat部署后JSP图片路径404怎么解决
路径代码看着没问题，页面上还是 404，多半不是 JSP 的锅，而是资源根本没到该在的位置，按下面顺序排一遍,能解决大部分问题。
- 确认图片在部署目录而不是源码目录：Tomcat 跑的是
webapps/shop/，不是你的 Eclipse 工程目录，IDE 里的文件要经过发布才会同步过去。 - 检查大小写：Linux 文件系统区分大小写，
Logo.png和logo.png是两个文件，Windows 上测不出来。 - 检查是否重复拼接 contextPath：
/shop/shop/images/logo.png这种双前缀,多半是页面里又手工加了一次项目名。 - 看过滤器有没有拦截静态资源：登录校验、字符编码过滤器如果匹配了 ，把
.jpg、.png也拦了，页面就会拿着一堆登录页 HTML 当图片。 - 中文文件名做 URL 编码：用
java.net.URLEncoder.encode(name, "UTF-8")转一下，空格、、 都会截断请求。 - 确认 WAR 是否解压：
getRealPath()返回 null 时，先看webapps下是不是只有.war没有目录。
排查时最快的一招，是在浏览器里直接把拼出来的 URL 敲进去访问，返回 404 就是资源不存在，返回 500 才是代码有问题。
JSP获取图片路径的两种写法哪个好
这是后台开发者问得最多的一类问题，其实没有绝对好坏,只有场景匹配。
| 对比项 | getRealPath 取物理路径 | getContextPath 拼 URL |
|---|---|---|
| 返回值 | 磁盘绝对路径 | 以 开头的 Web 路径 |
| 能否给 img 用 | 不能 | 能 |
| 能否 new File | 能 | 不能 |
| 容器差异 | WAR 未解压可能为 null | 稳定返回 |
| 推荐用途 | 上传保存、删图、读流 | 页面渲染、前端请求 |
结论很清楚：只要是要显示出来，一律用 getContextPath() 拼 URL；只要是要操作文件本身，一律用 getRealPath() 或配置的磁盘目录。 想把两者合成一个值,那是在给自己埋雷。
另外提醒一句，物理路径不要输出到前端页面，哪怕是调试注释里，把服务器目录结构暴露出去，属于典型的信息泄露,近年来不少安全扫描都会专门查这一条。
Q&A：JSP获取服务器图片路径常见问题
JSP 获取服务器下的图片路径返回 null 是什么原因？
最常见的是应用以 WAR 包形式运行且没有解压，容器无法提供真实文件路径，其次是路径参数写成了相对路径，或者开头漏了 ，解决方向是检查部署形态，或者改用 getResourceAsStream() 读取,也可以把图片移到固定的外部目录再配置映射。
JSP 里图片路径用绝对路径还是相对路径更稳妥？
生产环境推荐“contextPath + Web 路径”的写法，它既不受页面层级影响，也不依赖服务器磁盘结构，相对路径只在页面结构固定、项目永远不换部署路径时才勉强可用，一旦迁到别的上下文,全线失效。
图片文件名带中文，JSP 访问 404 怎么处理？
先确认服务器文件系统编码与请求编码一致，再对文件名做 URL 编码，输出到 src 时用编码后的值，同时检查 Tomcat 的 URIEncoding 配置，早期版本默认不是 UTF-8，中文名会在请求阶段就被转成乱码,导致服务器端找不到对应文件。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/787834.html
