企业官网建设流程全解析

搞了十几年 Python 开发，我见过太多项目在本地跑得飞起，一到部署就翻车。环境不一致、依赖冲突、系统库缺失，这些问题几乎每个新手都会撞上。所以这次我想认真聊一聊 Python 开发里的容器化部署，从最基础的 Docker 概念讲起，用一套完整的实操案例，带你把一个 Python 项目真正打进容器、跑起来，再一步步拆解到用 Docker Compose 编排多容器服务。这篇文章不止讲命令，还会把每条命令背后的原理、每个设计的坑都摊开讲清楚，适合刚完成 Python 入门、想掌握规范部署方式的开发者，也适合被“本地能跑、服务器跑不了”折磨过的人。

几年下来我的体会是，Docker 不是部署的终点，但它是所有 Python 项目交付绕不开的起点。一个能跑通的容器化方案，比十段“能跑”的本地代码值钱得多。下面我直接把这套完整流程和经验心得写出来。

1. 为什么 Python 项目一部署就出问题，容器化到底解决了什么

1.1 本地能跑，换个环境就挂的真实原因

Python 项目的运行依赖远不止一个解释器。你的代码用到的第三方包有版本要求，底层的 C 库、系统动态链接库、环境变量、时区、字符集设置，任何一个对不上，都可能让程序启动报错。最常见的情况是：本地开发用的是 Windows，Python 3.11，依赖用 pip 装好，一切正常；到了生产服务器是 Linux，系统自带 Python 3.6，有些包的高版本装不上，或者某个依赖库需要系统的 libssl 和 libffi，而这台机器上压根没装。

这种问题本质上不是代码逻辑的问题，而是运行环境被“隐式依赖”绑死了。传统解决办法是写一大篇部署文档，让运维照着在服务器上手动装依赖、配环境。但文档永远跟不上环境差异，这也是“容器化”能解决的核心问题——把代码和它需要的完整运行环境一起打包，像搬一个已经装好所有依赖的小房间到任何服务器上，而不是搬一堆零件到现场再组装。

1.2 容器和虚拟机的区别，用一个生活类比讲清楚

虚拟机更像“整机搬迁”。它虚拟出一整套硬件设备，然后在上面跑一个完整的操作系统，占用的磁盘空间通常几个 GB 起步，启动也要等系统完整引导。容器不一样，它直接复用宿主机的操作系统内核，只隔离进程、文件系统、网络这些用户态资源。你可以把容器理解成一个个“标准集装箱”，里面装着你的应用和依赖，但集装箱之间互不干扰，并且共享下面的大船动力系统。

这个区别带来的实际收益非常直观：容器镜像可以压到几百 MB，启动时间按秒算，同一台服务器能同时跑十几个互不影响的容器，而虚拟机十几个基本就跑不动了。对 Python 开发来说，容器化的好处还有一层——它天然帮你隔离了不同项目的 Python 版本和依赖版本，再也不用为了项目 A 升个依赖导致项目 B 挂掉而头疼。

1.3 这套方案适合什么样的开发者

容器化不是大厂专属，也不是运维才需要掌握的东西。我建议以下这几类人群尽早把 Docker 用起来：

• 刚学完 Python 语法，开始写 Flask、FastAPI、Django 项目的入门者，用 Docker 可以省掉大量“为什么别人电脑能跑”的排查时间。
• 需要交付项目给同事、客户，或者需要部署到服务器的开发者，容器能保证交付物和环境彻底解耦。
• 对部署、运维有兴趣，想往后端工程化方向走的开发者，Docker 是通往 K8s、CI/CD 这些高阶技能的第一级台阶。

一个常见的误区是觉得“只有大项目才需要 Docker”。实际上，哪怕只是一个几百行的爬虫脚本，只要它依赖特定版本的 Python 和几个第三方包，容器化之后就能稳定运行在任何 Linux 服务器上，不再受系统自带 Python 版本牵制。

2. 先把本地环境搭好：Python、VSCode、Docker 一个都不能少

2.1 Python 安装的细节和版本管理思路

如果你是在 Windows 上开发，直接去 Python 官网下载安装包就行。安装时有一个非常关键的勾选项，叫做“Add Python to PATH”，很多人第一次装完，在命令行敲 python 提示无法识别，99% 就是漏了这一步。如果装的时候漏了也没关系，可以重新运行安装包选择 Modify，把 PATH 加上去。

