企业官网建设流程全解析

从“这个名字最响”说起：拿到一个JavaWeb项目，别急着写代码，第一件该干的事是把项目在你自己的机器上跑起来。Myeclipse这个老牌IDE的部署环节，很多人第一次接触时都卡在“明明代码没问题，怎么就是404”这个坎上，其实问题往往不在代码，而在部署的姿势。

这篇文章我会从环境版本搭配、项目导入、Tomcat配置、数据库联调、打包发布到常见问题排查，完整走一遍用Myeclipse部署JavaWeb网站的流程。适合刚学Servlet/JSP的学生、接手老项目需要本地跑通的新人，以及被各种神级配置折磨到怀疑人生的同行。准备好笔记，我们从最枯燥但也最重要的环境开始。

1. 部署前先理清版本搭配：JDK、Myeclipse、Tomcat

1.1 版本关系不是玄学，是兼容性

在动手之前，你得先明白一个概念：JavaWeb项目在Myeclipse里部署，本质上就是把编译好的class和静态资源塞进Tomcat的过程。而这个过程中，JDK、IDE、Tomcat三个版本必须互相兼容，否则就会出现类加载失败、JSP编译报错、甚至启动直接崩掉的情况。

以我现在的常用组合为例：JDK 1.8 + MyEclipse 2017 CI + Tomcat 8.5。这套组合在我见过的大部分老项目中都能稳定运行。Tomcat 9可以看作Tomcat 8.5的升级版，绝大多数项目也能跑，但跨到Tomcat 10就要小心了——Tomcat 10把Servlet API的包名从javax.servlet改成了jakarta.servlet，如果项目里用的是老写法，部署后必现ClassNotFoundException。

提示：遇到“项目在我机器上明明能跑，到你那就报错”的情况，九成是版本没对齐。先问对方JDK和Tomcat版本，再动手部署。

1.2 环境变量和IDE内存设置

环境变量这块，JAVA_HOME指向JDK安装目录，CATALINA_HOME指向Tomcat目录。这里有个容易犯的迷糊操作：把JAVA_HOME配置成JRE目录。如果你在命令行运行java -version能找到，但Tomcat启动报“找不到JAVA_HOME”，多半就是这个原因。JDK里包含了JRE，所以JAVA_HOME应该指向JDK的根目录，而不是jre子目录。

Myeclipse自身的内存设置也要处理。默认的eclipse.ini对老机器来说太保守，部署大型项目时容易卡死或直接闪退。我的经验是把内存参数调大一些：

-Xms256m -Xmx1024m -XX:MaxPermSize=256m

如果是JDK 8及以上版本，MaxPermSize这个参数会被忽略，因为它针对的是老版本JDK的永久代；不必纠结，写上也无妨，不会报错。重点是-Xmx，它决定IDE能申请到的最大堆内存。部署那种动辄几十个JSP页面、几十个jar的老项目，512M以下的内存设置基本就是给自己找罪受。

1.3 热词“myeclipse exe4j 外部依赖 打包 可执行 exe 文件”的澄清

搜索结果里经常出现“Myeclipse打包exe”的诉求，我先把结论放在这：如果你做的是JavaWeb项目，Myeclipse本身不能直接把它打成exe，你需要一个内嵌Tomcat的思路；如果你做的是Swing/JavaFX桌面程序，用exe4j这类工具就对了。这俩场景完全不冲突，后文第5章我会专门展开讲怎么做，现在先别急着跳过去。

2. 把项目导入Myeclipse并看懂工程结构

2.1 导入老项目的完整流程

拿到一个同事或老师给的JavaWeb项目，多数情况下它是一个完整的Myeclipse/Eclipse工程目录，里面带着.classpath、.project这样的隐藏文件。这时用File -> Import -> General -> Existing Projects into Workspace来导入。

