web服务器的.do文件是什么，do文件怎么打开

Web服务器中的.do文件本质上是一个Java Web的请求映射标识，它并不是真实存在于服务器硬盘上的文件，而是通过URL后缀触发的Servlet处理逻辑。

对于很多刚接触Java项目的站长或者运维人员来说，看到地址栏里的.do后缀，第一反应往往是“这文件存在哪？”或者“它是怎么被执行的？”这很正常因为.do文件既不是HTML那样可以直接打开，也不是图片那样可通过路径访问，本文会把.do文件的原理、与Struts框架的关系、常见错误排查整理透彻,让你看完就能上手处理相关问题。

理解.do文件之前，先明确它是“假文件”

在Windows或Linux服务器的Web目录里，你搜索login.do或user.do，绝对找不到对应的实体文件，行业共识认为，.do后缀是Java Web框架（尤其是Struts 1.x和Struts 2）用来做请求分发的“虚拟路径标识”。

它的工作机制类比成“门牌号”更直观：

• 浏览器访问http://你的域名/user/login.do
• Web服务器（如Tomcat）看到.do后缀后，不尝试找实体文件，而是把这个请求交给“ActionServlet”或“FilterDispatcher”这样的核心控制器
• 控制器解析login这个路径，查配置文件（如struts.xml或struts-config.xml），找到对应的Java类（Action）并执行
• 执行完毕后，Java类返回一个“结果字符串”（比如success），框架再根据结果跳转到对应的JSP页面渲染HTML

你在地址栏看到的.do是“路由器”,真正干活的是后台的Java类。

什么样的Web服务器和框架才会产生.do文件

并不是所有web服务器都有.do后缀，这取决于后端技术栈。

使用.do后缀的典型环境

• Tomcat/ Jetty等Servlet容器：这是基础，所有Java Web程序都跑在这类容器上
• Struts框架：最典型，早期大部分Java企业项目用Struts，因此遗留系统里遍布.do
• Spring MVC（早期配置）：在Spring MVC的配置中，完全可以自定义后缀为.do，很多老项目就这么干的
• 自定义Servlet映射：如有程序员在web.xml中写了<url-pattern>.do</url-pattern>，那么任何以.do结尾的请求都会被指定的Servlet接住

.do与.jsp、.html的本质差异

表格：不同后缀的请求处理方式对比

从表格能看出，.do文件往往是“后续动作”的承载者，比如你点了“保存”按钮，表单数据会POST到一个.do地址上,完成写入数据库的操作。

浏览器访问.do文件时的完整处理流程

理解这条链路是排查问题的基础，把一个用户注册.do请求完整走一遍：

1. 用户在浏览器填写信息，点击提交，表单action指向register.do
2. 浏览器发送HTTP请求到80/443端口，请求行包含POST /register.do
3. Tomcat接收后，根据部署描述符发现.do匹配到某个Filter或Servlet
4. 核心控制器读取struts.xml中的<package>和<action>配置，匹配到处理注册的Action类
5. Action类中execute()方法被调用，内部通过DAO层操作数据库
6. 执行完成后，返回逻辑视图名（例如"success"）
7. 框架根据结果码映射到最终的JSP页面（比如/WEB-INF/pages/success.jsp）
8. Tomcat渲染JSP，生成HTML返回给浏览器

对于开发人员来说，这一过程里最需要关注的是第4步和第5步。多数.do无法访问的错误，都出在配置路径写错或者Action类抛异常这两个环节上。

.do文件打不开或404的常见原因与实操排查

访问.do地址提示404，或点击按钮没反应,最常见的诱因可以归纳为以下三类。

项目没有正确部署到Tomcat的webapps目录

如果你的war包没解压成功，或者项目名与URL不匹配，任何后缀都会报404，验证方式是在Tomcat管理页面看有没有部署成功的列表，或检查logs/catalina.out日志。

实操命令（Linux环境）：

ls -l /usr/local/tomcat/webapps/

若只看到ROOT目录，说明项目没发布成功,需要重新放置war包并重启Tomcat。

Struts配置文件里的Action路径写错

这是一个高频率问题,假设你配置了：

<action name="login" class="com.demo.LoginAction">

那访问路径应该是/login.do，而不是/user/login.do，若URL与name值不能完全对应,必然404。