macOS 上自带的 Python 3 版本偏旧，我不建议直接用系统自带版本，一个干净的做法是用 Homebrew 安装：brew install python@3.12。Linux 发行版则可以用系统包管理器安装，比如 Ubuntu 上执行sudo apt update && sudo apt install python3 python3-pip python3-venv。装完用python --version和pip --version验证一下，确保命令行能正常调用。

不过我更推荐你尽早接触 pyenv 这类 Python 版本管理工具。它的价值在于，你可以在同一台机器上自由切换 Python 3.8 到 3.12 的任意版本，避免某个老项目需要 Python 3.8、新项目需要 3.12 时还要折腾系统环境。思路很简单：pyenv 把不同版本的 Python 下载到用户目录，通过修改 PATH 的优先级让你选择用哪个版本。

2.2 VSCode 里配置 Python 开发环境的几个关键点

写 Python 不一定非要用 IDE，VSCode 加上两个插件就够用了。打开扩展面板，搜索安装 Python 扩展和 Pylance，这两个是微软官方出的，一个负责运行和调试，一个负责代码补全和类型检查。装好后，用Ctrl+Shift+P打开命令面板，输入Python: Select Interpreter，选择你刚装好的解释器。

有一个容易被忽略但又非常重要的配置项：format on save。在 VSCode 设置里搜format on save，开启后，每次保存文件都会自动格式化代码。Python 的代码风格非常依赖缩进，一个统一的格式化工具能帮你避免很多由缩进不一致引发的报错。

如果你要用 Docker，建议同时安装 VSCode 的 Docker 扩展。它能在编辑器的侧边栏里直接显示所有本地镜像、容器、日志，点一下就能启动或停止容器，不用每次都在命令行敲docker ps手动查看。

2.3 Docker 安装：Windows、macOS、Linux 三种环境分别怎么搞

Docker 安装最省心的是 Windows 和 macOS，官方提供的 Docker Desktop 已经打包好了 Docker 引擎、命令行工具和图形界面。Windows 用户安装前需要确保系统开启了 WSL2，这是 Windows 上跑 Linux 容器的底层支持。安装完 Docker Desktop 后，它会在系统托盘常驻，打开后如果显示绿色标识，说明 Docker 引擎正在运行。

Linux 上安装 Docker 稍微多两步。以 Ubuntu 为例，推荐用官方脚本或者手动添加 Docker 官方软件源，然后执行：

sudo apt update sudo apt install docker.io sudo systemctl enable --now docker sudo usermod -aG docker $USER

最后一行usermod会把当前用户加入 docker 用户组，这样你的普通用户账号就能直接执行 docker 命令，而不需要每次都加 sudo。执行完这条命令后需要重新登录终端才能生效。这一步很容易被人漏掉，漏掉的后果是装完 Docker 后发现每次敲命令都要 sudo，体验非常差。

安装完成后，验证 Docker 是否正常工作的标准命令是：

docker --version docker run hello-world

能输出 hello-world 里的那句 “Hello from Docker!”，说明整个链路已经通了。

2.4 镜像下载慢？先把这个基础配置做好

有没有发现，首次拉镜像的时候经常卡住，几十 MB 的文件要下载半天？这是因为 Docker Hub 的服务器在海外，国内访问很不稳定。比较通用的做法是给 Docker 配置镜像加速器，让 Docker 从国内可用的镜像仓库拉取数据。

在 Docker Desktop 的设置界面的 Docker Engine 配置项里，或者在 Linux 的/etc/docker/daemon.json文件里，加入 registry-mirrors 配置，然后重启 Docker 服务：

{ "registry-mirrors": [ "https://docker.m.daocloud.io" ] }

注意，加速器第三方维护者众多，可用性随时会变，如果发现某个地址失效，换一个有响应的公共服务即可。这也是多数开发者一开始最容易踩的坑——不是 Docker 坏了，而是镜像源配置没生效。改完配置记得重启 Docker，再用docker info查看 Registry Mirrors 一节确认配置已经加载。

3. 手写第一个 Python 容器：用 Flask 应用把整个流程跑通

3.1 项目结构怎么组织，文件和目录各自是什么角色