有个细节建议你养成习惯：在Import窗口里勾选Copy projects into workspace。解释一下原因：如果你不勾选，项目引用的是原来的磁盘路径，一旦原目录被移动、改名或清理，工程就直接“失联”了；复制一份到workspace里，后续操作可以随便折腾，失败了删掉重来也不会影响原始文件。这个习惯让我少踩了很多坑，强烈建议你照做。

导入成功后，如果项目图标上没有地球样式的Web标识，说明它没有被识别为Web项目。这时候右键项目 ->Properties -> Project Facets，勾选Dynamic Web Module并选择版本（老项目一般3.0/3.1）。如果不勾选，你会发现后面配置Tomcat时，这个项目根本没有“Add”到Server的选项。

2.2 WebRoot目录结构务必要看懂

Myeclipse的项目结构和IDEA的JavaWeb项目结构有个显著差异：Myeclipse使用WebRoot作为Web根目录，而新版IDEA默认叫webapp。很多从IDEA切过来的人会在这一步懵掉。

WebRoot下面通常长这样：

WebRoot/ ├── WEB-INF/ │ ├── web.xml │ ├── classes/ │ └── lib/ ├── index.jsp ├── css/ ├── js/ └── images/

WEB-INF目录是规则保护区域。Tomcat允许浏览器直接访问WebRoot下的index.jsp、css、js这些路径，但任何在WEB-INF里面的文件都不允许通过URL直接访问，必须经过服务端转发。所以web.xml里配置的Servlet路径，转发目标如果是/WEB-INF/views/xxx.jsp，那是合规玩法；如果你想直接http://localhost:8080/项目名/WEB-INF/web.xml去看配置，那必定是404。

WEB-INF/lib是Project依赖的jar存放地。注意：放进这个目录的jar会自动进入Tomcat的类加载路径，不需要再右键Add to Build Path。反过来，只做Build Path引入而在lib目录里没有实际文件，部署到Tomcat之后大概率ClassNotFound。这条规则几乎能解释一半的“本地正常、部署就崩”问题。

2.3 热词“myeclipse webroot 项目名”是什么意思

你搜“myeclipse webroot 项目名”，很多人问的是上下文路径的问题。在Myeclipse里，右键项目 ->Properties -> Web，能看到Web Context-root，默认值就是项目名。这个值决定了访问URL的第一段路径：

http://localhost:8080/项目名/页面路径

如果你把Web Context-root改成ROOT或空字符串，访问URL就变成了http://localhost:8080/页面路径，相当于部署在Tomcat根路径。这里有个新手常见的认知误区：菜单里的项目名不能代表部署后的访问路径，你得看Web Context-root或war包文件名。要保持路径和项目名一致，省得后面自己访问时都搞不清该敲哪个URL。

2.4 编译输出目录的设置

老版本Myeclipse的项目默认编译输出到WebRoot/WEB-INF/classes，这样部署时class文件跟着WebRoot一起走，逻辑很顺。如果你发现导入项目后，WEB-INF/classes是空的，编译的class不知道跑哪去了，就在项目属性里找到Java Build Path -> Source标签页，检查Default output folder是不是指向了WebRoot/WEB-INF/classes。这个配置不对，项目编译能成功，但Tomcat启动后找不到Servlet类。

3. 配置Tomcat并完成本地部署

3.1 绑定运行环境与Server视图

Myeclipse自带了一个内置Tomcat，但我一直不推荐用它做日常开发。理由很实际：内置Tomcat版本老旧、控制台日志输出不全、出了问题想单独重启还要等IDE响应。我更习惯配置一个外部的Tomcat实例。

操作路径：Window -> Preferences -> Servers -> Runtime Environment -> Add，选择你本机安装的Tomcat版本，指定Tomcat安装目录和对应的JDK。

这里有个细节：Tomcat启动时的JVM参数。如果你的项目用了比较大的内存，或者要设置编码，可以在Server的Open launch configuration或双击Server视图里的Tomcat实例，在Arguments里的VM arguments里加参数：