正确做法是先打开struts.xml，搜索<action name=，复制name的值再拼接.do访问。

过滤器拦截导致.do请求“绕不过去”

例如Shiro或Spring Security拦截器把.do地址拦截了，就会返回302或403，排查方式是打开浏览器的开发者工具（F12），看Network面板里.do请求的响应状态码：

• 404：找到不配置的映射
• 500：Action内部Java代码报错，看Tomcat的localhost.log里具体的Exception
• 403：权限拦截，检查角色配置

Action类中return的字符串没有匹配到结果页

这是一种“请求成功但页面空白”的情况，配置中少写了<result name="success">节点，框架不知道该跳哪,浏览器就只能得到空响应。

修复方式：在struts.xml中为每个Action补齐<result>配置,并确认JSP文件存在于指定路径。

日常运维中如何正确处理.do文件相关请求

针对GEO优化场景的URL处理

如果你的业务需要把动态.do地址做GEO，有几点值得留意，搜索引擎的爬虫对动态参数有偏好差异，但.do本身并不影响抓取真正影响收录的是URL中包含大量参数，以及SessionID导致的内容重复。

建议做法：用sitemap.xml将清晰的.do链接主动提交给百度站长平台，如果条件允许，开通“伪静态”功能。

伪静态配置思路：在Tomcat中隐藏.do后缀

• 使用RewriteValve（即org.apache.catalina.valves.rewrite.RewriteValve）
• 在conf/Catalina/localhost/项目.xml中加入Rewrite规则，把/product/123这种路径内部转发到/product.do?id=123

这样既保留了假静态URL的美观,又不需要改动Java代码。

查询和修改.do文件的映射规则

有些程序员接手旧项目时，找不到某个.do对应的是哪段业务逻辑,高效步骤：

1. 列出项目中所有包含.do的地方，用IDE全局搜索（如IntelliJ IDEA）
2. 区分哪些是前端页面的form/链接，哪些是JSP重定向
3. 把唯一的.do地址输入到IDE搜索框，排除HTML字符后，往往能看到标注了

   

   @Action("user/list")之类的注解

4. 打开对应Java类，断点调试即可定位

如果是老版Struts 1，需要看struts-config.xml里的<action path="/user/list" type="...">。

换个真实场景理解.do文件的价值

假设你手上是一个2018年前开发的电商后台系统，技术栈是Spring MVC + MyBatis,在地址栏中管理商品时会看到：

http://admin.example.com/goods/edit.do?goodsId=1024

你在服务器上遍历goods目录，找不到任何edit.do文件，此时心里应该明白，该地址对应的代码逻辑大概率被@RequestMapping("/goods/edit.do")注解锁定在一个GoodsController类中，找到源码，拉起来改改返回逻辑，刷新页面就能验证，这个“通了”的过程，就是对.do文件最好的理解。

Q&A：do文件的高频问题

.do文件是病毒或恶意脚本吗？

不是。.do只是Java Web框架中的URL模式，属于服务器端Java逻辑，不直接代表安全风险，如果某个.do地址存在SQL注入或未授权访问漏洞，那它就可能被攻击者利用，看到.do不要慌,你先确认服务器上运行的进程是什么即可。

.do和.action、.htm的区别是什么？

它们只是不同的框架扩展名约定，比如Struts 2早期默认支持.do和.action，Spring MVC则经常用.do或没有任何后缀的RESTful风格。.htm常用于前端静态页面，走的路由完全不一样，具体区别取决于框架配置文件里的suffix设置。

老项目里的.do文件怎么迁移到Spring Boot？

Spring Boot中默认没有Servlet映射，需要在启动类上加入@ServletComponentScan并定义一个WebMvcConfigurer，配置路径匹配规则，直接做法：在application.yml中配置spring.mvc.pathmatch.matching-strategy=ant_path_matcher，然后把原项目里的.do请求改为.do路径拦截，保留原URL不加改动，对使用者来说，地址栏不变,只是底层实现更现代了。

.do文件是Java Web技术栈特定历史阶段的产物，理解它要弄清楚两个核心关系：URL地址与配置文件映射的关系，以及配置文件与Java业务类的关系，掌握这两步，碰到任何.do问题都能快速定位到具体代码逻辑，总体而言，它并不神秘,只是一个带框架标识的调度入口。