企业官网建设流程全解析

1. 项目概述：为什么我们需要一个“一键式”集成测试环境？

在软件开发，尤其是后端服务开发中，集成测试是保证多个组件协同工作正常的关键环节。想象一下，你正在开发一个用户下单服务，它需要连接MySQL数据库来存储订单、连接Redis来缓存商品库存、连接RabbitMQ来处理异步的订单状态更新。每次你修改了代码，想跑一遍集成测试来验证整个流程，都需要做哪些事？手动启动本地的MySQL、Redis、RabbitMQ服务，配置好连接信息，运行测试，最后再手动清理测试数据，甚至关闭服务。这个过程繁琐、耗时，并且难以保证环境的一致性——你的本地数据库版本可能和CI服务器上的不一样，导致测试结果飘忽不定。

“Docker Compose + Testcontainers 集成测试环境”这个组合拳，就是为了彻底解决这个问题。它的核心目标，就是实现数据库、缓存、消息队列等外部依赖的“一键启动、随用随弃”。Docker Compose负责定义和编排这些服务容器，而Testcontainers则是一个强大的测试库，它能在你的测试代码中，以编程的方式启动、管理和清理这些由Docker Compose定义的服务栈。最终的效果是：开发者只需一条测试命令，一个完整的、隔离的、与生产环境拓扑一致的测试环境就会自动准备就绪，测试结束后自动销毁，不留任何痕迹。这不仅提升了开发体验，更是实现可靠CI/CD流水线的基石。

2. 核心工具选型与设计思路拆解

2.1 为什么是Docker Compose + Testcontainers，而不是别的？

市面上管理测试依赖的方案不少，但这个组合有其独特的优势。我们逐一分析常见的替代方案，就能明白为什么它是当前的最佳实践之一。

方案一：使用内存数据库（如H2）和模拟器（如Mockito）。这是最轻量级的方案。对于简单的、逻辑不复杂的场景，比如只测试数据库CRUD，H2兼容模式可能够用。但它的局限性非常明显：H2与MySQL、PostgreSQL在语法、函数、尤其是高级特性（如窗口函数、特定索引行为）上存在差异。Redis和MQ更是无法用内存数据库模拟。Mockito等模拟框架只能验证代码调用逻辑，无法验证真实的网络通信、序列化/反序列化、连接池行为等。结论：此方案适合单元测试，无法满足真正的集成测试需求。

方案二：维护一个共享的测试环境服务器。团队维护一台专用的测试服务器，上面常驻MySQL、Redis等服务。所有开发者和CI都连接它。这听起来省事，实则问题重重：测试并行运行时会相互干扰，数据污染严重；环境难以版本化，升级数据库版本可能影响所有测试；网络依赖性强，离线无法工作。结论：此方案是集成测试的“反模式”，应尽量避免。

方案三：使用Testcontainers直接启动单个容器。这是Testcontainers的标准用法，在测试类中通过代码定义并启动一个MySQL容器、一个Redis容器。它解决了环境隔离和一致性问题。但当依赖服务增多，且服务间有依赖关系（例如应用需要先等数据库初始化完成）时，用代码编排多个容器的启动顺序和网络连接就变得复杂。结论：此方案适合依赖服务较少的场景，多服务编排略显繁琐。

方案四：Docker Compose + Testcontainers（本项目方案）。这正是我们选择的方案。它的设计思路非常清晰：

1. 声明式环境定义：使用docker-compose.yml文件，以声明式的方式定义测试所需的所有服务（MySQL, Redis, RabbitMQ）、它们的配置、网络和依赖关系。这个文件本身就是环境的“源代码”，可以纳入版本控制，确保团队环境一致。
2. 编程式生命周期管理：在测试代码中，利用Testcontainers的DockerComposeContainer模块，加载上述YAML文件。Testcontainers会负责在测试开始时启动整个Compose栈，在测试结束后（无论成功失败）自动停止并移除所有容器、网络。生命周期与测试用例完全绑定。
3. 动态端口与连接获取：Testcontainers能动态分配主机端口，避免冲突，并能通过API在测试代码中获取到运行中容器的实际主机和端口，用于构建应用的连接字符串。

优势总结：

