企业官网建设流程全解析

1. 项目概述：从“跑起来”到“传出去”，为什么镜像打包是Docker真正的分水岭

你刚学会用docker run启动一个 Nginx 容器，页面能打开，日志在刷，心里一松——“Docker 我会了”。但第二天换台机器，同事问你：“这服务怎么部署？”你翻出昨天的命令，发现要手动装依赖、复制配置、改端口、调环境变量……三分钟变半小时，半小时变两小时。最后你发过去一个带七八行docker run的文本，对方照着敲还报错：“找不到 config.yml”“权限被拒绝”“/app 目录不存在”。

这就是没跨过 Docker 的真正门槛：容器是运行时的快照，而镜像是可复现、可传递、可验证的交付单元。标题里说的“将容器打包成镜像”和“使用 Dockerfile 打包镜像”，表面看是两个操作路径，实则代表两种工程思维——前者是救火式的手工快照（docker commit），后者是工业化标准的声明式构建（Dockerfile）。我带过的几十个团队里，90% 的线上故障、协作卡点、CI/CD 失败，根源都卡在这一步：把 Docker 当成高级tar用，而不是当作软件交付的契约。

这个教程不是教你怎么敲命令，而是帮你建立一套“镜像即契约”的认知体系：它必须明确回答五个问题——

• 这个镜像基于哪个操作系统和基础环境？（OS 层）
• 安装了哪些二进制、库、语言运行时？（依赖层）
• 应用代码放在哪？怎么加载？（代码层）
• 启动前要做什么初始化？（入口层）
• 运行时以什么用户、什么权限、暴露什么端口？（安全与网络层）

Dockerfile 就是这份契约的法律文本，每一行FROM、COPY、RUN都是不可抵赖的条款；而docker commit生成的镜像，就像手写一份没有公证、没有版本号、连签名都没有的便条——它可能今天能用，明天就失效，换个人就跑不通。后面所有内容，都会围绕这两个路径的真实代价、适用边界、避坑细节展开。如果你正卡在“本地能跑，上线就崩”“开发说没问题，运维说缺东西”“CI 构建总失败”这类问题上，这篇就是为你写的实战手册。

2. 核心思路拆解：手工打包 vs 声明式构建，本质是两种交付哲学

2.1 手工打包（docker commit）：适合什么场景？又埋下哪些雷？

docker commit的逻辑非常直白：你在一个正在运行的容器里，手动装好 Python、拷贝代码、改好配置、启动服务，确认一切正常后，执行：

docker commit -m "add flask app and nginx conf" -a "dev@team" container_id my-flask-app:0.1

这条命令会把当前容器的文件系统变更层（diff layer）打包成一个新的镜像。它确实快——5 分钟搞定，适合临时调试、快速验证某个补丁、或者给测试同学发一个“能跑就行”的 demo 包。

但它背后藏着三个硬伤，每个都可能在关键节点让你掉链子：

提示：docker commit生成的镜像无法追溯构建过程。你永远不知道这个镜像里到底装了几个版本的 pip、是否残留了调试用的 root 密码、有没有偷偷删掉某个关键配置文件。

第一，不可审计性。docker history my-flask-app:0.1只能看到一行"/bin/sh -c #(nop) CMD [\"python\", \"app.py\"]"，而看不到前面 20 步RUN apt-get install、COPY、sed -i是怎么一步步堆出来的。当安全扫描工具报出“该镜像含已知 OpenSSL 漏洞”，你根本没法快速定位是哪次commit引入的，只能重来。

第二，不可复现性。今天你在 Ubuntu 主机上commit，明天同事在 macOS 上用相同命令拉取镜像，结果发现/proc/sys/net/core/somaxconn路径在 macOS 宿主机上根本不存在，导致应用启动失败。因为commit捕获的是容器运行时状态，而非构建逻辑——它不保证底层 OS、内核参数、甚至 shell 版本的一致性。

第三，不可协作性。你提交了一个my-flask-app:0.1，但没人知道这个镜像对应哪次 Git 提交、哪个分支、是否包含未 push 的本地修改。CI 流水线想自动触发构建？不行，因为commit没有源码关联。运维想回滚到上个稳定版？只能靠你口头说“0.1 是周三下午三点打的”。

