WebGoat环境搭建全攻略：从Java配置到Docker部署的深度排错

1. 项目概述：为什么WebGoat环境搭建总出问题？

搞安全测试的朋友，对WebGoat这个靶场应该都不陌生。它由OWASP维护，里面塞满了各种经典的Web漏洞场景，从SQL注入、XSS到CSRF、文件上传，简直是安全初学者的“练功房”。但就是这个看似简单的Java Web应用，在环境搭建这一步，不知道劝退了多少跃跃欲试的新手。我自己带团队、做培训这么多年，见过太多人卡在“环境起不来”这一步，对着满屏的报错信息干瞪眼。

问题的核心在于，WebGoat虽然是一个教学工具，但它模拟的是一个相对完整的、存在漏洞的Web应用生态。这意味着它的运行依赖一个特定的环境栈：合适的Java版本、匹配的构建工具（Maven或Gradle）、正确的数据库配置，以及一个能处理其特殊依赖关系的应用服务器（通常是内嵌的Tomcat）。任何一个环节版本不匹配、配置有误，或者与你的操作系统环境（Windows/macOS/Linux）产生冲突，都会导致启动失败。更“有趣”的是，WebGoat的不同大版本（比如7.x, 8.x, 最新的）在架构和依赖上还有差异，网上搜到的教程如果版本对不上，基本就是“刻舟求剑”。

所以，这篇文章的目的不是给你另一个“一键安装”的教程——那种教程往往在你遇到第一个报错时就失效了。我要做的是，把我这些年搭建、排错、以及帮别人解决WebGoat环境问题的经验，系统地梳理出来。我会带你深入每个可能出错的环节，理解背后的原理，并给出具体的排查路径和解决方案。无论你是安全测试的初学者，还是需要在不同机器上快速部署测试环境的老手，这些“踩坑”经验都能让你少走弯路，把精力真正花在漏洞原理的学习和利用上，而不是跟环境较劲。

2. 核心需求解析：我们到底需要一个怎样的WebGoat环境？

在动手解决具体问题之前，我们必须先明确目标：一个“能用”的WebGoat环境，到底需要满足哪些条件？这不仅仅是把程序跑起来，而是要确保它能稳定、完整地支持后续所有的安全实验。

2.1 功能完整性需求

首先，WebGoat环境的核心功能必须完整。这包括：

1. Web服务正常启动：应用能够成功监听指定端口（默认8080），并通过浏览器访问到登录页面。
2. 所有课程模块可用：登录后，左侧的课程列表应完整加载，点击任一课程（如“SQL Injection”、“Cross-Site Scripting”）都能进入对应的漏洞练习界面。
3. 前后端交互正常：每个练习的漏洞触发、攻击Payload提交、结果反馈（成功或失败）功能必须工作。例如，在SQL注入课程中，你输入一个' or '1'='1，应该能看到预期的结果（如显示所有用户信息），而不是一个500内部服务器错误。
4. 数据持久化：用户的解题进度、部分课程（如“Http Basics”）的会话状态能够被正确记录和保持。

如果以上任何一点不满足，你的环境就是有缺陷的，无法用于有效的学习。很多搭建失败的情况，表面上服务启动了，但一操作就报错，问题往往出在更深层的依赖或配置上。

2.2 环境稳定性与可复现性需求

对于学习和研究而言，环境的稳定性与可复现性同样关键。

1. 版本可控：你需要明确知道你安装的是WebGoat的哪个版本（如webgoat-server-8.2.2.jar），以及与之配套的Java版本（如Java 11或17）。不同版本的WebGoat对Java的依赖可能不同，混用必然导致问题。
2. 依赖隔离：理想情况下，WebGoat的运行环境应该与系统全局环境隔离。避免因为系统中安装了多个不同版本的Java或Maven，导致环境变量冲突。使用Docker容器或通过工具（如jenvfor Java,virtualenv的类似思想）进行版本管理是很好的实践。
3. 配置可追溯：你对WebGoat所做的任何配置修改（如修改默认端口、数据库连接串）都应该是明确且可记录的。这样，当环境出现问题或需要在另一台机器上重建时，你可以快速复现。

理解这些需求后，我们就能有的放矢地进行环境准备和问题排查。接下来，我们就从最基础的环节开始拆解。

3. 环境准备阶段的典型问题与根治方案

万事开头难，WebGoat的环境搭建往往在第一步就卡住了。这部分我们聚焦在“安装和启动之前”，把那些看似简单却暗藏玄机的问题彻底解决。