我们先用一个最简单的 Flask 应用来理解容器化的全流程。项目结构如下：

flask-demo/ ├── app.py ├── requirements.txt ├── Dockerfile └── .dockerignore

app.py 里放一个最小可访问的接口：

from flask import Flask app = Flask(__name__) @app.route("/") def hello(): return {"message": "hello docker"}

requirements.txt 里只需要一行：

flask==3.0.0

这里指定版本号是个好习惯。如果不指定版本，时间一长，Flask 出了新版本，你以前构建的镜像内容就会悄悄改变，以后再想复现当初的行为就难了。容器化部署最大的好处之一就是可复现，所以不要把可复现性毁在依赖版本上。

3.2 Dockerfile 每一行的作用和选择逻辑

Dockerfile 就是构建镜像的说明书。来看看这份完整的 Dockerfile 应该怎么写：

FROM python:3.12-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 5000 CMD ["python", "app.py"]

逐行拆开讲一下。

第一行FROM python:3.12-slim指定基础镜像。我们没有用 python:3.12 而是用 slim 瘦身版，是因为完整版镜像里包含了很多编译工具和文档，这些在运行时完全用不到。slim 版基于 Debian 精简而来，镜像体积小很多，下载也快。如果你对体积有更极致的追求，可以尝试FROM python:3.12-alpine，alpine 的体积更小，但有些需要编译的 Python 包在 alpine 上装起来会比较麻烦，新手阶段先用 slim 最稳。

WORKDIR /app设置容器里的工作目录。后面的命令都会在这个目录下执行，所以接下来COPY requirements.txt .是将本地的 requirements.txt 复制到容器里的 /app 目录下。

先复制 requirements，再执行 pip install，然后才复制项目代码，这个顺序是刻意的。Docker 构建镜像时有层缓存机制：每一行指令都会生成一层，如果某一层的内容没有变化，构建时就可以直接复用缓存。把依赖安装在代码之前，意味着只要 requirements.txt 没变，不管代码改多少次，pip install 那层都能命中缓存，构建速度会快非常多。

RUN pip install --no-cache-dir -r requirements.txt里的--no-cache-dir是防止 pip 把下载的安装包缓存留在镜像里，进一步控制镜像体积。

最后两行EXPOSE 5000和CMD ["python", "app.py"]分别声明容器对外提供服务的端口，以及启动容器时执行的命令。注意 CMD 用的是 JSON 数组格式，这种写法不会经过 shell 解析，直接执行，更安全。

3.3 .dockerignore：一个帮你避免低级错误的文件

和 .gitignore 的思路一样，.dockerignore 用来告诉 Docker，哪些文件不要复制进镜像。写 Python 项目时，下面这些内容应该排除：

__pycache__ *.pyc .venv venv .git .gitignore .env

为什么要排除？想象一下，如果你在本地已经创建了 .venv 虚拟环境，里面可能有几百 MB 的依赖包，如果没在 .dockerignore 里排除，执行COPY . .的时候就会把这些文件全部复制进镜像，导致镜像体积暴增，构建时间也暴涨。另一个隐患是，如果不排除 .env 文件，你的环境变量、密码、密钥就会跟着镜像一起分发出去，这是非常严重的安全漏洞。

3.4 构建镜像、启动容器的全流程演示

在 flask-demo 目录下打开终端，开始构建：

docker build -t flask-demo .

-t flask-demo给镜像起个名字，最后的句点表示使用当前目录下的 Dockerfile 进行构建。第一次构建时，Docker 会先拉取 python:3.12-slim 基础镜像，然后在它上面逐层执行指令。构建结束后，用docker images能看到本地已经存在名为 flask-demo 的镜像。

启动容器：

docker run -d -p 5000:5000 --name flask-demo-container flask-demo

这里的三个关键参数拆开看：

• -d：后台运行，容器不会独占终端。
• -p 5000:5000：端口映射，宿主机 5000 端口收到的请求转发到容器内的 5000 端口。
• --name：给容器起一个可识别的名字，方便后续管理。

启动后，打开浏览器访问http://localhost:5000，能看到接口返回的 JSON 数据，就说明容器化部署已经跑通了。

日常运维时这几个查看命令也高频使用：

