Paused状态是容器迁移前的必要安全停顿点，通过cgroups冻结进程以保证内存和命名空间一致性，为CRIU冷迁移提供稳定快照基础，但不直接支持迁移且依赖底层兼容性。
容器处于 Paused 状态时，其所有进程被冻结（通过 cgroups freezer 控制），CPU 不执行、内存不释放、网络连接保持但无数据收发。这种状态本身 不直接支持迁移，但它常作为容器迁移前的准备步骤之一，尤其在冷迁移或一致性快照场景中起关键作用。
Paused 是迁移的“安全停顿点”
容器运行时若持续修改内存或文件系统，直接拷贝会导致状态不一致。Pause 操作能原子性地冻结所有用户态进程，确保：
- 内存页内容稳定，不会因进程写入而变化
- 挂载点、网络命名空间等内核对象保持打开但静止
- 避免迁移过程中出现竞态（如正在写日志、提交数据库事务）
注意：Pause 不能替代应用层的“优雅停止”。例如数据库容器需先执行 pg_dump 或 FLUSH TABLES WITH READ LOCK，再 Pause，否则恢复后可能损坏数据。
Pause 与 CRIU 冷迁移协同工作
Docker 原生不支持热迁移，但可通过 CRIU（Checkpoint/Restore in Userspace） 实现冷迁移，而 Pause 是其中必要前置动作：
-
checkpoint 阶段：必须先
docker pause <container></container>，再调用docker checkpoint create，否则 CRIU 会报错 “process is running” - 迁移阶段：将生成的 checkpoint 目录（含内存镜像、进程状态、文件描述符等）复制到目标主机
-
restore 阶段：在目标机运行
docker start --checkpoint <name></name>恢复，容器从 Pause 后的状态继续运行
该流程本质是“暂停 → 快照 → 复制 → 恢复”，Pause 保障了快照时刻的一致性边界。
Pause 不等于可迁移，依赖底层支持
即使容器已 Pause，迁移仍可能失败，原因包括：
- 非标准存储驱动：overlay2 支持较好；devicemapper、zfs 等对 checkpoint 兼容性差
-
特权模式或特殊挂载：使用
--privileged、--pid=host、绑定挂载 /dev 或 /proc 的容器，CRIU 往往无法完整保存上下文 -
内核版本限制：CRIU 要求源和目标主机内核版本接近（建议同一大版本，如都为 5.10.x），且开启
CONFIG_CHECKPOINT_RESTORE
可运行 criu check --all 验证当前环境是否满足迁移前提。
替代方案：Stop + Commit + Run 更通用但有延迟
若 CRIU 不可用或容器不兼容，常用替代路径是：
-
docker stop <container></container>（触发 SIGTERM + grace period） -
docker commit <container> new-image</container>（保存当前文件系统层） - 推送镜像至 registry，目标机
docker pull后docker run
这种方式不保留内存状态和网络连接，属于“应用重启式迁移”，适合无状态服务；而 Pause + CRIU 才真正实现“状态迁移”，适用于需要零中断的有状态中间件（如 Redis 主节点、Kafka broker）。
不复杂但容易忽略：Pause 是迁移链路中的控制点，不是终点；它解决的是“何时拍快照”，而能否成功迁移，取决于应用行为、存储配置和内核能力的共同配合。
