企业官网建设流程全解析

本地部署这个词，最近被AI圈带得格外热闹，什么ollama本地部署、大模型本地部署、连deepseek都能在个人电脑上跑起来了。但对Java后端开发者来说，提到"本地部署"，第一反应永远是那个最朴素也最绕不开的场景——把自己电脑上的SSM项目跑起来。SSM就是Spring、SpringMVC、MyBatis这三件套，多少人第一个正式的Web项目就是它，课程设计、毕业设计、公司里跑了好几年的老系统，到处都是它的影子。这篇文章不扯虚的，就从一个接手别人代码的视角出发，把SSM项目从环境准备、数据库初始化、配置文件修改到Tomcat发布的全流程走一遍，重点说那些教程文档里不会写的坑。适合正在做毕设、刚入职接老项目、或者准备换电脑重装环境的同学，哪怕你是第一次部署，按这个流程走，至少能少折腾一整天。

1. 部署SSM项目前，先把环境版本对齐

1.1 JDK、Maven、Tomcat、MySQL怎么选版本

很多人拿到SSM项目第一件事就是双击打开IDEA，等着它自己跑起来，结果一编译就是一片红。我这几年帮人排过的部署问题里，十有七八都是版本不对齐导致的，所以第一步千万别急着跑代码，先把本机环境跟项目要求对齐。

SSM项目最稳的搭配是JDK 1.8、Maven 3.6左右、Tomcat 8.5或9.0、MySQL 5.7或8.0。JDK为什么推荐1.8？因为大多数SSM项目的Spring版本在4.x到5.x之间，MyBatis版本在3.4到3.5之间，这些框架在JDK 8上经过大量生产验证。如果你装了JDK 17甚至更高版本，老框架很可能会报"非法反射访问"之类的警告，严重时直接启动失败。Tomcat也一样，你要是图新装了Tomcat 10，会发现项目里那些javax.servlet开头的代码全找不到类，因为Tomcat 10已经把包名换成了jakarta.servlet，老war包根本不兼容。

Maven没那么多讲究，3.6.x就能覆盖绝大多数项目。MySQL这里有个经典坑：MySQL 8.0默认的认证插件是caching_sha2_password，而旧版的mysql-connector-java驱动可能不认，连接时直接报Authentication plugin错误。所以用MySQL 8就要配8.x版本的驱动，并且在连接串里加上allowPublicKeyRetrieval=true。我一般建议先看项目里的pom.xml依赖版本，再决定本机装什么，别反着来。

装完环境后，打开命令行检查一下：

java -version mvn -v mysql --version

三个命令都能正常输出版本号，并且JDK是1.8、Maven不报错，环境这关才算过。如果java -version显示的是17或者更高，而项目是老的SSM，要么换JDK，要么在IDEA里给这个项目单独指定Project SDK为1.8，别偷懒。

1.2 拿到代码先别急着跑，pom.xml里藏着答案

很多新手拿到项目压缩包，直接解压就开跑，这是第二个大坑。SSM项目能不能顺利部署，pom.xml基本已经决定了一半，花五分钟读一读，能省下后面两小时的排查时间。

先看这几个地方：<packaging>是war还是jar，SSM项目一般是war，因为要部署到Tomcat；<properties>里的maven.compiler.source和target是不是1.8；<dependencies>里Spring版本、MyBatis版本、MySQL驱动版本分别是多少。然后重点看有没有这几个常见依赖：lombok、druid、fastjson、pagehelper。有lombok的话，IDEA必须安装Lombok插件并且开启注解处理，否则编译时getter、setter全部消失，代码莫名其妙报错。有druid的话，数据库连接池配置就要按druid的格式写，别套用c3p0的配置。

还要注意项目是不是多模块结构，也就是顶级pom下面挂着好几个子模块，比如dao模块、service模块、web模块。这种项目在IDEA里直接跑之前，必须先对依赖的基础模块执行mvn install，把它们装进本地Maven仓库，否则web模块编译时找不到内部依赖。另外看一下pom里有没有引入JSTL标签库依赖，很多SSM项目的JSP页面用了<c:forEach>这类标签，但pom里漏了jstl，启动后会报"无法找到tag library descriptor"。