3.1 Java环境：版本冲突与配置陷阱

Java是WebGoat的基石，这里的问题最常见也最令人头疼。

问题表象：

• 运行java -jar webgoat-server-xxx.jar时，提示UnsupportedClassVersionError（类版本不支持）。
• 提示找不到或无法加载主类。
• 程序启动后立即崩溃，或卡住无响应。

根因分析与解决方案：

1. 版本不匹配：这是头号杀手。WebGoat 8.x 通常需要Java 11 或更高版本（推荐Java 11或Java 17 LTS），而WebGoat 7.x 可能兼容Java 8。你用Java 8去跑需要Java 11的jar包，肯定会报UnsupportedClassVersionError。

   • 排查：在终端分别执行java -version和javac -version。确保它们指向同一个版本，且版本号符合要求。
   • 解决：
     • Windows/macOS：建议从Oracle官网或Adoptium（Eclipse Temurin）下载并安装指定的JDK版本。安装后，可能需要手动调整系统环境变量JAVA_HOME和PATH。一个常见的坑是：系统里装了多个JDK，PATH里顺序不对，导致命令行调用的不是你想要的那个。你可以通过where java（Windows）或which java（macOS/Linux）来查看实际调用的java程序路径。
     • macOS（使用Homebrew）：可以用brew install openjdk@11安装指定版本，然后用brew link --overwrite openjdk@11链接。但更推荐使用jenv这类工具来管理多个JDK版本，可以做到项目级隔离。
     • Linux：使用包管理器安装，如apt install openjdk-11-jdk，并通过update-alternatives --config java来切换默认版本。

2. JAVA_HOME配置错误或未设置**：一些启动脚本或构建工具（如Maven）依赖JAVA_HOME环境变量来定位JDK。

   • 排查：在终端执行echo $JAVA_HOME（Linux/macOS）或echo %JAVA_HOME%（Windows）。如果为空或路径不正确，就需要设置。
   • 解决：
     • Windows：系统属性 -> 高级 -> 环境变量，新建系统变量JAVA_HOME，值为你的JDK安装路径（如C:\Program Files\Java\jdk-11.0.15）。然后在Path变量中增加%JAVA_HOME%\bin。
     • macOS/Linux：在~/.zshrc或~/.bash_profile中添加：export JAVA_HOME=/path/to/your/jdk（例如/Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home），然后export PATH=$JAVA_HOME/bin:$PATH。最后执行source ~/.zshrc使配置生效。

实操心得：我强烈建议在个人电脑上使用像jenv（macOS/Linux）或通过绝对路径调用特定版本Java的方式来管理版本。对于团队或需要频繁重建的环境，直接使用Docker镜像是最省心的，它能提供完全一致的Java环境。

3.2 依赖管理工具：Maven构建失败详解

如果你是从源代码（GitHub仓库）构建WebGoat，或者下载的是需要编译的版本，那么Maven就是必经之路。这里网络问题和依赖冲突是两大拦路虎。

问题表象：

• 执行mvn clean install或mvn spring-boot:run时，卡在下载依赖（Downloading...）阶段。
• 构建过程中出现Could not resolve dependencies或Failed to read artifact descriptor等错误。
• 构建成功，但运行时出现ClassNotFoundException。

根因分析与解决方案：

1. 网络问题导致依赖下载失败：Maven中央仓库（Maven Central）在国外，国内直接访问可能速度慢或不稳定。

   • 解决：配置国内镜像源。找到Maven的配置文件settings.xml（通常在~/.m2/目录下），在<mirrors>标签内添加阿里云镜像：

     <mirror> <id>aliyunmaven</id> <mirrorOf>*</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>

     这能极大加速依赖下载。

2. 依赖版本冲突或仓库元数据损坏：有时本地仓库（~/.m2/repository）中的某个jar包或其元数据（.pom,.sha1文件）下载不完整或损坏，会导致后续构建一直失败。

   • 解决：
     • 清除本地仓库重新下载：这是最彻底的方法。你可以删除整个本地仓库目录（rm -rf ~/.m2/repository），但更温和的做法是只删除出问题的依赖目录。根据错误信息，找到对应的groupId和artifactId，手动删除~/.m2/repository下对应的文件夹，然后重新构建。
     • 使用-U参数强制更新：运行mvn clean install -U，强制Maven检查所有依赖的更新，并重新下载损坏的元数据。

