当前位置：首页 > news >正文

JavaSecLab漏洞靶场部署与实战指南：从环境搭建到代码审计

news 2026/7/4 11:48:09

1. 项目概述与核心价值

最近在跟几个刚入行安全开发的朋友聊天，发现他们虽然学了不少Java开发，也了解一些OWASP Top 10的概念，但真让他们去挖一个现成的Java Web应用漏洞，或者去理解一个漏洞在代码层面到底是怎么被触发和利用的，往往就有点无从下手了。理论是理论，实战是实战，中间缺的就是一个能亲手“摆弄”的靶场。这让我想起了几年前自己入门时的窘境，当时要找到一个集成了多种Java漏洞场景、代码清晰、还能一键部署的本地实验环境，真的不容易。直到我遇到了JavaSecLab这个开源项目，它几乎完美地填补了这个空白。

简单来说，JavaSecLab就是一个专门为Java安全学习、研究和教学设计的漏洞靶场。它不是那种简单的、只有一个登录框的CTF题目，而是一个完整的、模拟了真实企业级Java Web应用架构的实验室。里面集成了从最常见的SQL注入、XSS，到相对复杂的反序列化、SSRF、文件上传绕过、SpEL表达式注入等几十种漏洞场景。最关键的是，它把存在漏洞的代码片段和安全的修复代码放在一起对比，让你能清晰地看到“问题出在哪”以及“怎么修”。对于想深入理解Java安全漏洞原理、提升代码审计能力，或者为企业做安全开发培训的工程师来说，这玩意儿就是个宝藏。

我自己在带新人、做内部培训的时候，JavaSecLab是必上的“实操课”。它能让你避开在公网靶场上可能遇到的环境不稳定、题目过期等问题，在本地就能搭建一个专属的、可反复折腾的安全实验室。接下来，我就结合自己多次部署和使用的经验，给你拆解一下从零开始玩转JavaSecLab的完整流程，以及那些官方文档里可能没细说，但实际踩坑时一定会遇到的“坎儿”。

2. 环境准备与前置条件解析

在动手部署之前，把环境理顺是成功的一半。JavaSecLab虽然提供了多种部署方式，但其核心依赖其实就三样：Java、Maven和Docker。下面我详细说说每个环节的选型理由和避坑点。

2.1 Java与Maven环境配置

项目明确要求使用Java 8。这里有个深坑：并不是你系统里装了个JDK 8就万事大吉了，关键是Maven运行时也必须指向同一个Java 8环境。很多朋友编译失败，问题就出在这里。

为什么必须是Java 8？这个项目里用到了不少历史版本的依赖库，这些库的API或特性在Java 11及以上版本中可能已被标记为废弃（deprecated）甚至移除。强行用高版本JDK编译，会遇到各种“找不到类”或“不支持的版本”错误。Java 8是目前企业环境中保有量最大、最稳定的一个LTS版本，选择它能最大程度保证依赖兼容性。

实操步骤与验证：

安装JDK 8：从Oracle官网或AdoptOpenJDK等渠道下载安装。安装后，在终端执行java -version和javac -version，确保输出显示版本为1.8.x。
配置Maven：去Apache官网下载Maven（版本3.6.x以上均可）。解压后，重点在于配置其JAVA_HOME。编辑Maven安装目录下conf/settings.xml文件不是必须的，关键是系统环境变量。
关键检查点：打开终端，依次执行以下命令，确保三者一致：
```
# 检查系统默认Java版本 java -version # 检查Maven运行时使用的Java版本 mvn -v
```
在mvn -v的输出信息中，第一行应该明确显示Java version: 1.8.x。如果这里显示的是Java 11或更高，说明你的Maven正使用其他JDK。你需要检查并设置系统的JAVA_HOME环境变量，将其指向你的JDK 8安装目录，然后重新打开终端。

我的踩坑记录：有一次我在macOS上，通过Homebrew安装了JDK 8，但系统之前还装有JDK 11。即使我设置了JAVA_HOME，mvn -v依然显示Java 11。最后发现是Homebrew安装的Maven其内部脚本硬编码了另一个JDK路径。解决办法是直接下载Apache官方的Maven压缩包，手动解压配置，并在.zshrc或.bash_profile中明确将PATH变量里Maven的路径放在最前面，确保它优先被调用。

2.2 Docker与Docker Compose环境