docker ps # 列出正在运行的容器 docker logs flask-demo-container # 查看容器日志 docker exec -it flask-demo-container bash # 进入容器内部排查 docker stop flask-demo-container # 停止容器 docker rm flask-demo-container # 删除已停止的容器

3.5 Docker 常用命令速查表

刚接触 Docker 的人很容易被一堆命令搞懵，其实核心操作就那么几个。我把常用的整理成一张速查表，你可以保存在本地随时对照：

不要试图一次记下全部命令，先记住 build、run、ps、logs、exec 这五个，能覆盖 90% 的日常需求，其他命令用到时再查。

4. 多容器编排实战：Python 应用 + MySQL 8.0 + Redis

4.1 为什么要引入 Docker Compose

一个真实的后端项目很少只有一个 Python 进程。数据库 MySQL、缓存 Redis、可能还有消息队列，如果每个服务都手动 docker run，服务一多就失控了。你需要记住每个容器的启动参数、端口映射、网络配置，服务之间还要能互相访问。

Docker Compose 就是来解决这个问题的。它允许你用一个 YAML 文件描述整套服务，一次命令启动所有容器。服务之间通过容器名互相访问，网络隔离由 Compose 自动处理，不需要手动创建虚拟网络。这套机制非常适合本地开发环境搭建，也适合单机部署场景。

4.2 编写 docker-compose.yml 完整配置

项目的目录结构调整如下：

flask-demo/ ├── app.py ├── requirements.txt ├── Dockerfile └── docker-compose.yml

docker-compose.yml 的完整内容：

version: "3.8" services: app: build: . ports: - "5000:5000" environment: - DB_HOST=mysql - DB_USER=root - DB_PASSWORD=123456 - DB_NAME=demo - REDIS_HOST=redis depends_on: mysql: condition: service_healthy redis: condition: service_healthy mysql: image: mysql:8.0 ports: - "3306:3306" environment: - MYSQL_ROOT_PASSWORD=123456 - MYSQL_DATABASE=demo volumes: - mysql_data:/var/lib/mysql healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost"] interval: 5s timeout: 3s retries: 10 redis: image: redis:7-alpine ports: - "6379:6379" volumes: - redis_data:/data healthcheck: test: ["CMD", "redis-cli", "ping"] interval: 5s timeout: 3s retries: 10 volumes: mysql_data: redis_data:

重点解释几个关键配置。

app服务使用build: .，表示用当前目录下的 Dockerfile 构建镜像。environment里把数据库和 Redis 的连接信息通过环境变量传给应用，好处是敏感信息不写在代码里，镜像本身不包含任何与环境相关的凭据。

depends_on控制启动顺序。这里我用的是带 condition 的写法，它会让 app 服务等待 mysql 和 redis 的健康检查通过后再启动。如果不加健康检查，只写简单的 depends_on，Compose 只保证 mysql 容器先创建，但容器创建出来不代表 MySQL 已经初始化完成，应用很可能在数据库还没准备好时就去连接，然后疯狂报错。用 healthcheck 方式可以规避这个经典问题。

volumes配置是为了数据持久化。MySQL 的数据默认存在容器内部，容器一删数据就没了。通过mysql_data:/var/lib/mysql将数据目录挂载到命名卷，容器删除后数据依然保留。Redis 同理。

4.3 应用代码里怎么连接容器网络内的服务

在 docker-compose 创建的网络里，每个服务都可以用服务名作为主机名互相访问。也就是说，Python 代码里连接数据库的 host 应该直接写成mysql，而不是localhost或127.0.0.1。因为每个容器都是独立的网络命名空间，localhost 指向的是容器自身。

用 SQLAlchemy 连接 MySQL 的示例：

import os from sqlalchemy import create_engine db_host = os.getenv("DB_HOST", "localhost") db_user = os.getenv("DB_USER", "root") db_password = os.getenv("DB_PASSWORD", "") db_name = os.getenv("DB_NAME", "demo") engine = create_engine( f"mysql+pymysql://{db_user}:{db_password}@{db_host}:3306/{db_name}", pool_pre_ping=True )

connect Redis 也是同理：

import os import redis redis_client = redis.Redis( host=os.getenv("REDIS_HOST", "localhost"), port=6379, decode_responses=True )