• 环境一致性：Docker镜像保证了环境与CI、生产环境高度一致。
• 隔离性：每个测试套件或并行任务都拥有自己独立的容器栈，互不干扰。
• 可重复性：一键创建和销毁，测试结果完全可重复。
• 开发效率：无需手动管理本地服务，简化“新同事搭建环境”的流程。
• 生产仿真度：可以模拟复杂的多服务拓扑，进行更真实的集成测试。

2.2 项目整体架构设计

一个典型的基于此方案的Java项目目录结构可能如下所示：

your-project/ ├── src/ │ ├── main/ │ └── test/ │ ├── java/ │ │ └── com/yourcompany/ │ │ └── IntegrationTest.java │ └── resources/ │ ├── docker-compose-test.yml # 测试专用的Compose文件 │ └── application-test.yml # 测试专用的Spring配置（如使用） ├── docker-compose.yml # 开发或部署用的Compose文件（可选） └── pom.xml 或 build.gradle

核心交互流程：

1. 开发者执行mvn test或gradle test。
2. 构建工具启动JUnit测试。
3. 在@BeforeAll注解的方法中，Testcontainers读取docker-compose-test.yml，通过Docker API启动容器组。
4. Testcontainers等待容器内特定服务（如MySQL的3306端口）就绪。
5. 测试代码通过Testcontainers提供的方法，获取到MySQL、Redis等服务的实际访问地址（主机和端口）。
6. 测试代码使用这些动态地址来初始化数据源、Redis客户端等，并执行测试逻辑。
7. 测试结束后，在@AfterAll注解的方法中（或由Testcontainers自动处理），所有容器被停止并移除。

3. 核心细节解析与实操要点

3.1 Docker Compose文件 (docker-compose-test.yml) 的编写艺术

这个文件是环境的蓝图。编写时不仅要能跑起来，更要考虑测试的特定需求：快速启动、数据隔离、资源控制。

version: '3.8' services: mysql-test: image: mysql:8.0.33 # 固定版本，避免因镜像更新导致测试行为变化 container_name: it-mysql # 指定容器名，便于在日志中识别 environment: MYSQL_ROOT_PASSWORD: testroot MYSQL_DATABASE: testdb MYSQL_USER: testuser MYSQL_PASSWORD: testpass ports: - "3306" # 映射到宿主机随机端口，由Testcontainers管理 healthcheck: # 关键！定义健康检查，Testcontainers依此判断服务是否就绪 test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-p$$MYSQL_ROOT_PASSWORD"] interval: 2s timeout: 5s retries: 10 command: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_unicode_ci - --default-authentication-plugin=mysql_native_password # 兼容老客户端 tmpfs: /var/lib/mysql # 重要技巧！使用内存tmpfs，极大提升I/O速度，测试完数据即消失 redis-test: image: redis:7-alpine # 使用Alpine版本，体积小，启动快 container_name: it-redis ports: - "6379" healthcheck: test: ["CMD", "redis-cli", "--raw", "incr", "ping"] # 执行一个简单命令检查 interval: 1s timeout: 3s retries: 5 rabbitmq-test: image: rabbitmq:3-management-alpine # 带管理界面的版本，便于必要时调试 container_name: it-rabbitmq environment: RABBITMQ_DEFAULT_USER: guest RABBITMQ_DEFAULT_PASS: guest ports: - "5672" # AMQP端口 - "15672" # 管理界面端口 healthcheck: test: ["CMD", "rabbitmq-diagnostics", "-q", "ping"] # RabbitMQ专用的健康检查命令 interval: 2s timeout: 5s retries: 10 networks: default: name: it-network # 指定网络名，使容器可通过服务名互相访问（如mysql-test）

编写要点与避坑指南：

1. 镜像版本固定：务必使用完整的镜像标签（如mysql:8.0.33），而非mysql:latest。后者会导致测试环境随时间不可预测地变化，破坏可重复性。
2. 健康检查(Healthcheck)是必须的：这是Testcontainers判断“服务何时真正可用”的核心机制。没有健康检查，Testcontainers可能只在端口打开时就认为服务就绪，而此时数据库可能还在初始化表中，导致测试连接失败。务必为每个服务配置合适的健康检查命令。
3. 使用tmpfs加速数据库：对于测试，数据持久化不是需求，而是负担。为MySQL/PostgreSQL的数据目录挂载tmpfs，可以将磁盘I/O变为内存操作，测试启动速度可能有数量级的提升。这是提升测试体验的关键技巧。
4. 端口映射：通常只写端口号（如- "3306"），让Docker分配随机宿主机端口，避免与本地已有服务冲突。Testcontainers会负责获取这个随机端口并告知测试代码。
5. 网络命名：给网络指定一个明确的名称（如it-network），有助于在复杂的多项目环境中隔离测试网络，也方便使用Docker命令手动调试。