3. 插件版本或兼容性问题：WebGoat的pom.xml中定义的Maven插件版本可能与你的Maven版本不兼容。

   • 解决：确保使用较新且稳定的Maven版本（如3.6.x以上）。如果错误明确指向某个插件（如maven-compiler-plugin），可以尝试在项目的pom.xml中显式指定一个已知兼容的插件版本。

注意事项：如果只是为了运行WebGoat，而非参与开发，我建议直接下载官方编译好的、可执行的JAR包（如webgoat-server-8.2.2.jar）。这能绕过所有Maven构建的复杂性。从GitHub的Release页面或OWASP官网直接下载，是最高效的方式。

4. 启动与运行阶段的故障诊断手册

当你的Java环境妥了，也拿到了可执行的JAR包，满怀信心地输入启动命令后，新的挑战才刚刚开始。服务启动不起来，或者启动后无法访问，是这一阶段的高频问题。

4.1 端口占用与网络权限问题

问题表象：

• 启动时抛出java.net.BindException: Address already in use。
• 服务启动日志显示成功，但浏览器访问http://localhost:8080连接被拒绝或无法访问。
• 在服务器或虚拟机上部署时，外部机器无法访问。

根因分析与解决方案：

1. 端口冲突：8080是WebGoat的默认端口，也是很多其他开发工具（如Tomcat、Jenkins）的常用端口。

   • 排查：
     • Linux/macOS：在终端运行lsof -i :8080或netstat -tulpn | grep 8080，查看是哪个进程占用了8080端口。
     • Windows：在命令提示符或PowerShell中运行netstat -ano | findstr :8080，找到对应的PID（进程ID），然后在任务管理器中根据PID结束该进程。
   • 解决：
     • 终止占用进程：如果占用端口的是非关键进程，可以安全地终止它。
     • 修改WebGoat启动端口：这是更推荐的做法。通过命令行参数指定新端口启动：

       java -jar webgoat-server-8.2.2.jar --server.port=9090

       这样WebGoat就会在9090端口运行，访问地址变为http://localhost:9090。

2. 防火墙/安全组限制：特别是在云服务器（AWS EC2、阿里云ECS）或本地开启了防火墙的Linux系统上。

   • 排查：在服务器本机使用curl http://localhost:8080可以访问，但用外部机器的浏览器访问http://<服务器IP>:8080不行。
   • 解决：
     • Linux本地防火墙（如ufw或firewalld）：

       # 对于ufw (Ubuntu/Debian常见) sudo ufw allow 8080/tcp sudo ufw reload # 对于firewalld (CentOS/RHEL常见) sudo firewall-cmd --permanent --add-port=8080/tcp sudo firewall-cmd --reload

     • 云服务器安全组：登录云服务商的控制台，找到你实例所属的安全组，添加入站规则，允许TCP协议访问你设定的端口（如8080或9090），源IP可以设置为0.0.0.0/0（对所有IP开放，仅限测试环境）或你个人的公网IP。

4.2 内存不足与JVM参数调优

WebGoat作为一个完整的Web应用，启动和运行需要一定的内存。默认配置在资源有限的机器上可能不够。

问题表象：

• 启动过程中或运行一段时间后，控制台抛出java.lang.OutOfMemoryError: Java heap space。
• 应用启动极其缓慢，响应卡顿。
• 在Docker容器中运行WebGoat时，容器频繁重启或被杀死。

根因分析与解决方案： JVM内存主要分为堆（Heap）和非堆（Non-Heap）区域。堆内存是OOM的常发地。

• 解决：通过JVM启动参数调整内存分配。

  java -Xms512m -Xmx1024m -jar webgoat-server-8.2.2.jar

  • -Xms512m：设置JVM初始堆内存为512MB。这个值设得太小，会导致频繁进行垃圾回收（GC）；设得太大，会浪费内存。
  • -Xmx1024m：设置JVM最大堆内存为1024MB（1GB）。这是应用能使用的堆内存上限。对于WebGoat 8.x，1GB通常足够；如果课程加载很多或同时有多个用户，可以适当增加到-Xmx2048m（2GB）。

实操心得：如果你在IDE（如IntelliJ IDEA）中运行WebGoat，也需要在运行配置（Run Configuration）里修改VM Options，添加上面的参数。对于生产环境或资源紧张的VPS，监控内存使用情况很重要，可以使用jconsole或jvisualvm（JDK自带工具）连接到运行中的WebGoat进程进行观察。