我见过最典型的事故：某团队用docker commit给客户交付一个数据处理服务，镜像里硬编码了开发机上的绝对路径/home/dev/data/input.csv。客户部署时挂载新目录，服务直接报错退出，排查三天才发现是镜像里RUN cp /home/dev/data/* /app/data/这一行惹的祸——而这一行，根本不在任何文档里，只存在于那个被commit的容器历史中。

2.2 声明式构建（Dockerfile）：为什么它是生产环境的唯一选择？

Dockerfile 是一个纯文本文件，用人类可读的指令描述“如何从零开始构建一个镜像”。它的核心价值不是“更高级”，而是“把构建过程变成可版本化、可审查、可自动化的一等公民”。

我们来看一个真实项目中简化后的 Flask 应用 Dockerfile：

# 1. 基础层：明确指定发行版和版本号，杜绝“latest”陷阱 FROM python:3.11-slim-bookworm # 2. 环境层：设置工作目录、非 root 用户、时区 WORKDIR /app RUN groupadd -g 1001 -f app && useradd -s /bin/bash -u 1001 -g app app ENV TZ=Asia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone # 3. 依赖层：分阶段安装系统依赖和 Python 包，利用层缓存 COPY requirements.txt . RUN apt-get update && apt-get install -y --no-install-recommends \ gcc libpq-dev && rm -rf /var/lib/apt/lists/* RUN pip install --no-cache-dir -r requirements.txt # 4. 代码层：仅 COPY 应用代码，避免误传 .git 或本地配置 COPY --chown=app:app . . # 5. 安全层：切换到非 root 用户，暴露必要端口 USER app EXPOSE 8000 HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD curl -f http://localhost:8000/health || exit 1 # 6. 入口层：定义启动命令，支持覆盖 CMD ["gunicorn", "--bind", "0.0.0.0:8000", "--workers", "2", "app:app"]

这段代码的价值，在于它把原本散落在终端里的 17 条命令，压缩成 6 个语义清晰的段落，并且每一步都可验证：

• FROM python:3.11-slim-bookworm—— 明确锁定 Python 3.11 和 Debian Bookworm，避免python:latest某天突然切到 3.12 导致兼容性问题；
• --chown=app:app—— 在COPY时直接赋权，省去后续chown命令，减少镜像层数；
• HEALTHCHECK—— 把健康检查逻辑写进镜像，Kubernetes 自动注入探针，无需额外配置；
• CMD使用数组格式 —— 防止 shell 解析歧义，确保信号能正确传递给主进程。

更重要的是，这个文件可以：

• git add Dockerfile && git commit -m "add docker build support"—— 和代码一起版本管理；
• 放进 CI 流水线，每次git push自动触发构建并推送到私有仓库；
• 用docker build --build-arg BUILD_DATE=$(date -u +'%Y-%m-%dT%H:%M:%SZ')注入构建时间，实现镜像溯源；
• 用docker scan my-flask-app:0.1扫描漏洞，报告能精准定位到apt-get install安装的libpq-dev版本。

这不是“多此一举”，而是把交付从“人肉搬运”升级为“机器可理解的契约”。当你开始写 Dockerfile，你就不再是 Docker 的使用者，而是基础设施的定义者。

2.3 两种路径的决策树：什么时候该用 commit？什么时候必须用 Dockerfile？

很多初学者纠结“到底该用哪个”，其实答案非常简单：看交付对象和生命周期。

我自己的经验是：只要这个镜像会离开你的本地终端，就必须用 Dockerfile。哪怕只是发给另一个开发同事，也值得花 10 分钟写好——因为一次省下的沟通成本，远大于写 Dockerfile 的时间。曾经有个项目，前端同学用commit打了个 Vue 镜像发给我，我本地docker run报错FATAL ERROR: Ineffective mark-compacts near heap limit。查了两小时才发现他commit前手动npm install时用了 Node 18，而基础镜像是 Node 16，V8 引擎不兼容。如果他用 Dockerfile，FROM node:16这一行就能拦住所有问题。

3. 核心细节解析：Dockerfile 每一行背后的原理与陷阱

3.1 FROM：选错基础镜像，等于从悬崖边起步

FROM是 Dockerfile 的第一行，也是最重要的决策点。它决定了整个镜像的“地基”——操作系统、包管理器、默认 shell、甚至 libc 版本。

常见错误是盲目追求“小”：看到alpine镜像只有 5MB，就FROM alpine:latest。但 Alpine 使用 musl libc，而大多数 Python 包（尤其是含 C 扩展的numpy、psycopg2）默认编译依赖 glibc。结果就是pip install失败，或运行时报ImportError: Error loading shared library。

正确的选型逻辑是三层过滤：

1. 语言生态匹配：Python 项目优先选python:<version>-slim（Debian 基础，glibc，预装 pip）；Node.js 选node:<version>-slim；Go 项目可选golang:<version>-alpine（Go 静态链接，musl 无影响）。
2. 安全与维护性：拒绝latest，必须锁定具体版本。python:3.11-slim比python:3.11-slim-bookworm少一层确定性——Bookworm 是 Debian 12 代号，明确告诉你底层 OS 版本，方便 CVE 扫描。
3. 大小与功能平衡：slim镜像比full小 300MB+，但已包含curl、wget、tar等常用工具；alpine更小但生态割裂；scratch最小（0MB），但只能放静态编译的二进制，不适合解释型语言。

实测对比（以 Python 3.11 为例）：

注意：slim镜像里pip是通过python3-pip包安装的，路径是/usr/bin/pip3，不是/usr/local/bin/pip。如果requirements.txt里有--find-links指向私有源，记得在RUN前加ENV PIP_TARGET=/tmp/pip-target，避免权限问题。

3.2 COPY vs ADD：99% 的场景，只用 COPY

Dockerfile 里最容易被滥用的指令就是ADD。官方文档说它“比 COPY 多一个自动解压功能”，但这个“多出来”的功能，恰恰是安全风险的温床。

ADD的三大隐患：

• 自动解压不可控：ADD archive.tar.gz /app/会自动解压，但解压行为取决于文件后缀，不是文件头。一个伪造的.tar.gz文件实际是 zip，解压就会失败或覆盖错误路径。
• 远程 URL 下载无校验：ADD https://example.com/app.jar /app/会下载并复制，但不校验 SHA256，中间人攻击可替换 jar 包。
• 语义模糊：ADD既可复制文件，又可解压，还可下载，违反单一职责原则。

而COPY只做一件事：安全、确定地复制文件或目录。它不猜测、不解压、不联网，所有输入都来自构建上下文（build context），可控性极强。

正确用法示范：

# ✅ 推荐：COPY 明确、安全、可预测 COPY requirements.txt . COPY --chown=app:app src/ /app/src/ COPY --from=builder /app/dist/*.js /app/static/js/ # ❌ 避免：ADD 引入不必要风险 # ADD requirements.txt . # 无意义，和 COPY 一样，但语义不清 # ADD app.tar.gz /app/ # 自动解压，路径不可控 # ADD https://github.com/xxx.zip /tmp/ # 无校验，不推荐

唯一ADD的合理场景：你需要在构建时下载一个已知 SHA256 的 tar 包，且该包必须解压。此时应配合校验：

ARG TAR_URL=https://example.com/app-v1.2.3.tar.gz ARG TAR_SHA256=sha256:abc123... ADD ${TAR_URL} /tmp/app.tar.gz RUN echo "${TAR_SHA256} /tmp/app.tar.gz" | sha256sum -c - && \ tar -xzf /tmp/app.tar.gz -C /app && \ rm /tmp/app.tar.gz

但更优解是：把这个下载步骤放到 CI 脚本里，校验后放入构建上下文，再用COPY—— 让 Dockerfile 只负责“组装”，不负责“获取”。

3.3 RUN：如何写出高效、安全、可缓存的构建命令

RUN是 Dockerfile 里最“重”的指令，它会启动一个新容器执行命令，并将结果保存为新层。它的效率和安全性，直接决定镜像构建速度和最终体积。

缓存机制：Docker 的“记忆”是怎么工作的？

Docker 构建时，会对每一层计算一个 hash（基于指令内容 + 上一层 hash）。如果某层 hash 未变，就直接复用缓存，跳过执行。例如：

RUN apt-get update && apt-get install -y curl RUN pip install flask

当你改了第二行pip install django，Docker 会发现第一行RUN apt-get...的 hash 没变，直接复用缓存层，只执行第二行。但如果把顺序颠倒：

RUN pip install flask RUN apt-get update && apt-get install -y curl

一旦requirements.txt变更，第一行RUN pip install的 hash 就变了，第二行即使没改，也会重新执行apt-get update—— 白花 30 秒。

所以黄金法则：把变化频率低的指令放前面，变化频率高的放后面。典型分层：

1. 系统依赖（apt-get install）—— 很少变，放最前；
2. 语言包（pip install -r requirements.txt）—— 中等频率，放中间；
3. 应用代码（COPY . .）—— 频繁变，放最后。

安全实践：为什么RUN pip install必须加--no-cache-dir

pip install默认会在/root/.cache/pip缓存下载的 wheel 包。这个缓存会作为镜像层的一部分被保存，导致：

• 镜像体积虚增 100MB+；
• 缓存里可能包含已知漏洞的旧包版本；
• 多次构建时，缓存可能污染新安装（pip 有时会优先用缓存而非重下载）。

正确写法：

# ✅ 强制禁用 pip 缓存，减小体积，提升确定性 RUN pip install --no-cache-dir -r requirements.txt # ✅ 如果需要加速，用 pip 的 --find-links 指向本地 wheel 目录 # COPY wheels/ /tmp/wheels/ # RUN pip install --no-cache-dir --find-links /tmp/wheels/ --trusted-host localhost -r requirements.txt

多阶段构建：如何让生产镜像小一半？

传统构建中，gcc、make、git等编译工具会留在最终镜像里，既增大体积，又引入安全风险（CVE-2023-XXXX 可能就藏在gcc里）。

多阶段构建（Multi-stage build）用FROM ... AS builder切出一个“构建阶段”，只在该阶段安装编译工具，编译完把产物COPY --from=builder到精简的运行阶段：

# 构建阶段：安装编译工具，编译前端资源 FROM node:18-slim AS frontend-builder WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY . . RUN npm run build # 运行阶段：只放编译好的静态文件和 Nginx FROM nginx:1.25-alpine COPY --from=frontend-builder /app/dist/ /usr/share/nginx/html/ COPY nginx.conf /etc/nginx/conf.d/default.conf

实测效果：一个 Vue 项目，单阶段镜像 1.2GB，多阶段后仅 28MB，且完全不含node、npm、gcc等任何构建工具。

3.4 WORKDIR、USER、EXPOSE：被严重低估的“软性规范”

这三条指令不产生文件层，却极大影响镜像的健壮性和可维护性。

• WORKDIR /app：设置默认工作目录。它比RUN cd /app && xxx强大得多——所有后续COPY、RUN、CMD都自动在此目录下执行，且容器启动后默认进入此目录。更重要的是，它让路径引用变得确定：COPY config.yml .总是相对于/app，不会因cd失败而错乱。

• USER app：这是安全基石。默认容器以root运行，一旦应用漏洞被利用，攻击者就获得宿主机 root 权限。创建非 root 用户并切换，能将危害降到最低。注意两点：

  • USER必须在COPY之后（否则COPY的文件属主是 root，USER app无法写入）；
  • 如果应用监听 80 端口（<1024），需在USER前用EXPOSE 80声明，但实际启动时用--cap-add=NET_BIND_SERVICE或改用 8000 端口。

• EXPOSE 8000：很多人以为它“开放端口”，其实它只是文档化声明——告诉使用者“这个镜像默认监听 8000”。真正开放端口靠docker run -p 8000:8000。但它有实际价值：

  • docker ps输出中会显示0.0.0.0:8000->8000/tcp，一目了然；
  • Docker Compose 里expose字段依赖它；
  • 某些网络策略工具（如 Istio）会读取EXPOSE做流量治理。

4. 实操过程：从零构建一个可落地的 Flask 镜像

4.1 项目结构准备：最小可行的构建上下文

不要把整个 Git 仓库扔进docker build。构建上下文（build context）是docker build命令指定的目录，Docker 守护进程会把它全部打包上传。如果目录里有.git、node_modules、__pycache__，不仅拖慢构建，还可能意外泄露敏感信息。

一个生产级 Flask 项目的推荐结构：

my-flask-app/ ├── Dockerfile # 构建定义 ├── requirements.txt # Python 依赖（明确版本） ├── app.py # 主应用 ├── config.py # 配置（不含密钥） ├── .dockerignore # 构建时排除的文件 ├── gunicorn.conf.py # Gunicorn 配置 └── README.md

.dockerignore是关键防线，内容必须包含：

.git .gitignore README.md __pycache__ *.pyc *.pyo *.pyd .Python .env .venv venv pip-log.txt .noseids .coverage .coverage.* nosetests.xml coverage.xml *.cover *.log .DS_Store

提示：.dockerignore语法和.gitignore完全一致。漏掉.env是高频事故——它可能含数据库密码，一旦被COPY . .进镜像，就永久留在层里，docker history都删不掉。

4.2 Dockerfile 编写：逐行详解与参数说明

我们写一个兼顾安全、性能、可观测性的 Flask Dockerfile：

# 第一部分：元信息与基础层 # VERSION: 0.1.0 # AUTHOR: dev-team # DESCRIPTION: Production-ready Flask app with Gunicorn and health check FROM python:3.11-slim-bookworm # 第二部分：构建参数（可选，用于 CI 动态注入） ARG BUILD_DATE ARG VCS_REF # 第三部分：环境与用户 LABEL org.opencontainers.image.created=$BUILD_DATE \ org.opencontainers.image.revision=$VCS_REF \ org.opencontainers.image.version="0.1.0" WORKDIR /app RUN groupadd -g 1001 -f app && useradd -s /bin/bash -u 1001 -g app app ENV PYTHONDONTWRITEBYTECODE=1 ENV PYTHONUNBUFFERED=1 ENV TZ=Asia/Shanghai RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone # 第四部分：系统依赖与 Python 包 # 更新 apt 索引，安装编译依赖（如 psycopg2 需要 libpq-dev） RUN apt-get update && apt-get install -y --no-install-recommends \ gcc libpq-dev && rm -rf /var/lib/apt/lists/* # 升级 pip 到最新稳定版，避免旧版 bug RUN pip install --no-cache-dir --upgrade pip # 安装 Python 依赖，--no-cache-dir 禁用 pip 缓存 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 第五部分：应用代码与配置 # --chown=app:app 确保文件属主正确，避免后续 USER 切换失败 COPY --chown=app:app . . # 第六部分：安全加固与运行时配置 # 切换到非 root 用户 USER app # 创建运行时目录（如果应用需要写日志） RUN mkdir -p /app/logs && chown app:app /app/logs # 声明端口和健康检查 EXPOSE 8000 HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD curl -f http://localhost:8000/health || exit 1 # 第七部分：启动命令 CMD ["gunicorn", "--config", "gunicorn.conf.py", "app:app"]

关键参数说明：

• PYTHONDONTWRITEBYTECODE=1：禁止生成.pyc文件，减小镜像体积，避免多线程时的字节码竞争问题；
• PYTHONUNBUFFERED=1：强制 stdout/stderr 不缓冲，日志实时输出，便于docker logs查看；
• --no-install-recommends：apt 安装时跳过推荐包，避免引入无关依赖（如gcc会推荐g++，但 Python 项目不需要）；
• --chown=app:app：在COPY时直接设置属主，比RUN chown少一层，更高效；
• HEALTHCHECK：Kubernetes 会自动识别并注入 liveness/readiness 探针，无需额外配置。

4.3 构建与验证：三步确认镜像可用性

第一步：本地构建（带构建参数）

# 获取当前 Git 提交哈希和时间戳 GIT_COMMIT=$(git rev-parse HEAD) BUILD_TIME=$(date -u +'%Y-%m-%dT%H:%M:%SZ') # 构建镜像，注入元数据 docker build \ --build-arg BUILD_DATE="$BUILD_TIME" \ --build-arg VCS_REF="$GIT_COMMIT" \ -t my-flask-app:0.1.0 \ . # 查看镜像信息，确认 LABEL 已注入 docker inspect my-flask-app:0.1.0 | jq '.[0].Config.Labels'

第二步：启动并测试

# 启动容器，映射端口，后台运行 docker run -d --name flask-test -p 8000:8000 my-flask-app:0.1.0 # 等待 5 秒，检查健康状态 sleep 5 docker ps --filter "name=flask-test" --format "table {{.Names}}\t{{.Status}}" # 调用健康接口 curl http://localhost:8000/health # 返回 {"status": "ok", "timestamp": "2024-05-20T10:30:00Z"} # 查看日志，确认无报错 docker logs flask-test | tail -n 20

第三步：深度验证（生产必备）

# 1. 检查镜像大小（理想值：150MB~300MB） docker images my-flask-app:0.1.0 # 2. 检查镜像层（应只有 5~7 层，避免冗余） docker history my-flask-app:0.1.0 # 3. 扫描安全漏洞（需安装 docker scan） docker scan my-flask-app:0.1.0 # 4. 检查进程用户（应为 app，非 root） docker exec flask-test ps aux | head -n 2 # 输出应类似：app 1 0.0 0.1 123456 7890 ? S 10:30 0:00 gunicorn: master # 5. 模拟信号测试（验证 CMD 数组格式是否正确） docker kill -s SIGUSR2 flask-test # 应触发 gunicorn 优雅重启，而非容器退出

4.4 推送与部署：如何让镜像真正流动起来

构建完成只是起点，镜像需要被推送、拉取、部署。这里给出最小可行的私有仓库方案（无需公网）：

搭建本地 Registry（5 分钟）

# 启动一个本地 registry 容器 docker run -d -p 5000:5000 --restart=always --name registry registry:2 # 给镜像打 tag，指向本地 registry docker tag my-flask-app:0.1.0 localhost:5000/my-flask-app:0.1.0 # 推送到本地 registry docker push localhost:5000/my-flask-app:0.1.0 # 从另一台机器拉取（需先配置 Docker daemon 信任 http registry） # 在 /etc/docker/daemon.json 加 { "insecure-registries":["localhost:5000"] }，然后 systemctl restart docker docker pull localhost:5000/my-flask-app:0.1.0

生产部署检查清单

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 “pip install 失败：ReadTimeoutError” —— 构建时网络问题的终极解法

现象：在 CI 环境或公司内网，RUN pip install -r requirements.txt随机失败，报ReadTimeoutError或ConnectionError。

原因：Docker 构建时的网络环境和宿主机不同。CI runner 可能走代理，也可能 DNS 配置异常；而pip默认超时仅 15 秒，内网 PyPI 源响应慢就直接失败。

三步解决：

1. 在 Dockerfile 中全局配置 pip：

# 在 RUN pip install 前，写入 pip 配置 RUN mkdir -p /etc/pip.conf && \ echo "[global]" > /etc/pip.conf && \ echo "index-url = https://pypi.tuna.tsinghua.edu.cn/simple/" >> /etc/pip.conf && \ echo "trusted-host = pypi.tuna.tsinghua.edu.cn" >> /etc/pip.conf && \ echo "timeout = 100" >> /etc/pip.conf && \ echo "retries = 5" >> /etc/pip.conf

2. 构建时传入额外参数（推荐）：

docker build \ --build-arg PIP_INDEX_URL="https://pypi.tuna.tsinghua.edu.cn/simple/" \ --build-arg PIP_TRUSTED_HOST="pypi.tuna.tsinghua.edu.cn" \ .

对应 Dockerfile：

ARG PIP_INDEX_URL=https://pypi.org/simple/ ARG PIP_TRUSTED_HOST=pypi.org RUN pip install --no-cache-dir --index-url $PIP_INDEX_URL --trusted-host $PIP_TRUSTED_HOST -r requirements.txt

3. 终极方案：离线 wheel 包
   在可信环境pip wheel --no-deps --wheel-dir /tmp/wheels -r requirements.txt，把/tmp/wheels目录 COPY 进构建上下文，再pip install --find-links /tmp/wheels --no-index。彻底断网，100% 可控。

5.2 “容器启动就退出：no process found” —— CMD 与 ENTRYPOINT 的生死线

现象：docker run my-app启动后立即退出，docker ps -a显示Exited (0)