这套环境变量的设计方式是容器应用的标准做法，叫做“12-Factor App”里的配置管理原则。把配置从代码中剥离，镜像可以原封不动地部署到开发、测试、生产任何环境，只需要修改环境变量内容。

4.4 启动整套服务，验证多容器协作

在 docker-compose.yml 所在的目录执行：

docker compose up -d --build

-d表示后台运行，--build表示每次启动前重新构建镜像。构建完成后，用docker compose ps查看所有服务状态，正常情况下三个服务的状态都是 running，healthy 表示健康检查已通过。

这时候访问http://localhost:5000，如果应用接口里写了对数据库的读写操作，只要数据能正常返回，说明 Python 应用已经成功连上了容器网络里的 MySQL 和 Redis。宿主机这边的 3306 和 6379 端口也被映射出来了，所以你也可以用 Navicat 或者 Redis Desktop Manager 直接连上去查看容器里的数据。

查看日志时，如果只想看某一个服务的日志，可以指定服务名：

docker compose logs -f app docker compose logs -f mysql

停止整套服务用：

docker compose down

注意，docker compose down默认不会删除命名卷中的数据，所以数据是安全的。如果你连数据也想清空，可以加-v参数，但要确认这是一次真正想全部重置的操作。

4.5 关于 MySQL 8.0 和 Redis 的两个常见扩展场景

有朋友问过我，网上那些“docker 安装 mysql8.0 并使用”、“docker 安装 redis 主从”到底怎么操作。这里顺带提一下。

MySQL 8.0 在容器里使用，最大的坑是认证插件。MySQL 8 默认用 caching_sha2_password 认证，而一些旧版客户端不支持这个协议。如果本地用 SQLAlchemy 连接时报Authentication plugin 'caching_sha2_password' cannot be loaded，可以考虑在 MySQL 启动参数中加入--default-authentication-plugin=mysql_native_password，或者升级客户端驱动到新版。

Redis 主从的话，本质上就是启动两个或更多 redis 容器，从节点通过 replicaof 参数指向主节点。在 Compose 文件里增加一个 redis-slave 服务，镜像仍然用 redis，只是启动命令改为：

redis-slave: image: redis:7-alpine command: redis-server --replicaof redis 6379 depends_on: - redis

注意主从复制不等于高可用，主节点挂了不会自动切换。但如果只是做读写分离、读压力分流，这套配置完全够用。

5. 部署上线，这些坑和优化点能帮你少走弯路

5.1 镜像体积优化，从 1GB 降到 200MB

镜像体积直接影响部署速度和服务器磁盘占用。一个常见的反面教材是FROM python:3.12不加任何处理，装完依赖后镜像轻松超过 1GB。做几个改动就能降到 200MB 左右。

首先，基础镜像用 slim 版。其次，用多阶段构建。多阶段构建的思路是：在第一个阶段装依赖、编译必要组件，在第二个阶段只复制最终需要的产物。以 Python 项目为例：

# 构建阶段 FROM python:3.12-slim AS builder WORKDIR /app COPY requirements.txt . RUN pip install --prefix=/install -r requirements.txt # 运行阶段 FROM python:3.12-slim WORKDIR /app COPY --from=builder /install /usr/local COPY . . CMD ["python", "app.py"]

这样运行阶段只会包含 Python、依赖库和你的代码，不会保留 pip 的缓存文件、编译器的中间产物。构建体积的优化是物理层面的，收益很直观。

5.2 环境变量、密钥和敏感信息管理

在 Dockerfile 里写死环境变量是大忌。因为镜像是可以被分发和拉取的，任何写进镜像的信息都是公开给所有拿到镜像的人。正确的做法是运行时注入环境变量。

使用 .env 文件的正确姿势：

services: app: env_file: - .env

然后在项目目录下创建 .env 文件，里面写：

DB_PASSWORD=secure_password_here API_KEY=another_secret_here

关键一步：把 .env 写进 .dockerignore 和 .gitignore，确保它不会进入镜像和代码仓库。很多人会忽略这个安全细节，一旦仓库公开，密钥就相当于泄露出去了。

5.3 容器挂了自动重启，让服务自己恢复

服务器重启或者容器进程崩溃，是部署运维里最容易遇到的问题。Docker 提供了 restart 策略来处理这种情况。在 Compose 文件里加上：