4.3 数据库连接与初始化失败

WebGoat使用内嵌的H2数据库（一种内存数据库）来存储课程数据和用户进度。虽然默认配置是开箱即用的，但在特定情况下也会出问题。

问题表象：

• 启动日志中出现大量与数据库连接、表创建或初始化脚本执行相关的错误或警告。
• 能够登录，但课程列表为空，或点击课程时提示数据错误。
• 应用重启后，之前的学习进度全部丢失（这有时是预期行为，因为H2内存模式关闭后数据不持久化）。

根因分析与解决方案：

1. 数据库文件权限问题：如果你配置了使用文件模式的H2数据库（为了持久化），而运行WebGoat的用户（如www-data或你自己）对数据库文件所在目录没有写权限。

   • 解决：检查数据库文件路径（如~/.webgoat-8.2.2/data/webgoat_db），确保运行WebGoat的进程有该目录的读写权限。

2. 初始化脚本执行错误：WebGoat在启动时会执行SQL脚本来创建表和初始化数据。如果脚本中有语法错误（极少数情况），或与当前H2数据库驱动版本不兼容，会导致初始化失败。

   • 排查：仔细查看启动日志中SchemaCreator或DataSourceInitializer相关的错误信息。
   • 解决：这通常与WebGoat版本本身有关。尝试下载一个更新或更稳定的Release版本。如果是从源码构建，确保拉取的是官方仓库的最新稳定分支。

3. 期望数据持久化：默认的内存模式（jdbc:h2:mem:webgoat）在应用停止后数据会消失。如果你想保留进度，需要修改配置。

   • 解决：使用文件模式启动。你可以通过命令行参数或创建application.properties文件来配置：
     • 命令行参数：

       java -jar webgoat-server-8.2.2.jar --spring.datasource.url=jdbc:h2:file:~/.webgoat-8.2.2/data/webgoat_db

     • 配置文件：在与JAR包同目录下创建application.properties，内容为：

       spring.datasource.url=jdbc:h2:file:~/.webgoat-8.2.2/data/webgoat_db

     这样，数据库文件会保存在用户主目录下的.webgoat-8.2.2/data/文件夹中，重启应用后数据依然存在。

5. 访问与交互阶段的疑难杂症

恭喜你，服务终于跑起来了，也能看到登录页面了。但别高兴太早，登录进去操作课程时，可能还会遇到一些令人困惑的问题。

5.1 前端资源加载失败（CSS/JS 404）

问题表象：

• 浏览器能打开WebGoat首页，但页面样式错乱，看起来像“裸奔”的HTML。
• 浏览器开发者工具（F12）的“网络”（Network）选项卡中，显示大量对.css、.js或图片文件的请求返回404状态码。

根因分析： 这通常是因为WebGoat的前端静态资源（由webgoat-client模块提供）没有被正确打包到最终的JAR文件中，或者应用在运行时无法从classpath中找到这些资源。在从源码构建时，如果构建过程不完整（比如只编译了webgoat-server没编译webgoat-client），就容易出现这个问题。

解决方案：

1. 确保使用官方完整的发行版JAR：再次确认你下载的是webgoat-server-xxx.jar，而不是其他模块的JAR。完整的发行版JAR通常体积较大（100MB左右），因为它包含了内嵌的前端资源。
2. 检查构建流程：如果你是从源码构建，请确保按照官方README的说明，在项目根目录执行了完整的构建命令，例如mvn clean install（这会构建所有模块，包括client）。有时需要先构建client模块，生成静态资源文件。
3. 查看启动日志：关注启动日志中是否有关于“静态资源路径”或“MVC映射”的警告信息。Spring Boot应用默认会在classpath:/static/,classpath:/public/等位置寻找静态资源。

5.2 课程功能异常与浏览器兼容性

问题表象：

• 点击某个课程（如“Cross-Site Request Forgery”）后，页面功能不全或无法操作。
• 提交攻击Payload后，页面无反应，或提示“无法连接到服务器”。
• 在某些浏览器（如旧版IE）中，页面完全无法正常工作。

根因分析与解决方案：

1. 浏览器控制台报错（JavaScript错误）：这是最直接的线索。按F12打开开发者工具，查看“控制台”（Console）选项卡是否有红色的错误信息。错误可能指向某个前端API调用失败或JavaScript语法错误。

   • 解决：根据错误信息判断。如果是API调用（fetch或XMLHttpRequest）失败，可能是后端接口问题（见下一点）。如果是语法错误，可能与浏览器兼容性有关。

