diff --git a/04_image/4.7_internal.md b/04_image/4.7_internal.md
index 8394eba..2f09e6a 100644
--- a/04_image/4.7_internal.md
+++ b/04_image/4.7_internal.md
@@ -60,7 +60,7 @@ Docker 镜像的每一层都有一个唯一的 ID，这个 ID 是根据该层的
 
 Docker 使用联合文件系统 (Union FS) 与写时复制思路来实现这种分层挂载。传统的实现方式常见于 `overlay2`、`aufs`、`btrfs`、`zfs` 等存储驱动；而在 Docker Engine 29.0 及之后的全新安装中，默认镜像后端已经变为 containerd image store，它使用 snapshotter 来管理这些层。
 
-> **版本背景**：Docker Engine 29.0.0 发布于 2025 年 11 月 10 日，是一个重要版本分界点。Docker Engine 29.0 及之后的全新安装默认使用 containerd image store；从更早版本升级的 daemon 会继续使用 legacy graph driver，直到显式启用 containerd image store。Docker Desktop 4.34 及之后也默认启用 containerd image store，实际环境仍应以当前配置为准。
+> **版本背景**：Docker Engine 29.0.0 发布于 2025 年 11 月 11 日，是一个重要版本分界点。Docker Engine 29.0 及之后的全新安装默认使用 containerd image store；从更早版本升级的 daemon 会继续使用 legacy graph driver，直到显式启用 containerd image store。Docker Desktop 4.34 及之后也默认启用 containerd image store，实际环境仍应以当前配置为准。
 
 虽然底层实现细节不同，但它们都遵循上述的 **分层 + CoW** 模型；因此，无论你看到的是 `overlay2` 还是 containerd snapshotter，理解镜像层、容器层和写时复制的方式都是一样重要的。
 
diff --git a/11_compose/11.8_wordpress.md b/11_compose/11.8_wordpress.md
index 4b51432..c80755f 100644
--- a/11_compose/11.8_wordpress.md
+++ b/11_compose/11.8_wordpress.md
@@ -192,7 +192,7 @@ WordPress 支持 Redis 缓存以提高性能。
 1. 检查 `docker compose logs wordpress`
 2. 确认 `.env` 中的密码与 YAML 文件引用一致
 3. 确认 `WORDPRESS_DB_HOST` 也是 `db` (服务名)
-4. MySQL 8.0 可能需要几秒钟启动，WordPress 会自动重试，稍等片刻即可。
+4. MySQL 8.4 可能需要几秒钟启动，WordPress 会自动重试，稍等片刻即可。
 
 #### Q：无法上传大文件
 
diff --git a/12_implementation/12.1_arch.md b/12_implementation/12.1_arch.md
index 1862e4b..a92b563 100644
--- a/12_implementation/12.1_arch.md
+++ b/12_implementation/12.1_arch.md
@@ -75,7 +75,7 @@ flowchart TD
   E["退出"]
 
   U -->|1. REST API| D
-  K -->|2. gRPC| C
+  D -->|2. gRPC| C
   C -->|3. 准备镜像和 Bundle| B
   C -->|4. 启动 Shim| S
   S -->|5. 执行| R