-Xms256m -Xmx1024m -Dfile.encoding=UTF-8

我自己的习惯是：一律在Server配置里指定文件编码，因为老项目的JSP页面很可能是GBK，而Myeclipse的默认工作区编码可能不是GBK，不统一指定就会乱码奇遇记。

3.2 添加项目并启动

在Servers视图下，右键Tomcat实例 ->Add and Remove，把左侧的项目加到右侧，然后点启动按钮。等Console输出日志不再刷新，出现Server startup in xxx ms这样的字样，就说明启动成功了。

启动日志是个宝贝，别忽略。老手看部署状态基本都靠它：如果项目没有成功Deploy，启动日志里一定会出现Deployment is out of date或者Error during deployment。

启动成功后在浏览器访问：

http://localhost:8080/你的项目名/index.jsp

如果你的访问路径跟我这个有出入，请回到2.3节检查Web Context-root。

3.3 IDEA跑JavaWeb项目的配置逻辑

现在很多小伙伴是先用IDEA写代码，再被要求用Myeclipse部署老项目。IDEA里的Tomcat配置逻辑跟Myeclipse有对应关系，你可以把它当参考系：IDEA的Run Configuration -> Deployment -> Application context，对应Myeclipse的Web Context-root；IDEA里的Server -> URL会自动带上上下文路径，Myeclipse里的访问URL需要你自己拼接。理解了这一层，你在两个IDE之间切换就不会觉得部署是两套完全不同的知识。

3.4 外置Tomcat的另一种部署方式

除了在Myeclipse里管理Tomcat，你还可以直接把项目部署到外部Tomcat，方法是把WebRoot下的内容整个复制到Tomcat的webapps/项目名/目录下。这其实就是在模拟war包解压后的效果。手动操作时别把WEB-INF漏掉，不少新手把JSP和class放对了，却忘了lib里那一堆jar，结果启动报错。

4. 带数据库的完整案例部署：MySQL联调

4.1 数据库连接配置到底改哪

很多JavaWeb完整案例的教学项目都是Servlet + JSP + MySQL的组合，跑到部署阶段，最常见的报错已经从404变成了数据库连不上。这时候你要知道连接配置的文件位置。

常见配置文件名我有必要列一下，因为每个项目模板的命名习惯不一样：

• src/jdbc.properties
• src/db.properties
• src/c3p0-config.xml
• WEB-INF/classes/jdbc.properties

以最常见的jdbc.properties为例：

jdbc.driver=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/yourdb?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=123456

如果你用的MySQL是8.x，驱动类名要换成com.mysql.cj.jdbc.Driver，同时URL里的serverTimezone和useSSL参数必须带上，否则驱动初始化会直接报时区错误。

4.2 驱动版本与字符集的坑

驱动jar版本不匹配是数据库联调里的大坑之一。MySQL 5.x配mysql-connector-java 5.1.x，MySQL 8.x配mysql-connector-java 8.0.x。混用的典型症状：连接报Unsupported protocol，或者Communications link failure。

另外，数据库本身的编码也要统一。建库时建议使用：

CREATE DATABASE yourdb DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

utf8mb4和utf8的区别在于emoji和生僻字的支持。很多老项目只用了utf8，如果你的数据里有特殊字符，插入会失败。在连接参数里加上characterEncoding=utf8，同时保证数据库、连接串、JSP页面三端编码一致，乱码问题基本能根治。老项目如果页面还在用contentType="text/html; charset=GBK"，那你得优先保持页面编码和数据库存储编码一致，别盲目统一到UTF-8。

4.3 初始化数据脚本的执行顺序

部署带MySQL的完整案例时，通常会附带一个.sql脚本。执行顺序有讲究：先建库，再建表，最后插数据。直接双击脚本文件在Navicat里执行也是可以的，但你得先确认脚本里有没有CREATE DATABASE语句。如果没有，你需要手动建同名库，然后USE它再执行建表语句。