services: app: restart: unless-stopped

unless-stopped的含义是：除非管理员手动执行 docker stop，否则容器退出后会自动重启。这个策略适合绝大多数常驻服务。它是生产部署的一个基础配置，不加的话，一旦进程因为内存溢出退出，服务就只能等人来手动拉起。

5.4 常见问题与时排查速查表

新手在容器化部署阶段遇到的问题，汇总起来无非下面几种。我把常见问题和排查思路整理成一张速查表：

5.5 一组能直接照抄的排查命令

如果容器启动了但表现异常，别急着改代码。先按顺序做下面的排查：

# 1. 看容器状态 docker ps -a # 2. 看应用日志，这是最重要的信息来源 docker logs 容器名 # 3. 确认端口映射是否生效 docker port 容器名 # 4. 进入容器内部，手动执行命令测试 docker exec -it 容器名 bash # 在容器内查看进程是否存活 ps aux # 测试外部服务是否可达 curl http://mysql:3306

实际操作中，docker logs往往能直接定位 90% 的问题。比如启动崩了，日志里会显示缺少某个模块、端口被占用、或者连接超时。先看日志，再进容器排查，这是最高效的路径。

5.6 实用避坑清单

最后总结几条我从实际部署中踩出来的经验，每一条都值得记下来：

• 不要用latest标签。构建镜像时给一个固定版本号，比如flask-demo:1.0.0，方便回滚。用 latest 的话，部署时你根本不知道当前跑的是哪个版本。
• 不要把数据写进容器。容器是易失的，任何需要持久化的数据都要挂载 volume 或者写到外部存储。
• 一个容器只跑一个进程。前后端、队列、定时任务，分别拆成不同的容器，独立扩缩容和故障隔离都方便。
• 设置容器内存限制。Docker 默认不限制容器内存，一个 Python 进程内存泄漏可以把整个服务器拖垮。Compose 文件里加mem_limit: 512m，给容器加一道保险。
• 镜像里不要装没用的调试工具。每多一个工具就多一分攻击面，也多大几十 MB 体积。

6. 从容器化到工程化，下一步可以怎么走

从“能跑”到“能稳定交付”，容器化只是第一步。当你已经能用 Docker 跑通一个项目后，接下来的延伸方向大致有几个。

一个是搭建简单的 CI/CD 流水线。GitHub Actions 或 GitLab CI 里，配置好密码后，每次推代码到 main 分支，自动构建镜像并推送到私有镜像仓库。这样团队其他人拉下来就是自动构建好的最新版本，省去手动构建的步骤。这是工程化交付最直接的收益。

另一个方向是学习容器编排。Docker 解决的是单机上怎么跑容器，但生产环境往往需要多台服务器横向扩展。Kubernetes 是目前事实上的标准，它负责容器在多个节点上的调度、扩容、服务发现、故障恢复。Kubernetes 学习门槛不低，但 Docker Compose 的逻辑能帮你平滑过渡过去，因为很多概念是相通的，比如服务、容器、网络、数据卷。

还有一个容易被忽视的方向是安全。做部署久了你会意识到，环境跑通只是基础，权限控制、密钥管理、镜像漏洞扫描、基础镜像升级，这些才是真正决定一个系统能不能长期稳定运行的核心。一个没有密钥泄露风险、镜像体积小、启动快、挂掉能自愈的部署方案，比什么花哨的技术都实用。

我在实际部署项目时最大的体会是：容器化真正的价值不是“把项目跑起来”，而是“让项目的运行环境变得可描述、可复现、可版本化”。Dockerfile 本身就是环境的一份“可执行文档”，谁拿到都能构建出一样的运行环境。所以刚开始折腾 Docker 的时候，遇到问题不用慌，按日志、按命令一层层查，很快就能摸清它运作的规律。容器说到底就是一层隔离和一个进程管理系统，理解了底层逻辑，剩下的动作都是熟能生巧。

最后分享一个小技巧：在本地开发的时候，把项目代码用 volume 挂载进容器，这样你改代码后容器里的文件会同步更新，配合--reload参数，Flask 或 FastAPI 会自动重启，本地开发体验几乎和没有容器的时候一样流畅。等代码稳定了，再去构建正式镜像发布。我这些年用这个模式节省了非常多的重复构建时间。