看完pom.xml，再扫一眼src/main/resources目录。SSM项目的资源文件一般有这几个：jdbc.properties或db.properties、spring-mvc.xml、applicationContext.xml、mybatis-config.xml。这些是接下来部署时主要要改的地方。如果你发现项目的配置文件里的数据库地址写的是服务器IP而不是localhost，那基本可以确定这是从线上环境拷回来的代码，改配置这一环躲不掉了。

2. 数据库和配置文件的"伺候"环节

2.1 建库导入SQL：字符集、时区、驱动一个都别漏

SSM项目跑起来只是第一步，真正要让它"活"起来，数据库必须就位。大多数项目压缩包里会附带一个.sql文件，文件名一般叫init.sql、db.sql或者直接用项目名命名。找个数据库客户端，推荐用Navicat、DBeaver或者命令行的mysql工具，先创建一个和线上环境同名的数据库，再导入数据。

建库语句我建议手动写，别用客户端默认的字符集：

CREATE DATABASE `ssm_demo` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

为什么要指定utf8mb4？因为你的表里可能有表情符号、特殊字符，utf8mb4是utf8的超集，能完整覆盖。直接导入sql文件也行，但要注意sql文件本身的编码。如果你的sql文件是UTF-8编码，而数据库默认字符集是latin1，导入后中文全变成问号，这属于"事后极难排查"的问题，我只能说宁可建库时多写一行字符集配置，也别赌运气。

导入完成后，务必确认表都建出来了，记录一下数据库名、用户名、密码，后面要用。这里有个高频报错：MySQL 8.0环境遇到"Public Key Retrieval is not allowed"和"Authentication plugin 'caching_sha2_password' cannot be loaded"。前者是连接MySQL 8时客户端首次连接需要获取公钥，后者是驱动版本太老。解决办法：把MySQL驱动升级到8.0.x版本，然后在连接串上加allowPublicKeyRetrieval=true&useSSL=false。

另一个新手闻到就头疼的问题是时区报错：The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized or represents more than one time zone。这是连接串里缺少serverTimezone=Asia/Shanghai导致的，加上就消停了。这些参数一会儿配置环节一起处理。

2.2 jdbc.properties与Spring核心配置的修改要点

数据库就绪后，接下来改代码里的配置。SSM项目最核心的配置文件是jdbc.properties，它长这样：

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

逐个参数解释：useUnicode和characterEncoding是保证中文不乱码的；useSSL=false是为了避免SSL握手导致连接变慢或失败；serverTimezone前面说过，解决时区报错；allowPublicKeyRetrieval=true是MySQL 8的坑。如果你的项目还在用com.mysql.jdbc.Driver这个老驱动类名，也可以跑，但强烈建议跟随MySQL版本升级到com.mysql.cj.jdbc.Driver。

这里有个隐藏很深的坑：如果这些配置直接写在Spring的XML里，而不是单独的properties文件里，连接串中的&符号必须写成&，因为XML会把&当特殊字符处理。我之前接手过一个项目，配置文件里就这一处没转义，Spring解析直接报错，排查了半天。这也是为什么推荐把数据库配置抽到properties文件里单独管理。

接着看Spring配置。典型的applicationContext.xml里会有这几块内容：<context:component-scan>扫描service和dao包、数据源dataSource、SqlSessionFactoryBean、MapperScannerConfigurer。第一次跑通只需要改数据源部分，把数据源属性指向jdbc.properties里的值即可。但如果项目里用了Redis，你得确认本机装了Redis服务，并且applicationContext-redis.xml里的redis.host、redis.port跟本地一致，否则启动时连接Redis超时，项目照样起不来。还别忘了一些业务配置，比如文件上传保存路径，原来的配置可能写的是线上服务器的/data/upload，本地环境就需要改成Windows的D:/upload或者macOS下的某个目录，并且确保目录存在，否则上传功能直接报错。

3. 完整实操：从IDEA调试到Tomcat发布