如果项目用了Hibernate或MyBatis，建表可能由ORM自动完成。Hibernate配置hibernate.hbm2ddl.auto=update时会自动建表，但如果你同时手动导入了表结构，两者可能会冲突。我的习惯是：部署老项目优先按脚本手动建库建表，然后关闭ORM的自动建表功能，因为自动建的表结构往往和代码里的SQL对不上。

执行完脚本后，先在数据库客户端里跑一条SELECT确认数据真的进去了，再去启动Tomcat。这一步能帮你把问题边界划清楚：如果数据都有了，Tomcat启动后页面还是报SQLException，那就是SQL语句本身或驱动的问题，跟数据库初始化无关。

5. 打包发布：war包与exe文件的扩展玩法

5.1 最可靠的发布方式：导出war包

如果在本地跑通了，要发布到远程服务器，我推荐用war包而不是直接复制整个目录。在Myeclipse里，右键项目 ->Export -> WAR file，选择输出路径，一路下一步完成导出。

war包本质上就是一个带WEB-INF/web.xml的zip文件。把它放到Tomcat的webapps目录下，启动Tomcat时会自动解压成目录。如果你的项目名带空格或中文，war包文件名也要避开这些字符，否则Linux环境下可能出现奇奇怪怪的解压问题。

验证部署是否成功，别急着打开浏览器，可以先在命令行里确认：

curl -I http://服务器IP:8080/项目名/index.jsp

返回200 OK就说明服务端口和项目上下文路径都正常。如果返回404，排查顺序是：Tomcat是否启动 -> war包是否解压 -> URL的上下文路径是否与war包文件名一致。

5.2 为什么有人想把JavaWeb项目打包成exe文件

热词里频繁出现“myeclipse exe4j 外部依赖 打包 可执行 exe 文件”，这背后其实是两类需求：

第一类，写的是桌面程序（Swing/JavaFX/AWT），用Myeclipse写完，想让用户双击就能运行，不想让客户装JDK配环境。这类需求用exe4j或Jsmooth很合适。

第二类，写的是JavaWeb项目，想做成exe，本质上是想把Tomcat一起打包进去，让服务成为“绿色版”。这类需求的实现思路是：用Spring Boot或嵌入式容器，把项目打包成可执行jar，再用exe4j把jar包包裹成exe。但请注意：传统的Servlet/JSP项目没有内嵌容器，直接打exe并不现实，你需要先把项目改造或选用带内嵌容器的方案，否则就是绕远路。

5.3 exe4j打包含外部依赖时的关键步骤

先说清楚exe4j的定位：它本身不是编译器，而是为已经打包好的Java jar程序做一层原生壳，负责找JRE、带参数启动Java进程。所以它的前提是：你手里得有一个能通过java -jar跑起来的jar包。

在Myeclipse里把程序打成可执行jar包，我推荐用Export -> Runnable JAR file，在启动配置里选择主类，Library handling选择Extract required libraries into generated JAR或Package required libraries。如果你用的还是老式的Export -> JAR file，生成的jar包里不会包含第三方依赖，运行时会一直报ClassNotFound，这就是“外部依赖”四个字的由来。

exe4j的配置界面关键要素我整理如下：

VM参数里加-Dfile.encoding=UTF-8是我的血泪经验。Windows默认编码是GBK，Windows的纯Java程序如果不显式指定UTF-8，读写文件时很容易乱码。在exe4j里，这个参数配置在VM Parameters字段，别漏。

5.4 exe4j过程中必须避开的三个雷

用exe4j打包被问得最多的问题集中在三处：

雷区一：32位/64位不匹配。exe4j生成的exe是有位数概念的，必须和JDK/JRE的位数一致。你机器装的是64位JDK，那就不能在32位模式下生成exe，否则双击会提示“不是有效的Win32应用程序”。

