现代docker不再直接依赖lxc，而是通过libcontainer、runc和containerd实现容器运行时；早期（2013年前后）docker基于lxc提供隔离能力，后为解耦与跨平台演进，逐步构建原生运行时并推动oci标准，如今lxc仅作为可选后端存在。
现代 Docker 并不直接依赖 LXC 作为运行时，但 LXC 确实是 Docker 早期架构的关键基石。理解这个演变过程，关键在于看清技术分层：LXC 提供了底层隔离能力，而 Docker 在其之上构建了标准化、可移植、易用的容器生态。
LXC 是 Docker 的底层能力提供者（2013年前后）
早期 Docker（0.x 版本）直接调用 LXC 工具链（如 lxc-start）来创建和管理容器。它利用 LXC 封装的 Linux 内核特性——主要是 Namespaces（进程、网络、挂载、用户等隔离）和 cgroups（资源限制与统计）——实现进程沙盒化。此时的 Docker 更像一个“LXC 的友好前端”，解决了 LXC 配置复杂、模板难统一、镜像不可移植等问题。
- LXC 负责“能不能隔离”：提供内核级的容器运行基础
- Docker 负责“好不好用”：引入镜像分层、Dockerfile 构建、仓库分发、统一 CLI 等
- 用户无需手动写 LXC 配置文件，只需
docker run即可启动一个预打包环境
从 LXC 到 libcontainer：Docker 主动解耦（2014–2016）
随着需求增长，Docker 团队发现直接依赖 LXC 工具存在局限：版本绑定紧、功能扩展受限、对 Windows/macOS 支持困难。于是，Docker 开发了纯 Go 编写的原生运行时 —— libcontainer（后成为 containerd 的核心组件）。它绕过 LXC 用户态工具，直接调用内核接口实现 Namespaces 和 cgroups 管理。
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- libcontainer 不再需要
lxc-*命令或 LXC 模板 - 容器生命周期由 Docker daemon 直接控制，更轻量、更可控
- 此举为跨平台（如通过 Hyper-V 或 WSL2 运行 Linux 容器）打下基础
OCI 标准与 containerd：彻底脱离 LXC 依赖（2017 年至今）
Docker 将 libcontainer 贡献给 CNCF，并推动成立 Open Container Initiative（OCI），制定 runc（符合 OCI 规范的命令行容器运行时）和 containerd（工业级容器守护进程）标准。如今，Docker Engine 本身已演变为一个围绕 containerd 构建的封装层。
- 默认运行时是
runc，不是 LXC；LXC 仅作为可选后端存在（需显式配置） - 用户可通过
dockerd --default-runtime=lxc手动启用 LXC 运行时，但极少使用 - LXC 项目仍在独立演进（如 LXD），定位是“系统容器”（类似轻量 VM），而 Docker 定位是“应用容器”
今天的 LXC 和 Docker 各自定位清晰
两者已不再是“父子关系”，而是同源异途的协作生态：
- LXC/LXD：适合需要完整 init 系统、多服务、类虚拟机体验的场景（如替代传统 VM 运行桌面或服务器 OS）
- Docker + OCI 生态：专注单进程、有明确入口点、可编排、可镜像化的应用交付，强调构建-分发-运行闭环
- 它们共享同一套内核机制（Namespaces + cgroups），但抽象层级、设计目标和用户界面完全不同
