Created状态表示容器已初始化配置但未启动进程，仅注册元数据，无PID命名空间、零CPU占用、内存仅存几MB元数据、磁盘占用镜像层与可写层、网络默认不配置。
容器处于 Created 状态，表示镜像已成功加载并完成初始化配置，但尚未启动进程（即未执行 ENTRYPOINT 或 CMD），此时容器仅在 Docker daemon 中注册了元数据和资源配置，尚未真正运行。
Created状态的本质：隔离环境已就绪，但进程未启动
Docker 在调用 docker create（或 docker run --no-start）时，会完成以下关键动作：
- 解析镜像层，挂载只读 rootfs 并叠加可写层（如 overlay2 的 upperdir）
- 分配初始网络命名空间（默认为 none 模式，不配置网络接口）
- 设置 cgroups v1/v2 控制组路径（如
/sys/fs/cgroup/memory/docker/xxx），但此时限制值尚未生效（cgroup 资源限额仅在进程加入后才触发内核管控） - 生成容器 JSON 配置（
/var/lib/docker/containers/<id>/config.v2.json</id>），记录挂载点、端口映射、环境变量等静态信息 - 创建容器工作目录（如
/var/lib/docker/containers/<id>/</id>），但不启动任何用户进程
该状态下，容器没有 PID 命名空间主进程（init 进程），ps aux | grep 查不到对应进程，docker top 返回空，docker exec 也无法执行——因为 exec 依赖正在运行的 PID namespace。
资源是否被实际占用？内存/CPU/磁盘/网络的真实情况
Created 容器几乎不消耗运行时资源，但存在少量静态开销：
- 内存：仅占用几 MB 主机内存，用于存储容器结构体、cgroup 目录节点、挂载信息等元数据；rootfs 层文件本身不额外加载到内存（页缓存按需触发）
- CPU：零占用；无调度实体，不参与 CPU 时间片分配
-
磁盘：占用镜像层 + 可写层的磁盘空间（即
docker system df中显示的 “Local Volumes” 和 “Images” 总和），但不会因 Created 状态而新增写入 -
网络：默认不创建 veth pair、不分配 IP；若指定了
--network container:xxx或自定义网络但未启动，则仅预留网络配置项，不实际连接
注意：使用 --memory、--cpus 等参数创建容器时，Docker 会在 cgroup 中预先写入限制值，但内核不会立即施加约束——只有当容器启动、首个进程加入该 cgroup 后，资源限制才真正生效。
为什么需要 Created 状态？典型使用场景
Created 是 Docker 实现“分离构建与运行”的关键中间态，支撑多种运维与编排需求：
-
批量预创建 + 按需启动：例如在 CI 流水线中先
docker create数十个测试容器，再根据用例并发docker start，避免启动时镜像拉取/解压延迟 -
配置校验与审计：创建后检查
docker inspect输出，确认挂载路径、权限、环境变量是否符合安全策略，再决定是否启动 -
离线环境部署：在无网络节点上提前
docker load镜像并create容器，待业务就绪后一键start -
调试与恢复：容器异常退出后保持 Created 状态（如
restart: never），便于inspect分析退出前配置，或修改hostconfig.json后重启
如何验证与管理 Created 容器
常用操作与判断依据：
- 查看所有 Created 容器：
docker ps -a --filter status=created - 检查资源关联：
docker inspect <id> | jq '.HostConfig.Memory, .HostConfig.CpuCount'</id>查配置值；cat /sys/fs/cgroup/memory/docker/<id>/memory.limit_in_bytes</id>查 cgroup 文件（存在即已写入，但未激活） - 启动容器：
docker start <id></id>—— 此刻才 fork init 进程、挂载 proc/sys、加入 cgroup、触发网络配置 - 清理残留：
docker rm <id></id>可直接删除 Created 容器，释放元数据和可写层目录（注意：若挂载了外部卷，卷数据不受影响）
Created 不是故障态，而是 Docker 显式暴露的可控中间状态，理解它有助于更精准地规划资源、排查启动问题，并适配自动化流程。