雷区二：JRE搜索路径失效。客户机器如果没装JDK，你需要在exe4j的JRE搜索页面指定一个内置JRE，把JRE和exe放在同一级目录。否则exe在不同机器间拷贝后找不到JRE，直接闪退，客户只会说“你的程序打不开”。

雷区三：主类写错或清单文件缺失。如果jar包里没有Main-Class，exe4j也找不到入口。可以在生成jar包时检查META-INF/MANIFEST.MF，确认Main-Class:这一行存在且类名正确。

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

6.1 高频问题速查表

直接上干货，这些都是我在实际部署中反复遇到的场景，你大概率也会碰到。

6.2 端口占用问题的完整处理

端口占用是Tomcat启动报错里最经典的一类。Windows下命令行执行：

netstat -ano | findstr 8080

然后你会看到一行记录，最后一列就是进程PID。再执行：

taskkill /F /PID 该进程的PID

把占用进程杀掉后重启Tomcat。

注意：tomcat插件的“8080”是默认端口，一些项目会改成80或8088。如果你改了端口，上面命令里的8080要跟着换成对应端口。在conf/server.xml里搜Connector port就能看到当前位置的端口。

6.3 我私藏的4个排查习惯

第一个习惯是先看日志再看代码。遇到部署问题我基本不看代码，先打开Tomcat的日志。Myeclipse底部Console虽然方便，但历史日志会被清掉。Linux服务器上部署的老项目，也可以直接看catalina.out和localhost.yyyy-MM-dd.log，项目自身的异常页面控制台的详细堆栈都记录在这里。定位速度比在代码里乱翻快十倍。

第二个习惯是Clean Project之后重新部署。Myeclipse的增量编译在某些老旧场景下会陈旧：你改了Java文件，编译产物没有同步更新，部署到Tomcat里跑的还是旧class。遇到诡异问题，右键项目 ->Clean...，把Server里的项目移除，再重新Add，启动一次。这一套组合拳能解决不少“明明改对了但没生效”的问题。

第三个习惯是保留一个纯净的Tomcat副本。我电脑上专门有一个“原始Tomcat”文件夹，这个目录没做过任何配置，只用来验证：war包能不能启动、依赖缺不缺、JAR包到底有没有拉进去。这个副本检查过的问题，往往比我在IDE里折腾半天更接近真相。

第四个习惯是路径一律用英文。早期的JavaWeb项目生命周期长，老Tomcat对中文路径、中文项目名的支持并不完善，在Windows环境下很容易出现JSP编译失败或资源读取不到。现在用新版本也可能没问题，但既然能避免，就图个安稳。

6.4 部署态与开发态的差异要心里有数

最后说个容易被忽略的点：开发时你在Myeclipse里跑得通的项目，部署到服务器上不见得能跑。差异主要在路径上。你在JSP或Servlet里写的new File("xxx.txt")，在开发环境中可能指向了工作空间目录，在Tomcat环境里却指向了Tomcat的bin目录。解决方式就是不要在代码里裸写相对路径，要么用ServletContext.getRealPath()，要么用classpath下的资源。

类似的问题还有：本地MySQL能连，服务器怎么都连不上，检查一下服务器的防火墙和MySQL的远程访问权限。MySQL默认只允许本地连接，服务器上要开放bind-address和用户host权限，否则你从别的机器连过去永远是access denied。

做JavaWeb部署这件事，说实话没有太多高深的学问，绝大多数问题都出在环境、路径和类加载这三件事上。你只要把一个项目从头到尾跑通过一次，后面换IDE、换Spring Boot、换服务器，本质上遵循的是同一套治理思路。我的个人体会是：遇到问题不要急于改配置，先把日志完整读一遍，再动手。读日志这个习惯帮我节省的时间，远超过任何快捷键和插件。最后再分享一个冷门的小技巧：如果你发现自己反复在Tomcat和项目目录之间复制文件，建一个批处理或脚本去完成复制、重启、等日志输出这一套动作，你会回来谢我的。