Docker是现代化部署的利器，JavaSecLab强烈推荐使用Docker Compose进行一键部署，因为它把MySQL数据库、Redis（如果用到）和Web应用本身都编排好了。

安装要点：

Docker Desktop (Mac/Windows)：对于桌面用户，直接安装Docker Desktop是最省心的选择，它自带Docker Compose。安装后务必在设置中分配足够的资源（建议CPU≥2核，内存≥4GB），否则构建镜像时可能会因资源不足而失败。
Linux服务器：通过各发行版的包管理器安装Docker Engine和Docker Compose插件。记得将当前用户加入docker用户组，避免每次命令都要加sudo。
```
sudo usermod -aG docker $USER
```
执行后需要退出当前终端会话并重新登录，这个改动才会生效。

镜像源加速：这是国内环境部署成败的关键。默认的Docker Hub源速度慢且不稳定，极易导致镜像拉取超时。你需要配置国内镜像加速器。

配置方法（以Linux为例）：

创建或编辑/etc/docker/daemon.json文件。

填入以下内容（可以选用一个你网络访问最快的镜像，比如阿里云或中科大）：

{ "registry-mirrors": [ "https://<你的ID>.mirror.aliyuncs.com", // 阿里云（需登录容器镜像服务控制台获取） "https://docker.mirrors.ustc.edu.cn", // 中科大 "https://hub-mirror.c.163.com" // 网易 ] }

重启Docker服务使配置生效：

sudo systemctl daemon-reload sudo systemctl restart docker

验证是否生效：docker info，在输出中查找Registry Mirrors部分，确认包含你设置的镜像地址。

注意：不同镜像源的同步频率和完整性可能有细微差异。如果遇到某个特定镜像拉取失败，可以临时注释掉其他镜像源，只保留一个试试，或者直接使用docker pull命令时指定完整镜像地址。

3. 三种部署方式详解与选型建议

JavaSecLab提供了三种部署路径，适合不同需求和熟练度的使用者。我会逐一拆解，并告诉你哪种情况该选哪个。

3.1 方案一：IDEA本地部署（适合开发者深度调试）

这是最“原始”但也最灵活的方式。你需要把项目源码克隆到本地，用IntelliJ IDEA打开，配置好数据库，然后以Spring Boot应用的形式直接运行。这种方式最大的好处是你可以随时在IDE里打断点、单步调试、热修改代码，非常适合想要深入研究某个漏洞触发链、或者打算为项目贡献代码（提PR）的开发者。

详细步骤：

获取源码：

git clone https://github.com/whgojp/JavaSecLab.git cd JavaSecLab

数据库准备：
- 在本地或服务器上安装一个MySQL 8.0+的实例。用Docker跑一个是最快的：
```
docker run --name mysql-javasec -e MYSQL_ROOT_PASSWORD=QWE123qwe -p 13306:3306 -d mysql:8
```
- 使用数据库连接工具（如MySQL Workbench, Navicat, 甚至命令行），连接到localhost:13306，用户root，密码QWE123qwe。
- 执行项目sql/目录下的JavaSecLab.sql文件。这个脚本会创建数据库、表结构并插入初始数据（包括默认的管理员账号admin/admin）。
关键配置修改：
- 用IDEA打开项目后，找到src/main/resources/application.yml。这个文件是Spring Boot的主配置文件。
- 你会看到类似下面的配置：
```
spring: profiles: active: docker # 默认激活的是docker配置
```
- 将active: docker改为active: dev。这一步至关重要，它告诉Spring Boot去加载application-dev.yml这个针对本地开发环境的配置文件，而不是使用Docker环境下的配置（后者可能指向容器内的数据库地址）。
检查开发配置：
- 打开src/main/resources/application-dev.yml。这里定义了开发环境的数据源。
- 确认数据库连接信息与你刚启动的MySQL实例匹配，尤其是url中的端口（示例中是13306）和数据库名（JavaSecLab）。
```
spring: datasource: username: root password: QWE123qwe url: jdbc:mysql://localhost:13306/JavaSecLab?characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai
```
- 如果密码或端口不同，请在此修改。
运行与访问：
- 在IDEA中找到主启动类（通常是有@SpringBootApplication注解的类），右键点击Run。
- 控制台无报错，看到类似Tomcat started on port(s): 8080的日志，说明启动成功。
- 打开浏览器，访问http://localhost:8080，使用admin/admin登录即可。

心得：这种方式下，你的应用直接连接本地数据库，所有改动（包括漏洞利用尝试）都是实时的。我常用它来复现一个漏洞的利用过程，然后在同一IDE窗口里，直接修改代码，尝试修复，再重启应用验证修复是否有效，学习闭环非常短。

3.2 方案二：“半自动”部署（平衡便捷与可控）

如果你不想在本地编译项目（可能因为Maven依赖下载慢，或者环境配置总出问题），但又希望拥有类似Docker部署的便捷性，这个“半自动”方案是绝佳选择。它的核心思想是：你直接下载作者已经编译打包好的JavaSecLab.jar文件，然后结合Docker Compose来运行。

操作流程：

下载Release包：
- 访问JavaSecLab的GitHub Releases页面（例如：https://github.com/whgojp/JavaSecLab/releases）。
- 下载最新版本的JavaSecLab.jar文件。
准备项目目录结构：
- 在你喜欢的位置创建一个工作目录，例如~/javaseclab-deploy。
- 将下载的JavaSecLab.jar文件放入该目录。
- 关键一步：在该目录下新建一个名为target的文件夹，然后把JavaSecLab.jar移动到这个target文件夹内。最终的路径应该是~/javaseclab-deploy/target/JavaSecLab.jar。
- 将项目源码中的docker-compose.yml文件复制到这个工作目录。
启动服务：
- 打开终端，进入这个工作目录 (~/javaseclab-deploy)。
- 执行一条命令：
```
docker-compose -p javaseclab up -d
```
- Docker Compose会读取docker-compose.yml，发现里面定义的服务需要依赖target/JavaSecLab.jar，而这个文件我们已经准备好了，于是它会直接基于这个jar包构建Docker镜像并启动容器。

这个方案的妙处：它跳过了最耗时的mvn clean package编译过程，也避免了你本地可能存在的复杂环境问题。你得到的依然是一个容器化的、隔离的运行时环境，管理起来和全Docker方案一样方便。对于只想快速体验漏洞靶场，或者网络环境导致编译困难的同学，这是首选。

3.3 方案三：完整的Docker Compose部署（最推荐的生产化体验）

这是最“干净”、最接近现代应用部署流程的方式。整个过程完全由Docker管理，从拉取基础镜像、编译代码、构建应用镜像、启动数据库到运行应用，全部自动化。它能保证你在任何装有Docker的机器上，获得完全一致的运行结果。

它又细分为两种子模式：

模式A：使用预构建的公共镜像（最快）项目作者通常会将稳定版的JavaSecLab应用打包成镜像，推送到Docker Hub等公共仓库。你可以直接拉取这个镜像运行，速度最快。

# 进入项目根目录（包含 docker-compose.image.yml 文件） cd JavaSecLab # 使用指定的compose文件启动 docker compose -f docker-compose.image.yml up -d

这个docker-compose.image.yml文件里，web服务的配置直接从whgojp/javaseclab:latest这样的远程镜像地址拉取，无需本地构建。

模式B：本地源码构建镜像（最可控）如果你想部署最新的代码（比如刚拉取了Git主分支），或者想自定义一些构建参数，就需要在本地从源码构建镜像。

# 1. 确保在项目根目录 cd JavaSecLab # 2. 使用Maven编译打包项目（跳过测试以加快速度） mvn clean package -DskipTests # 这一步可能会花一些时间，因为它要下载所有依赖并编译。 # 3. 使用默认的docker-compose.yml启动 docker-compose -p javaseclab up -d

这个docker-compose.yml文件里，web服务的配置包含一个build: .指令，它会读取当前目录下的Dockerfile，利用上一步生成的target/JavaSecLab.jar来构建一个新的Docker镜像。

部署后的验证：无论采用哪种模式，启动成功后，执行docker ps应该能看到两个容器在运行：一个是javaseclab-web（应用），另一个是javaseclab-db（数据库）。应用默认映射到宿主机的80端口。直接访问http://localhost或http://<你的服务器IP>即可。

选型建议：
新手、求快：直接用“方案二：半自动部署”或“方案三的模式A（公共镜像）”。5分钟内就能看到界面。
开发者、研究者：用“方案一：IDEA本地部署”，方便调试和代码学习。
希望环境干净、可复现：用“方案三的模式B（本地构建）”。这是最标准的CI/CD流程，也便于你后续自定义Dockerfile（比如更换基础镜像版本）。

4. 核心问题排查与实战技巧

即使按照教程一步步来，在实际部署中你还是大概率会遇到一两个“拦路虎”。下面我把这些常见问题、背后的原因以及我的解决经验整理出来，你可以像查字典一样对照着看。

4.1 编译失败：Maven报错的终极排查思路

执行mvn clean package -DskipTests时红字飘满屏，这是最常见的“劝退”场景。别慌，按以下顺序排查：

确认Java版本：这是第一嫌疑犯。再次用mvn -v确认Java版本为1.8。如果不是，请彻底检查并修正你的JAVA_HOME和PATH环境变量。
清理本地Maven仓库：有时候本地仓库的依赖包下载不完整或损坏，会导致各种奇怪的错误。可以尝试清理后重新下载：
```
# 删除本地仓库中本项目的依赖（谨慎操作，这会删除所有本地缓存） # rm -rf ~/.m2/repository # 更安全的方式：只删除项目目录下的target文件夹，然后让Maven重新解决依赖 mvn clean
```
然后再次执行mvn package -DskipTests。Maven会重新下载所有依赖，虽然慢，但能解决很多因网络中断导致的依赖问题。
网络问题与镜像源：Maven中央仓库在国外，下载慢或超时也会导致失败。为Maven配置国内镜像源能极大提升成功率。编辑~/.m2/settings.xml（没有就创建），添加阿里云镜像：
```
<mirrors> <mirror> <id>aliyunmaven</id> <mirrorOf>*</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror> </mirrors>
```
检查POM文件：极少数情况下，项目根目录的pom.xml可能因为更新而存在暂时性的依赖冲突。可以尝试使用-U参数强制更新所有依赖的快照版本：mvn clean package -DskipTests -U。

4.2 部署成功但无法登录：数据库初始化之谜

这是Docker部署模式下最经典的问题。现象是：访问首页正常，但用默认账号admin/admin登录时提示用户不存在，查看应用日志会发现类似Table 'JavaSecLab.user' doesn't exist的错误。

根本原因：在Docker Compose的启动流程中，MySQL容器先启动，然后Java应用容器启动。理想情况下，应用启动时（通过Flyway或类似的数据库迁移工具）会自动执行SQL脚本来初始化表结构。但这个自动初始化过程有时会失败，原因可能是：

网络问题导致应用容器启动时，数据库容器虽已运行但尚未完全准备好接受连接。
数据库迁移脚本的执行时机或配置问题。
挂载的数据库数据卷（volume）里已有残留数据，但结构不对。

解决方案（手动初始化数据库）：

找到你的数据库容器ID或名称：docker ps | grep mysql或docker ps | grep db。

进入数据库容器的命令行：

docker exec -it <你的数据库容器名> bash

在容器内连接MySQL（密码参考docker-compose.yml中的MYSQL_ROOT_PASSWORD环境变量，通常是QWE123qwe）：
```
mysql -u root -p # 输入密码
```
手动创建数据库并导入SQL文件。你需要先将项目中的sql/JavaSecLab.sql文件复制到容器内，或者直接从宿主机导入。方法A（如果SQL文件在宿主机上）：在宿主机执行：
```
# 将SQL文件复制到容器内 docker cp /path/to/JavaSecLab.sql <你的数据库容器名>:/tmp/JavaSecLab.sql # 进入容器并导入 docker exec -i <你的数据库容器名> mysql -u root -pQWE123qwe JavaSecLab < /path/to/JavaSecLab.sql
```
方法B（在容器内操作）：如果你已经通过docker exec进入了容器的bash，并且SQL文件也在容器内（比如通过复制进去的），可以：
```
-- 在MySQL命令行中 CREATE DATABASE IF NOT EXISTS JavaSecLab; USE JavaSecLab; SOURCE /tmp/JavaSecLab.sql; -- 假设文件在/tmp下
```
退出MySQL和容器，然后重启Java应用容器：docker restart <你的应用容器名>。

我的标准操作流程：为了避免每次部署都遇到这个问题，我现在养成了一个习惯：在docker-compose up -d之后，不等登录，先执行一次数据库手动导入。虽然多一步，但能保证100%成功。你可以把这个检查步骤写成一个简单的shell脚本。

4.3 端口冲突与修改方法

项目默认使用80端口，如果你的宿主机80端口已被Nginx、Apache或其他应用占用，就需要修改。

需要修改的文件不止一个，而是三个，它们需要保持一致：

docker-compose.yml(或docker-compose.image.yml)：找到web服务的ports映射部分。
```
services: web: ... ports: - "80:8080" # 将左边的宿主端口80改为你想要的，如“8080:8080”
```
这里宿主机端口:容器内端口。容器内端口（8080）是Spring Boot应用默认监听的，一般不要改。我们只改冒号前的宿主机端口。
src/main/resources/application.yml：如果你采用本地部署（方案一），并且修改了Spring Boot的服务器端口，需要同步修改。但对于Docker部署，应用在容器内仍运行在8080，所以通常不需要改这里。
前端配置（如果有）：有些Web应用的前端代码里可能硬编码了API的访问地址（如localhost:80/api）。JavaSecLab的前后端似乎是打包在一起的，所以主要关注第1点即可。

修改后，务必重新构建或启动容器：

如果改了docker-compose.yml，需要运行docker-compose down停止并移除旧容器，然后再docker-compose up -d重新创建。
如果改了应用配置并重新打包，则需要重新执行构建和启动流程。

4.4 漏洞场景无法访问或空白

登录系统后，你可能会发现左侧漏洞菜单里，有些分类下的子项点击后没反应，或者页面是空白的。

原因分析：

功能尚未实现：这是最可能的原因。开源项目是逐步完善的，作者（whgojp）在Wiki中也提到，一些漏洞类型（如Hibernate、JPA注入）可能因为“优先级不高”或“漏洞场景不好写”而暂时搁置。点击这些链接，相当于访问了一个尚未开发完成的控制器或页面。
前端路由问题：极小概率是前端路由配置没有对应上。

如何应对：

查看项目Issue和PR：去GitHub仓库的Issues和Pull Requests页面看看，有没有其他人在讨论或贡献这个漏洞场景。这是了解项目开发进度的最佳方式。
自己动手，丰衣足食：JavaSecLab作为一个开源学习项目，非常欢迎贡献。如果你对某个漏洞场景有研究，完全可以尝试自己实现它，然后向原作者提交Pull Request。这不仅是帮助项目，也是对你个人能力的极大锻炼。你可以参考已有漏洞场景的代码结构，在src/main/java下找到对应的控制器和页面进行模仿开发。
专注于已实现的场景：对于学习者来说，项目里已经实现的几十个漏洞场景（如基本的SQL注入、XSS、文件上传、命令执行、反序列化等）已经构成了一个非常丰富的学习体系。先把这些搞懂、练熟，价值已经非常大。

5. 进阶使用与学习路径指南

成功部署只是第一步，如何高效利用JavaSecLab进行学习才是关键。这里分享我总结的一套使用方法和学习路径。

5.1 漏洞利用与代码审计实战

JavaSecLab每个漏洞点都设计了“漏洞”和“安全”两种模式，这是它最精华的部分。

标准学习流程：

定位漏洞：在Web界面找到目标漏洞点，例如“SQL注入 -> 数字型注入”。
黑盒测试：先不看代码，像渗透测试一样，尝试通过输入各种Payload（如1' OR '1'='1）来触发漏洞，观察页面的回显或行为变化。理解漏洞的表现形式。
查看漏洞代码：点击页面上的“查看漏洞代码”或类似按钮（通常在漏洞演示区域附近）。这会直接跳转到GitHub上对应的源代码文件，并高亮显示存在问题的代码行。例如，你会看到一段使用字符串拼接来构造SQL语句的PreparedStatement。
分析根源：仔细阅读高亮的代码，理解为什么这里会产生漏洞。是未过滤的用户输入？是不安全的API调用？还是错误的逻辑判断？
查看修复代码：再点击“查看安全代码”，对比修复后的版本。看作者是如何修复的——是使用了参数化查询（PreparedStatement），还是进行了严格的输入校验和过滤？思考这种修复方式的原理和优缺点。
本地调试：如果你用的是IDEA本地部署，可以在漏洞代码处打上断点，重新触发漏洞，观察程序执行时变量的变化过程，深入理解数据流和漏洞触发链。

以“SQL注入-数字型注入”为例：

漏洞代码：可能是String sql = "SELECT * FROM users WHERE id = " + request.getParameter("id");然后直接stmt.executeQuery(sql)。
安全代码：会变成String sql = "SELECT * FROM users WHERE id = ?";然后preparedStatement.setInt(1, id);。
你的任务：不仅要看懂这个区别，更要理解为什么字符串拼接会导致注入，而参数化查询能防止注入。可以尝试在安全代码处，故意传入一个非数字的参数，看看程序是如何处理的（抛出异常？还是返回空结果？）。

5.2 集成到安全开发流程

JavaSecLab不仅是个人的学习工具，也可以作为团队安全能力建设的平台。

新员工安全入职培训：为新入职的Java开发工程师部署一套JavaSecLab，要求他们在第一周内完成指定漏洞场景的学习和利用报告。这比单纯的理论培训效果要好得多。
安全代码评审训练：在团队内部组织“代码审计小竞赛”。选取JavaSecLab中的几个漏洞场景，隐藏漏洞位置，让开发人员在一定时间内找出代码中的安全问题并给出修复建议。这能有效提升团队对安全漏洞的敏感度。
自动化安全测试用例参考：JavaSecLab的每个漏洞点，本质上都是一个可复现的测试用例。你可以参考这些用例，为你自己的项目编写类似的自动化安全测试脚本（例如，使用OWASP ZAP的主动扫描规则，或编写专门的单元测试/集成测试）。

5.3 自定义与扩展

当你对现有漏洞了如指掌后，可以尝试更进阶的玩法：

添加新的漏洞场景：这是对个人能力提升最大的方式。比如，你最近研究了一个新的Apache Commons Collections反序列化利用链（Gadget），或者一个Fastjson的特定版本漏洞。你可以仿照现有模块的结构，在项目中新建一个Controller、Service和前端页面，实现这个漏洞的演示环境。这个过程会让你对漏洞的细节、Spring MVC框架、以及前后端交互有更深的理解。
修改漏洞难度：默认的漏洞利用可能比较简单。你可以尝试增加WAF（Web应用防火墙）规则，或者加入一些基础的过滤机制，然后挑战自己或团队成员如何绕过。例如，在文件上传漏洞中，除了后缀名黑名单，再加入文件内容头检查，然后思考如何制作一个包含恶意代码的图片马（ImageMagick漏洞）来绕过。
搭建内网靶场集群：使用Docker Compose可以轻松定义多个服务。你可以尝试修改配置，将JavaSecLab与一些其他的漏洞环境（比如一个古老的Struts2应用、一个存在未授权访问的Redis）组合在一起，模拟一个简单的内网环境，进行横向移动等综合渗透测试练习。

6. 维护、更新与故障恢复

一个长期运行的环境，总需要一些维护技巧。

更新到最新版本：

如果使用Git克隆的源码，进入项目目录，执行git pull拉取最新代码。
然后根据你的部署方式选择：
- 本地部署：直接在IDEA中重新运行即可。
- Docker源码构建：执行mvn clean package -DskipTests重新打包，然后docker-compose down和docker-compose up -d --build。--build参数强制Docker重新构建镜像。
- 公共镜像：执行docker-compose -f docker-compose.image.yml down然后docker-compose -f docker-compose.image.yml pull拉取最新镜像，最后docker-compose -f docker-compose.image.yml up -d。

数据备份与迁移：你的所有操作记录、添加的用户等数据都保存在MySQL数据库中。如果需要备份或迁移整个环境：

使用docker exec导出数据库：

docker exec <数据库容器名> mysqldump -u root -pQWE123qwe JavaSecLab > javaseclab_backup.sql

备份整个项目目录（包含源码、配置、docker-compose文件）。
在新环境部署好JavaSecLab并启动数据库后，将备份的SQL文件导入即可。

日常清理：Docker运行久了会产生很多停止的容器、未使用的镜像和网络，占用磁盘空间。定期清理：

# 删除所有已停止的容器 docker container prune # 删除所有未被任何容器使用的镜像 docker image prune # 删除所有未被使用的网络 docker network prune # 一键清理所有未使用的资源 docker system prune -a

使用-a参数要谨慎，它会删除所有未被使用的镜像，包括一些基础镜像。

最后，遇到任何奇怪的问题，查看日志永远是第一选择。使用docker logs -f <容器名>可以实时查看应用容器的输出，大部分错误信息都会在这里找到线索。对于这个项目，多动手、多尝试、多翻代码，比任何教程都管用。安全本身就是一个攻防对抗、不断实践的技术领域，JavaSecLab给了你一个绝对安全的沙箱，放心地去“搞破坏”吧，在一次次触发漏洞和修复漏洞的过程中，你的实战能力会得到实实在在的成长。

查看全文

http://www.jsqmd.com/news/1121478/