3.2 Testcontainers 模块的选择与集成

Testcontainers针对不同语言和技术栈有多个模块。对于Java项目，我们主要关注：

• testcontainers：核心库。
• testcontainers-junit-jupiter：与JUnit 5集成的模块，提供了便捷的注解支持。
• testcontainers-mysql,testcontainers-redis等：针对特定数据库的便捷模块，但当我们使用Compose时，通常不需要这些，核心是testcontainers本身对Compose的支持。

在Maven的pom.xml中，添加如下依赖：

<dependency> <groupId>org.testcontainers</groupId> <artifactId>testcontainers</artifactId> <version>1.19.3</version> <!-- 请使用最新稳定版 --> <scope>test</scope> </dependency> <dependency> <groupId>org.testcontainers</groupId> <artifactId>junit-jupiter</artifactId> <version>1.19.3</version> <scope>test</scope> </dependency>

注意：Testcontainers需要本地安装Docker并确保Docker守护进程正在运行。在CI环境中（如GitHub Actions, GitLab CI），需要确保运行器具有Docker执行权限，通常需要安装docker-in-docker(dind) 或使用支持Docker的托管运行器。

4. 实操过程与核心环节实现

4.1 编写集成测试基类

为了在所有集成测试中复用环境启动逻辑，最佳实践是创建一个抽象的测试基类。