3.1 用IDEA直接跑起来的配置流程

本地部署SSM项目，最推荐的方式是在IDEA里配置一个Tomcat Server，然后以war exploded的方式启动。为什么推荐这种方式？因为IDEA的Tomcat集成支持热部署、断点调试，改完代码不用重启整个Tomcat，开发效率最高。

具体步骤：打开Run菜单里的Edit Configurations，点加号选Tomcat Server -> Local。在Server标签页里，Application Server选择你本机Tomcat的目录，如果没配置过，点Configure并选择Tomcat安装路径和JDK版本。然后切到Deployment标签页，点加号选Artifact，这时如果你看到两个可选项，选名称带"war exploded"的那个，Application context建议就填/，这样访问时不用带项目名。设置好后直接点Debug按钮，IDEA会自动启动Tomcat并加载项目。

如果你的IDEA里没有任何可选的Artifact，说明还没为项目创建。打开File -> Project Structure -> Artifacts，点加号选择Web Application: Exploded，From modules，选中你的web模块，然后勾选"Put into WEB-INF/lib"以确保依赖打包进去。这一步很多新手漏掉，结果启动半天报ClassNotFoundException，全是缺jar包。

另一种跑法是用Maven插件，在IDEA的Run Configuration里加一个Maven配置，命令行写tomcat7:run。别被"tomcat7"这个名字吓到，它是插件名，不代表只能跑Servlet 7，SpringMVC项目用这个插件跑本地调试是常规操作。这种方式的优点是只要Maven依赖能拉下来，项目就能跑，不需要手动配IDEA的Tomcat集成，适合那种没配置好IDEA环境的同学。注意如果8080端口被占，需要先在命令行里杀掉占用进程，或者改插件配置的port。

3.2 Maven打包与独立Tomcat发布

如果是给毕设答辩、或者是把项目交给别人在另一台机器上运行，IDEA的调试方式并不合适，这时候就要走经典的打包发布流程：Maven打包成war，丢进Tomcat的webapps目录，启动Tomcat。这也是最符合"部署"这个词本质的方式，毕竟线上服务器没有IDEA。

命令行进入项目根目录，执行：

mvn clean package -DskipTests

clean是清掉target目录的旧产物，package是打包，-DskipTests跳过测试。如果你的项目还没在本机下载过依赖，第一次执行会比较慢，因为Maven要从中央仓库拉jar包，几十兆的依赖拉半天很正常。国内网络环境下，强烈建议在Maven的settings.xml里配置阿里云镜像。在<mirrors>节点加一个镜像地址，比如阿里云的maven.aliyun.com/repository/public，下载速度会快一个数量级。

打包完成后，target目录下会出现xxx.war文件。把它复制到Tomcat的webapps目录下，然后进入Tomcat的bin目录，Windows下双击startup.bat，macOS或Linux下执行：

./startup.sh

Tomcat启动后会检测到war包并自动解压成同名目录，这就是你的应用上下文路径。比如war包叫ssm_demo.war，那么访问地址就是http://localhost:8080/ssm_demo/。如果访问时不想带项目名，可以把war包改名为ROOT.war，Tomcat会把ROOT作为根路径。

这里要提醒一件事：别在生产环境用这种方式直接部署，webapps目录下的war包Tomcat每次启动都会重新解压，如果在线上的话，应该部署到tomcat的webapps但不覆盖原目录或者用专业的部署方式。本地跑通验证没问题，这就够了。

3.3 启动、访问与首轮验证

启动Tomcat之后，最怕的就是控制台一闪而过、什么信息都没留下。所以本地调试阶段，不要用startup.bat启动，而是用catalina.bat run（macOS/Linux是catalina.sh run），这样Tomcat日志会直接打印在当前窗口，报错信息看得一清二楚。亲测比翻日志文件省事得多。

看到日志里出现Server startup in [xxxx] milliseconds，说明Tomcat已经起来了。这时打开浏览器访问你配置的地址。SSM项目的首页通常由SpringMVC的Controller映射到某个路径，或者web.xml里配置了welcome-file指向JSP。如果页面出来了，先别急着高兴，找一个需要跟数据库交互的页面点一下，比如登录、列表页，确认数据能正常查询出来。

