fix(content): harden Docker practice guide

12_implementation/12.4_ufs.md

@@ -92,11 +92,11 @@ Docker 的存储驱动经历了从早期各式各样的机制（如 aufs, device
 
 | 存储后端 / 驱动 | 核心特性说明 | 推荐程度 |
 |---------|------|---------|
-| **containerd image store**| (v29.x 新一代默认后端，新装默认) 基于 containerd 的 snapshotters，原生支持 OCI image index、多架构镜像与 Attestations 构建溯源元数据存储。 | ✅**强烈推荐 (现代默认)** |
+| **containerd image store**| (v29.x 新一代默认后端，新装默认) 基于 containerd 的 snapshotters，原生支持 OCI image index、多架构镜像与 Attestations 构建溯源元数据存储；启用 `userns-remap` 时不可用。 | ✅**强烈推荐 (现代默认)** |
 | **overlay2**| (经典 Graph Driver) 传统架构下的现代 Linux 默认驱动，性能优秀，但在处理复杂溯源元数据（索引）时受限。 | ✅**推荐 (主要后备)** |
-| **aufs** | 早期默认，兼容性好 | 遗留系统 |
+| **aufs** | 早期默认，已从现代 Docker Engine 移除 | 历史资料 |
 | **btrfs**/**zfs** | 使用原生稳定文件系统快照能力 | 特定场景 |
-| **devicemapper** | 块设备级存储 | 遗留系统 (已被逐步弃用) |
+| **devicemapper** | 块设备级存储，已从现代 Docker Engine 移除 | 历史资料 |
 | **vfs** | 不使用 CoW，每层完整复制 | 仅测试 |
 
 #### Classic Graph Drivers 与 Snapshotters 的核心差异
@@ -104,7 +104,7 @@ Docker 的存储驱动经历了从早期各式各样的机制（如 aufs, device
 传统模型（如 `overlay2`）将镜像拉取解包的过程由 Docker 的 graph drivers 处理。而新的 `containerd image store` 则将这一职责彻底下放给了 `containerd` 自身的 `snapshotters`（底层在 Linux 发行版通常依然利用操作系统的 overlayfs）。这种架构改变带来了：
 
 1. 本地免拉取查看多平台镜像 index manifest 与 attestations (SBOM、Provenance)。
-2. 避免了以前绕过 CRI 获取本地镜像的问题，带来更好的原生 Kubernetes 生态兼容性。
+2. 允许 Docker 使用 containerd snapshotters 管理镜像层，便于与现代 OCI 生态能力对齐。它不表示 kubelet/containerd 会自动复用 Docker 本地镜像；Kubernetes 镜像分发仍应以 registry、镜像拉取策略和运行时配置为准。
 
 #### 查看当前存储驱动与后端
 
@@ -114,14 +114,14 @@ $ docker info | grep "Storage Driver"
 Storage Driver: overlay2
 
 ## 在 Engine v29.x 中，可以通过如下输出验证是否开启了 containerd 镜像后端：
-$ docker info | grep "containerd image store"
- containerd image store: true
+$ docker info -f '{{ .DriverStatus }}'
+[[driver-type io.containerd.snapshotter.v1]]
 ```
 ---
 
 ### 12.4.5 overlay2 工作原理
 
-overlay2 是目前最推荐的存储驱动：
+在经典 graph driver 体系下，overlay2 仍是 Linux 上的主要推荐驱动；Docker Engine 29 新安装场景默认走 containerd image store/snapshotter。
 
 ```mermaid
 flowchart TD