package com.yourcompany; import org.junit.jupiter.api.AfterAll; import org.junit.jupiter.api.BeforeAll; import org.testcontainers.containers.DockerComposeContainer; import org.testcontainers.containers.wait.strategy.Wait; import java.io.File; import java.time.Duration; public abstract class BaseIntegrationTest { // 定义DockerComposeContainer实例，使用资源路径下的compose文件 protected static final DockerComposeContainer<?> COMPOSE_CONTAINER = new DockerComposeContainer<>(new File("src/test/resources/docker-compose-test.yml")) .withExposedService("mysql-test", 3306, Wait.forHealthcheck().withStartupTimeout(Duration.ofMinutes(2))) .withExposedService("redis-test", 6379, Wait.forHealthcheck().withStartupTimeout(Duration.ofSeconds(30))) .withExposedService("rabbitmq-test", 5672, Wait.forHealthcheck().withStartupTimeout(Duration.ofSeconds(60))) .withLocalCompose(true); // 使用本地docker-compose命令 @BeforeAll static void beforeAll() { COMPOSE_CONTAINER.start(); // 这里可以添加一些全局的初始化逻辑，例如获取动态端口并设置系统属性 initSystemProperties(); } @AfterAll static void afterAll() { // Testcontainers 通常会自动清理，但显式调用 stop 是良好的实践 if (COMPOSE_CONTAINER != null && COMPOSE_CONTAINER.isRunning()) { COMPOSE_CONTAINER.stop(); } } private static void initSystemProperties() { // 获取MySQL服务的主机和映射后的端口 String mysqlHost = COMPOSE_CONTAINER.getServiceHost("mysql-test", 3306); Integer mysqlPort = COMPOSE_CONTAINER.getServicePort("mysql-test", 3306); // 获取Redis服务的主机和端口 String redisHost = COMPOSE_CONTAINER.getServiceHost("redis-test", 6379); Integer redisPort = COMPOSE_CONTAINER.getServicePort("redis-test", 6379); // 将动态连接信息设置为系统属性，供应用配置文件（如application-test.yml）读取 System.setProperty("test.mysql.host", mysqlHost); System.setProperty("test.mysql.port", String.valueOf(mysqlPort)); System.setProperty("test.redis.host", redisHost); System.setProperty("test.redis.port", String.valueOf(redisPort)); // 同理可以设置RabbitMQ等 String rabbitmqHost = COMPOSE_CONTAINER.getServiceHost("rabbitmq-test", 5672); Integer rabbitmqPort = COMPOSE_CONTAINER.getServicePort("rabbitmq-test", 5672); System.setProperty("test.rabbitmq.host", rabbitmqHost); System.setProperty("test.rabbitmq.port", String.valueOf(rabbitmqPort)); } // 提供便捷方法给子类使用 protected static String getMysqlJdbcUrl() { String host = System.getProperty("test.mysql.host"); String port = System.getProperty("test.mysql.port"); return String.format("jdbc:mysql://%s:%s/testdb?useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=UTC", host, port); } protected static String getMysqlUsername() { return "testuser"; } protected static String getMysqlPassword() { return "testpass"; } protected static String getRedisHost() { return System.getProperty("test.redis.host"); } protected static Integer getRedisPort() { return Integer.parseInt(System.getProperty("test.redis.port")); } }

关键代码解析：

1. DockerComposeContainer构造：传入Compose文件的File对象。withExposedService方法告诉Testcontainers你关心哪个服务（服务名）的哪个端口，并配置等待策略。这里我们使用Wait.forHealthcheck()，它会持续检查容器的健康状态，直到通过为止，这是最可靠的方式。
2. withLocalCompose(true)：指示Testcontainers使用本地安装的docker-compose或docker compose（v2）命令来管理生命周期。这通常比Testcontainers内置的模拟实现更稳定，尤其是处理复杂的Compose文件时。
3. 动态信息获取：getServiceHost和getServicePort是核心方法。它们返回的是从宿主机（即你的测试JVM）角度访问容器服务的地址和端口。例如，mysqlPort是一个随机的高位端口（如32768），你的测试代码需要连接这个端口。
4. 系统属性传递：我们将动态获取的主机和端口设置为JVM系统属性。这样，在Spring Boot的application-test.yml配置文件中，就可以通过${test.mysql.host}这样的占位符来引用这些值，实现配置与运行时环境的解耦。

4.2 配置测试专用的应用配置文件 (application-test.yml)

如果你的项目使用Spring Boot，可以创建一个测试配置文件来覆盖生产配置，指向Testcontainers启动的服务。

# src/test/resources/application-test.yml spring: datasource: url: ${test.mysql.jdbc.url} # 这个属性需要在测试基类中设置，或直接使用基类方法构建 username: testuser password: testpass driver-class-name: com.mysql.cj.jdbc.Driver hikari: maximum-pool-size: 5 # 测试环境连接池无需过大 data: redis: host: ${test.redis.host} port: ${test.redis.port} database: 0 timeout: 2000ms rabbitmq: host: ${test.rabbitmq.host} port: ${test.rabbitmq.port} username: guest password: guest # 关闭一些非必要的生产特性，加速测试 management: endpoints: web: exposure: include: health health: db: enabled: false redis: enabled: false logging: level: org.testcontainers: INFO com.zaxxer.hikari: WARN org.springframework.jdbc.core: DEBUG # 可选，查看SQL执行

4.3 编写具体的集成测试类

现在，我们可以编写真正的集成测试了。测试类继承自BaseIntegrationTest。

package com.yourcompany.service; import com.yourcompany.BaseIntegrationTest; import org.junit.jupiter.api.Test; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.boot.test.context.SpringBootTest; import org.springframework.data.redis.core.StringRedisTemplate; import javax.sql.DataSource; import java.sql.Connection; import java.sql.Statement; import static org.assertj.core.api.Assertions.assertThat; @SpringBootTest(properties = { // 如果没通过系统属性传递，也可以在这里直接注入URL "spring.datasource.url=" + BaseIntegrationTest.getMysqlJdbcUrl(), "spring.datasource.username=" + BaseIntegrationTest.getMysqlUsername(), "spring.datasource.password=" + BaseIntegrationTest.getMysqlPassword(), "spring.data.redis.host=" + BaseIntegrationTest.getRedisHost(), "spring.data.redis.port=" + BaseIntegrationTest.getRedisPort() }) class OrderServiceIntegrationTest extends BaseIntegrationTest { @Autowired private DataSource dataSource; @Autowired private StringRedisTemplate stringRedisTemplate; @Autowired private OrderService orderService; @Test void testCreateOrder_Integration() throws Exception { // 1. 准备Redis缓存数据 stringRedisTemplate.opsForValue().set("product:1001:stock", "50"); // 2. 准备数据库表（通常使用Flyway/Liquibase，这里简单演示） try (Connection conn = dataSource.getConnection(); Statement stmt = conn.createStatement()) { stmt.execute("CREATE TABLE IF NOT EXISTS orders (id BIGINT AUTO_INCREMENT, product_id VARCHAR(255), PRIMARY KEY(id))"); stmt.execute("DELETE FROM orders"); // 清空旧数据 } // 3. 执行被测服务方法（该方法内部会操作DB和Redis） Order order = new Order(); order.setProductId("1001"); Order savedOrder = orderService.createOrder(order); // 4. 验证数据库结果 assertThat(savedOrder.getId()).isNotNull(); try (Connection conn = dataSource.getConnection(); Statement stmt = conn.createStatement(); var rs = stmt.executeQuery("SELECT COUNT(*) FROM orders WHERE product_id='1001'")) { if (rs.next()) { assertThat(rs.getInt(1)).isEqualTo(1); } } // 5. 验证Redis缓存是否被更新（例如扣减库存） String stock = stringRedisTemplate.opsForValue().get("product:1001:stock"); assertThat(stock).isEqualTo("49"); // 假设扣减了1 } }

这个测试案例展示了在一个测试方法中，如何同时与MySQL和Redis交互，验证一个业务流程。所有依赖的基础设施都在测试开始前由BaseIntegrationTest自动准备好。

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

在实际使用中，你肯定会遇到各种问题。下面是我踩过坑后总结的一些常见问题及其解决方案。

5.1 容器启动超时或健康检查失败

这是最常见的问题。现象是测试卡在启动阶段，最终超时失败。

可能原因及排查步骤：

1. Docker守护进程未运行或无权访问：首先运行docker ps命令，确认Docker可用。在CI脚本中，确保已正确安装和启动Docker，并且运行测试的用户（如github-actions）在docker用户组中。
2. 镜像拉取慢或失败：尤其是首次运行，或CI环境网络不佳时。可以考虑：
   • 使用国内镜像加速器：在Docker守护进程配置中（/etc/docker/daemon.json）配置镜像仓库镜像。
   • 在CI中预拉取镜像：在测试步骤前，添加一个步骤显式执行docker-compose -f src/test/resources/docker-compose-test.yml pull。
3. 健康检查命令不正确：这是最可能的原因。健康检查命令必须在容器内可执行并返回成功退出码。
   • 调试方法：先手动用docker-compose -f src/test/resources/docker-compose-test.yml up启动服务，然后使用docker-compose ps查看服务状态。如果健康检查一直不通过，进入容器手动执行健康检查命令：docker exec -it <container_id> bash，然后执行mysqladmin ping -h localhost -u root -ptestroot，看是否成功。根据错误调整命令。
   • MySQL常见坑：密码中的特殊字符可能需要转义。使用$$在Compose文件中引用变量是安全的。确保--default-authentication-plugin与你的客户端驱动兼容。
4. 资源不足：同时启动多个容器（尤其是数据库）可能内存不足。可以尝试在Compose文件中为容器设置资源限制，或者优化测试，减少并行度。

   services: mysql-test: # ... deploy: # 注意：`deploy` 只在Compose特定版本或Swarm模式下有效，对于普通Compose，使用`mem_limit` resources: limits: memory: 512M # 或者使用旧式语法 mem_limit: 512m

5.2 测试代码无法连接到容器服务

现象：测试在连接数据库或Redis时抛出Connection refused或Connection timeout。

排查步骤：

1. 确认获取的地址和端口正确：在@BeforeAll方法中或测试开始时，打印出getMysqlJdbcUrl()和getRedisHost():getRedisPort()的值。确认端口是高位随机端口（如32768），而不是3306/6379。牢记：测试代码（运行在宿主机JVM）连接的是容器映射到宿主机的端口，不是容器内部端口。
2. 检查防火墙/SELinux：在某些Linux发行版上，防火墙可能阻止对Docker分配的随机端口的访问。可以临时关闭防火墙测试，或配置规则允许Docker网桥流量。
3. 使用localhost还是主机名：在Mac/Windows的Docker Desktop上，通常使用localhost。在Linux上，如果Docker以rootless模式运行或网络模式不同，可能需要使用127.0.0.1或容器IP。Testcontainers的getServiceHost方法已经处理了这些差异，返回的是最合适的地址，请务必使用它提供的主机名。
4. 等待策略不足：虽然端口打开了，但服务内部可能还未完成初始化（如MySQL正在创建系统表）。这就是为什么必须使用基于健康检查的Wait.forHealthcheck()，而不是简单的Wait.forListeningPort()。

5.3 测试性能优化技巧

集成测试启动容器需要时间，以下是提升反馈速度的实战技巧：

1. 复用容器（谨慎使用）：Testcontainers支持容器复用。通过配置testcontainers.reuse.enable=true环境变量，并给容器加上org.testcontainers.reuse标签，可以在测试间复用容器。但要注意：这要求测试必须是幂等的，每个测试都要清理自己产生的数据，否则会相互污染。对于数据库，可以在每个测试方法前执行TRUNCATE或在一个独立的事务中运行测试。
2. 使用轻量级镜像：优先选择-alpine后缀的镜像（如redis:alpine,postgres:alpine），它们体积小，拉取和启动更快。
3. tmpfs挂载：如前所述，为数据库的数据目录使用tmpfs，这是提升数据库容器启动和运行速度最有效的手段之一。
4. 并行测试优化：JUnit 5支持并行测试。如果多个测试类都继承BaseIntegrationTest，它们会各自启动一套Compose环境，可能耗尽资源。可以考虑使用@TestInstance(TestInstance.Lifecycle.PER_CLASS)并结合static的容器实例，让一个测试类中的所有方法共享一个环境。或者，更高级的做法是使用Singleton模式的容器，但这需要更精细的控制。
5. 分层构建与镜像缓存：如果你需要自定义Dockerfile作为测试依赖，利用Docker缓存，将不经常变动的层（如安装基础软件）放在前面。

5.4 CI/CD 集成注意事项

在GitHub Actions、GitLab CI等环境中运行此类测试，需要额外配置：

1. 服务容器（Services） vs Docker-in-Docker (DinD)：
   • GitHub Actions：推荐使用services关键字来启动MySQL、Redis等依赖。但这相当于使用了预启动的、独立的容器，而不是由Testcontainers管理的Compose栈。你需要调整测试配置去连接这些服务（通常通过环境变量localhost:3306）。这种方式更简单，但失去了Testcontainers的编程式管理和环境拓扑定义能力。
   • DinD：在CI作业中启动一个Docker守护进程，然后你的测试代码就能像在本地一样使用Testcontainers和Docker Compose。这更强大，但配置稍复杂，且需要注意文件挂载等问题。GitHub Actions的ubuntu-latest镜像通常已安装Docker客户端，你需要启动DinD服务。

   # GitHub Actions 使用 DinD 示例 jobs: integration-test: runs-on: ubuntu-latest services: docker: image: docker:dind options: --privileged # DinD需要特权模式 steps: - uses: actions/checkout@v4 - name: Set up Docker run: | sudo groupadd docker || true sudo usermod -aG docker $USER - name: Run tests with Testcontainers run: mvn verify env: DOCKER_HOST: tcp://localhost:2375 # 指向DinD服务 TESTCONTAINERS_HOST_OVERRIDE: host.docker.internal # 解决容器间网络访问问题

2. 资源限制：CI运行器的资源（CPU、内存）可能有限。务必在Compose文件中为容器设置合理的资源限制（mem_limit,cpus），防止因内存不足导致整个CI作业失败。
3. 日志收集：测试失败时，容器日志是重要的调试信息。确保在测试配置中（或在CI脚本里）配置日志输出。Testcontainers默认会在容器停止时输出日志到标准错误。你也可以使用COMPOSE_CONTAINER.withLogConsumer(...)来定制日志消费。

通过这套组合拳，你将拥有一个强大、可靠、高效的集成测试环境。它把环境管理的复杂性从开发者和CI脚本中抽象出去，让你能更专注于测试业务逻辑本身。从手动搭建环境的泥潭中解脱出来，把时间花在更有价值的事情上，这正是现代工程实践的追求。