验证数据链路有个小技巧：打开浏览器的开发者工具，看Network面板里XHR请求的状态码。如果是200并且响应里有数据，说明SpringMVC、MyBatis、MySQL整条链路通了。如果请求报500，转去Tomcat控制台看异常堆栈，重点看前几行，那通常就是真正的原因所在。我习惯在本地部署验证时，把日志级别调到DEBUG跑一遍登录流程，虽然日志刷得密，但能直观看到SQL语句是否执行、参数是否传对。

4. 本地部署十大翻车现场与排查方案

4.1 数据库连接失败的几种典型报错

数据库相关的问题占了SSM部署坑的半壁江山，我把最常见的几种整理成了一张速查表，按报错关键字搜索对应方案：

这里要特别说一个容易被忽略的点：配置文件里的密码如果含有特殊字符，比如@、#、&，在properties文件里不需要转义，但在URL里可能被解析成参数分隔符。最稳妥的做法是给MySQL单独建一个业务账号，密码设成简单的字母加数字，本地环境不用讲究权限最小化到这么细，能用就行，线上再收紧。

4.2 404、500、白屏乱码的定位思路

SSM项目最常见的翻车形态是三种：404、500、白屏乱码。它们的排查方向完全不同。

404要先区分是哪一层404。如果访问http://localhost:8080/项目名/直接404，多半是web.xml里的welcome-file配置有问题，或者webapp目录下没有可用的入口页面。如果访问某个Controller路径404，第一反应看请求的URL和@RequestMapping里的值是否完全一致，大小写、斜杠都不能差。另外看看DispatcherServlet在web.xml里配置的url-pattern，如果是*.do这种后缀匹配，而你又用/xxx去访问，那必然404。SpringMVC的静态资源也经常导致404，如果你的页面引用了CSS或JS但样式全没加载，检查spring-mvc.xml里有没有配置<mvc:default-servlet-handler/>或者专门的资源映射，否则DispatcherServlet会把所有请求都截走。

