修复 URL 编码与澄清 containerd image store 启用条件

01_introduction/1.2_what.md

@@ -106,7 +106,7 @@ flowchart LR
 
 ### 1.2.5 Docker 的历史与生态
 
-**Docker** 最初是 `dotCloud` 公司创始人 [Solomon Hykes](https://github.com/shykes) 在法国期间发起的一个公司内部项目，于 [2013 年 3 月以 Apache 2.0 授权协议开源](https://en.wikipedia.org/wiki/Docker_(software))。
+**Docker** 最初是 `dotCloud` 公司创始人 [Solomon Hykes](https://github.com/shykes) 在法国期间发起的一个公司内部项目，于 [2013 年 3 月以 Apache 2.0 授权协议开源](https://en.wikipedia.org/wiki/Docker_%28software%29)。
 
 Docker 的发展历程：
 

01_introduction/README.md

@@ -2,7 +2,7 @@
 
 本章将带领你进入 **Docker** 的世界。
 
-> **版本提示**：本书内容及示例基于 **Docker Engine v29.x** 及以上版本。值得注意的是，自 Docker Engine v29 起，官方在全新安装场景下 **默认启用了 `containerd image store` 作为镜像存储后端**（取代了传统的经典存储引擎如 overlay2 graph driver）。这项底层革新极大增强了 Docker 对多架构镜像（Multi-platform）、以及软件供应链安全元数据（Attestations, SBOM, Provenance）的本地支持原生性。
+> **版本提示**：本书内容及示例基于 **Docker Engine v29.x** 及以上版本。值得注意的是，自 Docker Engine v29 起，官方在全新安装场景下 **默认启用 `containerd image store` 作为镜像存储后端**（取代传统 classic store 路径下的 graph driver 体系）。这项底层革新极大增强了 Docker 对多架构镜像（Multi-platform）以及软件供应链安全元数据（Attestations, SBOM, Provenance）的本地支持原生性。
 
 ## 本章内容
 

04_image/README.md

@@ -18,5 +18,5 @@ Docker 运行容器前需要本地存在对应的镜像，如果本地不存在
 
 > **版本提示：镜像存储后端的变迁**
 >
-> 在 Docker Engine v29 及后续版本中，Docker 全新安装默认启用了 **containerd image store**（替代了传统的 classic store）。这一底层架构级别的变迁，意味着 Docker 解锁了对 OCI Image Index 和 Attestations （例如原生的 provenance 来源证明与 SBOM 软件物料清单）的全量本地支持。
+> 在 Docker Engine v29 及后续版本中，Docker 在**全新安装场景**默认启用 **containerd image store**（替代传统 classic store 路径）。这一底层架构级别的变迁，意味着 Docker 解锁了对 OCI Image Index 和 Attestations（例如原生的 provenance 来源证明与 SBOM 软件物料清单）的全量本地支持。
 > 读者在执行类似 `docker buildx build --provenance=mode=min --sbom=true` 甚至使用后续审查工具（如 `docker buildx imagetools inspect`）时，其元数据能够与镜像数据一并完好地管理于本地存储系统中，为供应链安全验证补齐了最后一块拼图。

10_buildx/10.2_buildx.md

@@ -43,7 +43,7 @@ $ docker buildx build --sbom=true -t myimage .
 >
 > **正确的解决路径有两条**：
 > 1. **推送到远端仓库**：使用 `docker buildx build --sbom=true --push -t myimage:tag` 时，SBOM 会正确保存到远端仓库。远端 OCI 兼容的镜像仓库能够完整存储这些元数据。
-> 2. **启用 containerd image store**：在 Docker 守护进程中启用 `containerd image store` 特性（Docker v29+，现代 Docker Desktop 默认推荐），可以在本地查看和管理 SBOM 等 attestation 元数据。
+> 2. **启用 containerd image store**：在 Docker 守护进程中启用 `containerd image store` 特性（Docker v29+，新安装场景默认启用，Docker Desktop 上也更容易直接使用），可以在本地查看和管理 SBOM 等 attestation 元数据。
 
 ### 10.2.2 官方文档
 

10_buildx/README.md

@@ -13,4 +13,4 @@ Docker Buildx 是一个 docker CLI 插件，其扩展了 docker 命令，支持
 * [构建多种系统架构支持的 Docker 镜像](10.3_multi-arch-images.md)
 
 > **供应链安全与存储后端前瞻**：现代软件供应链中，镜像来源证明（Provenance，在 BuildKit 中默认以 `mode=min` 添加）和软件物料清单（SBOM，可通过 `--sbom=true` 显式开启）已经成为极其重要的构建产出。这些 Attestations 数据会作为 manifest 附着在 **镜像索引 (Image Index)** 上。
-> 正是基于此诉求，自 Docker Engine v29 开始默认启用的 `containerd image store` 提供对 Image Index 的完美本地支持能力，解决了传统经典存储后端（Classic Store）无法有效处理带 Attestations 镜像索引的瓶颈。这使得你可以利用 `docker buildx imagetools inspect` 等手段，甚至做到无需拉取完整镜像内容即可在 Registry 或本地高效校验镜像的安全元数据。
+> 正是基于此诉求，自 Docker Engine v29 起在**新安装场景**默认启用的 `containerd image store` 提供对 Image Index 的完美本地支持能力，解决了传统经典存储后端（Classic Store）无法有效处理带 Attestations 镜像索引的瓶颈。这使得你可以利用 `docker buildx imagetools inspect` 等手段，甚至做到无需拉取完整镜像内容即可在 Registry 或本地高效校验镜像的安全元数据。

12_implementation/12.1_arch.md

@@ -98,7 +98,7 @@ flowchart TD
 
 从 Docker Engine v29 (2025) 开始，架构进一步简化和标准化：
 
-- **Containerd 镜像存储 (Image Store)**：默认启用。Docker 直接使用 Containerd 的镜像管理能力，不再维护自己的一套 graphdriver。
+- **Containerd 镜像存储 (Image Store)**：在 v29+ 的新安装场景中默认启用。Docker 直接使用 Containerd 的镜像管理能力，不再维护自己的一套 graphdriver。
   - **优势**：多平台镜像支持更好、镜像拉取更快 (lazy pulling)、与 K8s 共享镜像。
 
 ---

12_implementation/12.4_ufs.md

@@ -88,11 +88,11 @@ flowchart LR
 
 ### 12.4.4 Docker 支持的存储驱动
 
-Docker 的存储驱动经历了从早期各式各样的机制（如 aufs, devicemapper），到被广泛使用的现代经典 graph driver (`overlay2`)，再到当下（Engine v29 及以后）**默认启用的 containerd 镜像存储引擎（containerd image store）** 的演进。
+Docker 的存储驱动经历了从早期各式各样的机制（如 aufs, devicemapper），到被广泛使用的现代经典 graph driver (`overlay2`)，再到当下（Engine v29 及以后）**在新安装场景中默认启用的 containerd 镜像存储引擎（containerd image store）** 的演进。
 
 | 存储后端 / 驱动 | 核心特性说明 | 推荐程度 |
 |---------|------|---------|
-| **containerd image store**| (v29+ 新一代默认引擎) 基于 containerd 的 snapshotters，原生支持 OCI image index、多架构镜像与 Attestations 构建溯源元数据存储。 | ✅**强烈推荐 (现代默认)** |
+| **containerd image store**| (v29+ 新一代默认后端，新装默认) 基于 containerd 的 snapshotters，原生支持 OCI image index、多架构镜像与 Attestations 构建溯源元数据存储。 | ✅**强烈推荐 (现代默认)** |
 | **overlay2**| (经典 Graph Driver) 传统架构下的现代 Linux 默认驱动，性能优秀，但在处理复杂溯源元数据（索引）时受限。 | ✅**推荐 (主要后备)** |
 | **aufs** | 早期默认，兼容性好 | 遗留系统 |
 | **btrfs**/**zfs** | 使用原生稳定文件系统快照能力 | 特定场景 |