2. 后端API接口问题：前端通过Ajax调用后端REST API。如果API返回错误（4xx或5xx），前端功能就会失效。

   • 排查：在开发者工具的“网络”（Network）选项卡中，找到状态码为4xx或5xx的XHR/Fetch请求，点击查看响应详情。服务器返回的JSON错误信息通常会指明问题，如“课程未找到”、“用户未认证”、“参数无效”等。
   • 常见原因与解决：
     • 认证失效：WebGoat使用会话（Session）管理登录状态。如果你清理了浏览器Cookie，或者会话超时，就会导致后续API调用因未认证而失败。重新登录即可。
     • 课程数据未加载：有时课程列表加载不全。尝试刷新页面或重新登录。
     • 靶场服务未完全启动：有些课程（如“WebWolf”）可能需要额外的组件。确保你按照官方说明启动了所有必要服务。

3. 浏览器兼容性问题：WebGoat的前端可能使用了较新的JavaScript特性（如ES6+语法、Fetch API），这些特性在旧版本浏览器中不被支持。

   • 解决：使用现代浏览器，如最新版本的Google Chrome、Mozilla Firefox、Microsoft Edge或Safari。避免使用Internet Explorer。

注意事项：WebGoat的某些高级课程（如“WebWolf”）可能需要单独启动一个辅助应用（WebWolf），并确保两者能互相通信。务必阅读你所用版本WebGoat的官方文档，确认是否需要以及如何启动和配置WebWolf。通常，WebGoat和WebWolf会分别在不同的端口运行（如8080和9090），并且需要在WebGoat的设置中正确配置WebWolf的地址。

6. 高阶部署与容器化排错指南

对于追求环境一致性、快速部署或团队共享的进阶用户，使用Docker是部署WebGoat的绝佳选择。但容器化也带来了新的问题维度。

6.1 Docker镜像拉取与运行失败

问题表象：

• docker pull webgoat/webgoat速度极慢或失败。
• docker run命令执行后，容器立即退出（Exited）。
• 容器在运行，但无法从宿主机访问WebGoat页面。

根因分析与解决方案：

1. 镜像拉取慢或失败：Docker Hub的服务器在国外。

   • 解决：配置Docker国内镜像加速器。
     • Docker Desktop (Windows/macOS)：在设置（Settings） -> Docker Engine中，修改registry-mirrors配置，添加国内镜像地址，如阿里云镜像（需要登录阿里云容器镜像服务获取专属加速地址）或中科大镜像https://docker.mirrors.ustc.edu.cn。
     • Linux：编辑/etc/docker/daemon.json文件（不存在则创建），添加：

       { "registry-mirrors": ["https://docker.mirrors.ustc.edu.cn"] }

     然后重启Docker服务：sudo systemctl restart docker。

2. 容器端口映射错误：这是导致“容器运行但无法访问”的最常见原因。

   • 标准运行命令：

     docker run -p 8080:8080 -p 9090:9090 -t webgoat/webgoat

     • -p 8080:8080：将宿主机的8080端口映射到容器的8080端口（WebGoat服务）。
     • -p 9090:9090：将宿主机的9090端口映射到容器的9090端口（WebWolf服务，如果镜像包含）。
   • 排查：运行docker ps查看容器状态和端口映射。确认映射关系正确。如果宿主机8080端口已被占用，需要修改命令，例如-p 8888:8080，然后通过http://localhost:8888访问。

3. 容器内应用启动失败：容器日志是排查问题的第一现场。

   • 解决：使用docker logs <容器ID或名称>查看容器内部的应用日志。常见的错误原因与前面章节类似：容器内Java版本问题、内存不足、数据库初始化失败等。Docker镜像通常已经配置好Java环境，所以内存问题更常见。你可以通过Docker运行参数来调整内存限制：

     docker run -p 8080:8080 -m 1g --memory-swap -1 -t webgoat/webgoat

     -m 1g限制容器使用最多1GB内存，--memory-swap -1允许使用交换分区（根据宿主机情况）。

6.2 容器数据持久化与版本管理

默认情况下，Docker容器内的数据（如H2数据库文件）会随着容器的删除而丢失。

需求：希望保留WebGoat的学习进度，即使删除并重新创建容器。