500的情况更复杂，但原则只有一个：看Tomcat控制台的异常堆栈，从上往下读。我遇到的SSM项目500大部分集中在MyBatis环节，比如Invalid bound statement (not found)，这是mapper接口和XML映射文件对不上。检查两件事：XML文件里namespace是不是写了接口的全限定名；method id是不是跟接口方法名一致。还有类名容易踩的坑：mapper的XML文件没有放在mapperLocations指定的路径下。Spring配置里写的是classpath*:mapper/*.xml，而你的XML在resources下的mybatis/mapper/目录，那必然找不到，路径必须对得上。

白屏乱码的问题，本质上就是编码不统一。JSP页面头部没声明pageEncoding="UTF-8"、Tomcat的server.xml里Connector没加URIEncoding="UTF-8"、MySQL连接串没配characterEncoding=utf8，三处有一处不对，中文就给你脸色看。本地部署统一改完这三处，乱码基本能根治。另外GET请求的中文参数，Tomcat默认按ISO-8859-1解码，这个只能在server.xml里加URIEncoding解决，代码层面怎么弄都费劲。

4.3 端口占用、内存不足与环境杂症

端口占用是本地部署里最烦的问题，没有之一。开了一堆软件，8080早就被别的进程占了，Tomcat启动提示Port 8080 was already in use。Windows下用命令：

netstat -ano | findstr 8080

找到那个进程的PID，然后taskkill /PID 进程号 /F强制结束。macOS和Linux用：

lsof -i :8080 kill -9 进程号

杀掉之后重新启动就行。如果不想杀，也可以改Tomcat的server.xml里Connector的port属性，换成8081、8090之类的空闲端口，但要注意项目代码里如果有写死8080的跳转，改了可能失灵。

内存不足是很多人忽略的坑。SSM项目小，但你把IDEA、Tomcat、MySQL、Redis全开着，笔记本8G内存很容易见底。Tomcat启动时默认的堆内存可能不够，报java.lang.OutOfMemoryError: PermGen space或者Java heap space。解决办法在Tomcat的bin目录下，catalina.bat（Linux是catalina.sh）里配置CATALINA_OPTS="-Xms512m -Xmx1024m"，给Tomcat单独分配至少512M的初始堆。IDEA本身如果启动慢、编译卡，调整IDEA安装目录下idea64.exe.vmoptions里的-Xmx值，比如2048m，亲测流畅不少。

还有一个环境杂症是lombok不生效，代码里用了@Data注解，但编译时getter/setter全找不到。在IDEA的Settings -> Build -> Compiler -> Annotation Processors里勾选"Enable annotation processing"，再检查Lombok插件是否安装，这两个缺一不可。

5. 部署思维迁移：SSM之外的那些"本地部署"

5.1 换电脑、换系统部署要动的几个地方

SSM项目本地部署跑通过一次，后面换电脑、换系统就是重复劳动，但有几个地方每次都要重来，提前知道能省很多事。

Windows和macOS/Linux的差异主要在可执行文件上。Windows下Tomcat启动用startup.bat，macOS/Linux用startup.sh。如果你在mac上碰到Permission denied，别慌，先执行chmod +x bin/*.sh给脚本加执行权限。MySQL的安装方式也不一样，Windows直接装个安装包，macOS可以用Homebrew装，或者下载dmg安装包。项目里的绝对路径也得跟着改，比如上传文件保存路径、日志输出路径，Windows写D:/logs/xxx.log，macOS写/Users/你的用户名/logs/xxx.log。

换电脑还有一个必踩的坑是本地Maven仓库是空的。新机器上执行mvn clean package会重新下载全部依赖，没配镜像的话慢到怀疑人生。所以换电脑后第一件事就是把Maven的settings.xml配好，把<localRepository>指定到自己的目录，同时配好阿里云镜像，能少喝两杯咖啡的等待时间。

如果你经常要在不同机器间折腾，推荐一个思路：用绿色便携版。JDK、Maven、Tomcat、MySQL都有zip免安装版本，解压到固定目录，配置一下就完事，不污染系统环境，也能避免和机器上已有的老版本冲突。我自己就维护了一套便携版环境，放在移动硬盘里，换电脑插上就能用，做毕设答辩演示尤其方便。

5.2 从SSM到Flask轻量平台：本地部署的底层逻辑

文章开头我说本地部署被AI大模型带火，其实这个概念的底层逻辑是相通的，SSM只是其中一种。我之前帮人弄过一个基于Flask的校园失物招领智能匹配平台，Python写的，用Flask框架，配一个轻量级数据库，支撑用户发布失物和招领信息，再用关键词相似度算法做匹配推荐。这个项目本地部署的流程跟SSM大同小异：装好Python环境，pip install -r requirements.txt装依赖，改一下数据库连接配置，然后python app.py启动。区别只是没有Tomcat这个容器，没有war包，没有web.xml，但核心四步完全一致——环境就绪、依赖到位、配置正确、启动验证。

热词里那些AI大模型本地部署、ollama部署，本质也是一样的事情：模型的运行环境、依赖的CUDA或运行时库、端口和内存资源、日志排查，这些跟SSM部署时你要操心的事情惊人地相似。所以说，SSM本地部署虽然看起来是个Java领域的"基本功"，但训练出的那套排查思路是可以迁移的。你学会了看报错日志、对齐版本、改配置、验证数据链路，下次去部署任何一个新东西，心里都会有个底：无非是环境、依赖、配置、启动、看日志这几件事。

我还有一个小建议：第一次部署SSM项目时，把所有操作记下来，写成一个自己的部署清单。我当时就是踩了三天的坑才跑通，然后花了半小时整理成笔记，后面不管是自己换电脑，还是帮同学弄项目，照着清单十分钟搞定。这个清单里包含了数据库建库语句、jdbc.properties的标准写法、Maven镜像配置、Tomcat的CATALINA_OPTS，甚至连"杀端口"的命令都记着。经验这东西，第一次最贵，后面都是免费的。希望这篇文章能帮你把第一次的代价降到最低。