docker依赖dockerd守护进程管理容器，podman则无守护进程、直接调用oci运行时；docker默认需root权限，podman原生支持rootless模式，容器进程属启动用户且隔离更严格。
Docker 和 Podman 的架构核心差异，主要体现在“有没有守护进程”和“谁在管理容器进程”这两点上。
守护进程：有 vs 无
Docker 必须依赖一个长期运行的后台服务——dockerd 守护进程。所有容器创建、启动、网络配置等操作，都由 CLI 发送请求给 dockerd，再由它调用底层 runtime（如 runc）执行。一旦 dockerd 崩溃，所有容器都会停止。
Podman 则完全不依赖守护进程。每个命令（如 podman run）直接调用 OCI runtime（如 runc），容器进程就是 podman 命令自身的子进程。没有单点故障，也不需要后台常驻服务。
权限模型：root 默认 vs rootless 优先
Docker 守护进程必须以 root 身份运行，因此所有通过 Docker CLI 执行的操作，本质上都拥有系统级权限。即使用户不直接用 root 登录，也需加入 docker 用户组，间接获得高权限。
Podman 默认支持rootless 模式：普通用户无需提权即可拉取镜像、运行容器、挂载卷、配置网络。它利用 Linux user namespace 实现隔离，大幅缩小攻击面。
进程关系：父子嵌套 vs 直接父子
在 Docker 中，容器进程是 dockerd 的子进程，而 dockerd 又是系统服务（如 systemd）的子进程。这种多层嵌套增加了调试和信号传递的复杂性。
在 Podman 中，容器进程是 podman run 命令的直接子进程。进程树扁平、生命周期清晰，SIGTERM 等信号可直达容器主进程，更适合与 systemd 或脚本集成。
生态耦合：一体化 vs 模块化
Docker 把镜像构建（build）、运行（run）、编排（swarm）、分发（push/pull）全部集成在 Engine 中，形成封闭但易用的一体化链路。
Podman 将职责解耦：build 交给 Buildah，镜像签名交给 Skopeo，运行时由 Podman 自身负责。各组件专注单一任务，符合 OCI 标准，也更贴近 Kubernetes 生态（如 CRI-O）。