解决方案：使用Docker数据卷（Volume）或绑定挂载（Bind Mount）将容器内的数据目录持久化到宿主机。

# 方法一：使用命名卷（Docker管理位置） docker volume create webgoat_data docker run -p 8080:8080 -v webgoat_data:/home/webgoat/.webgoat -t webgoat/webgoat # 方法二：使用绑定挂载（指定宿主机路径） mkdir -p ~/webgoat_data docker run -p 8080:8080 -v ~/webgoat_data:/home/webgoat/.webgoat -t webgoat/webgoat

• /home/webgoat/.webgoat是官方镜像中WebGoat默认的数据存储路径（包括数据库和配置文件）。
• 通过-v参数将宿主机目录或卷挂载到此路径，即可实现数据持久化。

版本管理提示：Docker镜像标签（Tag）对应WebGoat版本。直接docker pull webgoat/webgoat拉取的是latest标签，可能不是最稳定版本。建议指定版本，如docker pull webgoat/webgoat:v8.2.2，并在docker run时使用完整镜像名。

7. 系统性排查流程与日志分析实战

当问题发生时，漫无目的地尝试重启或搜索错误信息是低效的。建立一个系统性的排查流程，并学会阅读日志，是快速定位问题的关键能力。

7.1 四步定位法：从现象到根因

无论遇到什么问题，都可以遵循以下四个步骤来缩小范围：

1. 确认现象：问题是什么？精确描述。是“无法启动”、“启动后退出”、“能访问但样式丢失”、还是“某个具体功能报错”？记录下完整的错误信息（截图或复制文本）。
2. 检查环境：
   • 版本：Java版本 (java -version)、WebGoat版本（JAR文件名或镜像标签）、操作系统。
   • 端口：所需端口是否被占用 (netstat -ano | findstr :8080或lsof -i :8080)。
   • 资源：磁盘空间是否充足？内存是否足够？（启动时可通过-Xmx调整）。
   • 网络：如果是远程访问，防火墙/安全组规则是否放行？
3. 查看日志：这是最重要的一步。日志是应用程序的“黑匣子”。
   • 控制台输出：直接运行JAR时，所有日志都会打印在控制台。仔细阅读启动过程中的INFO、WARN和ERROR信息。
   • 日志文件：如果应用以服务形式后台运行，日志可能写入文件。WebGoat Spring Boot应用默认日志会输出到控制台，但可以通过--logging.file.name参数指定文件，如--logging.file.name=webgoat.log。
   • Docker容器日志：docker logs <container_id>。
4. 隔离测试：
   • 最小化复现：尝试在一个干净的环境（如新的虚拟机、容器）中，用最少的步骤（只下载JAR和安装匹配的Java）重现问题。这能排除系统原有环境的干扰。
   • 参数调整：一次只改变一个变量（如Java版本、启动端口、内存参数），观察问题是否消失或变化。

7.2 关键日志信息解读

Spring Boot（WebGoat所用框架）的启动日志信息量很大，要学会抓重点：

• 启动成功标志：寻找包含Started WebGoat字样的行，后面会跟着启动耗时和端口信息。例如：

  2023-10-27 10:00:00.000 INFO 12345 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 8080 (http) with context path '' 2023-10-27 10:00:00.001 INFO 12345 --- [ main] org.owasp.webgoat.WebGoat : Started WebGoat in 15.456 seconds (JVM running for 16.789)

  看到这个，基本可以确定应用核心已正常启动。

• 数据库初始化：关注DataSourceInitializer或H2相关的日志。成功的话会看到H2 console available at ...和Database initialized之类的信息。失败则会有具体的SQL异常。

• 应用上下文加载错误：如果看到Application run failed或Failed to load ApplicationContext，这通常是致命错误，可能是配置错误、依赖缺失或Bean创建失败。错误堆栈（StackTrace）会指出具体出错的类和方法，是排查的关键。

• 连接被拒绝：如果看到Connection refused错误，通常是WebGoat尝试连接其他服务（如数据库、WebWolf）失败。检查相关服务是否启动，以及配置的地址端口是否正确。

• 权限错误：日志中出现Permission denied或Access denied，说明进程对某个文件或目录没有读写权限。需要检查对应路径的权限设置。

养成遇到问题先看日志、仔细阅读错误信息的习惯，你能自己解决90%以上的环境搭建问题。搜索引擎是你的朋友，但把完整的错误信息（而不是你的主观描述）直接粘贴搜索，往往能得到更准确的答案。