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

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 或本地高效校验镜像的安全元数据。