diff --git a/01_introduction/1.3_why.md b/01_introduction/1.3_why.md
index 6b6f7b4..d28bd18 100644
--- a/01_introduction/1.3_why.md
+++ b/01_introduction/1.3_why.md
@@ -101,6 +101,7 @@ $ docker compose up
 #### 3. 资源效率
 
 Docker 容器共享宿主机内核，无需为每个应用运行完整的操作系统。以一台 64GB 内存的物理服务器为例：
+
 - **传统虚拟机方案**：每个虚拟机都需要运行完整的操作系统（每个额外占用如 2GB 内存），产生大量资源开销，实际可用于应用的内存可能只有约 18GB。
 - **Docker 方案**：容器直接共享宿主机系统，只需付出很少的基础开销（OS 及引擎约 4GB），即可将约 60GB 的内存全部用于实际应用。
 
diff --git a/02_basic_concept/2.2_container.md b/02_basic_concept/2.2_container.md
index 0fb11fa..8df111d 100644
--- a/02_basic_concept/2.2_container.md
+++ b/02_basic_concept/2.2_container.md
@@ -27,6 +27,7 @@ flowchart TD
     end
 ```
 这种隔离主要通过 Linux 内核的 **Namespace** 实现，资源限制通常与 **cgroups** 配合。具体表现为：
+
 - **进程空间**：容器看不到宿主机上的其他进程。
 - **网络**：在默认网络模式下，容器通常拥有独立的网络命名空间，并可分配独立 IP；使用 `host` 或 `container:` 等模式时则例外。
 - **文件系统**：容器拥有独立的 root 目录。
diff --git a/03_install/README.md b/03_install/README.md
index 36b51af..a3dd2c3 100644
--- a/03_install/README.md
+++ b/03_install/README.md
@@ -23,6 +23,7 @@ Docker Engine 主要提供 `stable` 和 `test` 两个更新频道；`test.docker
 ### 国内用户的网络优化建议
 
 值得注意的是，国内直接访问 Docker 官方源速度较慢，建议：
+
 - **安装过程**：使用阿里云、腾讯云等国内镜像源
 - **镜像拉取**：安装完成后配置 Docker 镜像加速器（详见 [3.9 镜像加速器](3.9_mirror.md)），这一步对日常开发的体验提升最明显
 
diff --git a/06_repository/README.md b/06_repository/README.md
index 38d83a3..8677cee 100644
--- a/06_repository/README.md
+++ b/06_repository/README.md
@@ -24,6 +24,7 @@
 - 推荐使用专业级方案（Nexus 3、Harbor）而非简单的 Registry
 
 本章涵盖的方案从简到复杂：
+
 - Docker Registry：最小化部署（适合简单场景）
 - 私有仓库高级配置：添加认证、HTTPS 等生产必需项
 - Nexus 3：企业级完整解决方案，支持权限管理、备份等
diff --git a/07_dockerfile/7.2_copy.md b/07_dockerfile/7.2_copy.md
index f34598c..6b8cedb 100644
--- a/07_dockerfile/7.2_copy.md
+++ b/07_dockerfile/7.2_copy.md
@@ -5,6 +5,7 @@
 `COPY` 是在构建镜像时，将构建上下文（Dockerfile 所在目录及其子目录）中的文件或目录复制到容器内的指令。它是处理应用代码、配置文件最常用的方式。
 
 典型场景：
+
 - 复制应用源码：`COPY . /app`
 - 复制配置文件：`COPY nginx.conf /etc/nginx/nginx.conf`
 - 复制静态资源：`COPY public /app/public`
diff --git a/07_dockerfile/7.4_cmd.md b/07_dockerfile/7.4_cmd.md
index 2cfb09f..ecac261 100644
--- a/07_dockerfile/7.4_cmd.md
+++ b/07_dockerfile/7.4_cmd.md
@@ -5,6 +5,7 @@
 在深入 CMD 的细节之前，我们需要理解一个关键问题：**CMD 和 ENTRYPOINT 应该在什么时候使用？**
 
 这是 Dockerfile 使用中最常见的困惑之一。简单的答案是：
+
 - **CMD**：定义容器的”默认命令”。如果用户在 `docker run` 时提供命令，CMD 会被覆盖
 - **ENTRYPOINT**：定义容器的”入口脚本”。通常用于启动应用的某个特定部分
 
diff --git a/15_etcd/15.2_install.md b/15_etcd/15.2_install.md
index 0850e21..0f02133 100644
--- a/15_etcd/15.2_install.md
+++ b/15_etcd/15.2_install.md
@@ -13,12 +13,12 @@
 例如，使用 `curl` 工具下载压缩包，并解压。
 
 ```bash
-$ curl -L https://github.com/etcd-io/etcd/releases/download/v3.5.21/etcd-v3.5.21-linux-amd64.tar.gz -o etcd-v3.5.21-linux-amd64.tar.gz
+$ curl -L https://github.com/etcd-io/etcd/releases/download/v3.5.29/etcd-v3.5.29-linux-amd64.tar.gz -o etcd-v3.5.29-linux-amd64.tar.gz
 
 ## 国内用户可选择就近的网络加速方式（以可用镜像站为准）
 
-$ tar xzvf etcd-v3.5.21-linux-amd64.tar.gz
-$ cd etcd-v3.5.21-linux-amd64
+$ tar xzvf etcd-v3.5.29-linux-amd64.tar.gz
+$ cd etcd-v3.5.29-linux-amd64
 ```
 解压后，可以看到文件包括
 
@@ -65,8 +65,8 @@ $ docker run \
 -p 2379:2379 \
 -p 2380:2380 \
 --mount type=bind,source=/tmp/etcd-data.tmp,destination=/etcd-data \
---name etcd-gcr-v3.5.21 \
-quay.io/coreos/etcd:v3.5.21 \
+--name etcd-gcr-v3.5.29 \
+quay.io/coreos/etcd:v3.5.29 \
 /usr/local/bin/etcd \
 --name s1 \
 --data-dir /etcd-data \
diff --git a/15_etcd/15.3_cluster.md b/15_etcd/15.3_cluster.md
index 82acea4..f9ac232 100644
--- a/15_etcd/15.3_cluster.md
+++ b/15_etcd/15.3_cluster.md
@@ -8,7 +8,7 @@
 services:
 
   node1:
-    image: quay.io/coreos/etcd:v3.5.21
+    image: quay.io/coreos/etcd:v3.5.29
     volumes:
       - node1-data:/etcd-data
     expose:
@@ -40,7 +40,7 @@ services:
       - docker-etcd
 
   node2:
-    image: quay.io/coreos/etcd:v3.5.21
+    image: quay.io/coreos/etcd:v3.5.29
     volumes:
       - node2-data:/etcd-data
     networks:
@@ -72,7 +72,7 @@ services:
       - docker-etcd
 
   node3:
-    image: quay.io/coreos/etcd:v3.5.21
+    image: quay.io/coreos/etcd:v3.5.29
     volumes:
       - node3-data:/etcd-data
     networks:
diff --git a/16_cloud/16.2_tencentCloud.md b/16_cloud/16.2_tencentCloud.md
index d19e226..3ed4a7a 100644
--- a/16_cloud/16.2_tencentCloud.md
+++ b/16_cloud/16.2_tencentCloud.md
@@ -21,6 +21,7 @@
 #### 1. 创建集群
 
 登录腾讯云控制台，进入容器服务模块：
+
 - 选择 “创建集群”，配置集群名称、地域和网络
 - 选择节点配置（云服务器规格和数量）
 - 设置 Kubernetes 版本和安全组
diff --git a/16_cloud/16.3_alicloud.md b/16_cloud/16.3_alicloud.md
index 0c2ae26..f7b9a0f 100644
--- a/16_cloud/16.3_alicloud.md
+++ b/16_cloud/16.3_alicloud.md
@@ -26,6 +26,7 @@
 #### 1. 创建集群
 
 登录阿里云控制台，进入容器服务 > Kubernetes 集群：
+
 - 点击 “创建集群”，选择集群配置
 - 配置集群名称、地域、可用区和节点类型
 - 选择节点规格和数量（支持弹性伸缩）
diff --git a/17_ecosystem/17.2_coreos_install.md b/17_ecosystem/17.2_coreos_install.md
index 1fac31d..a770ebb 100644
--- a/17_ecosystem/17.2_coreos_install.md
+++ b/17_ecosystem/17.2_coreos_install.md
@@ -4,15 +4,15 @@
 
 在[下载页面](https://getfedora.org/coreos/download/) `Bare Metal & Virtualized` 标签页下载 ISO。
 
-### 17.2.2 编写 FCC
+### 17.2.2 编写 Butane 配置
 
-FCC 是 Fedora CoreOS Configuration (Fedora CoreOS 配置) 的简称。
+> **注意**：Fedora CoreOS 配置工具已从 `fcct` (Fedora CoreOS Config Transpiler) 更名为 **Butane**。新版本使用 `.bu` 扩展名和更新的 spec 版本。
 
 ```yaml
-## example.fcc
+## example.bu
 
 variant: fcos
-version: 1.0.0
+version: 1.6.0
 passwd:
   users:
     - name: core
@@ -21,10 +21,10 @@ passwd:
 ```
 将 `ssh-rsa AAAA...` 替换为自己的 SSH 公钥 (位于 `~/.ssh/id_rsa.pub`)。
 
-### 17.2.3 转换 FCC 为 Ignition
+### 17.2.3 转换 Butane 配置为 Ignition
 
 ```bash
-$ docker run -i --rm quay.io/coreos/fcct:v0.5.0 --pretty --strict < example.fcc > example.ign
+$ docker run -i --rm quay.io/coreos/butane:release --pretty --strict < example.bu > example.ign
 ```
 
 ### 17.2.4 挂载 ISO 启动虚拟机并安装
diff --git a/17_ecosystem/17.5_skopeo.md b/17_ecosystem/17.5_skopeo.md
index fcbfd00..6b5500b 100644
--- a/17_ecosystem/17.5_skopeo.md
+++ b/17_ecosystem/17.5_skopeo.md
@@ -62,6 +62,7 @@ $ skopeo copy docker://docker.io/library/alpine:latest docker://registry.example
 $ skopeo copy docker://docker.io/library/alpine:latest oci:alpine-oci
 ```
 如果我们要将本地的某个目录下的打包好的镜像再次推向 Registry 或转换为其它存储类型也是完全支持的，诸如：
+
 - `docker://` 远端 Registry
 - `docker-archive:` / `docker-daemon:` Docker 对应的归档文件或本地守护进程
 - `oci:` / `oci-archive:` OCI 相关文件格式
diff --git a/17_ecosystem/17.6_containerd.md b/17_ecosystem/17.6_containerd.md
index 53ae7d6..824f437 100644
--- a/17_ecosystem/17.6_containerd.md
+++ b/17_ecosystem/17.6_containerd.md
@@ -7,6 +7,7 @@
 [containerd](https://containerd.io/) 是一个行业标准的容器运行时，它最初是由 Docker 引擎中剥离出来的一个核心组件，后来 Docker 将其捐赠给了云原生计算基金会（CNCF），目前已经是一个 CNCF 毕业（Graduated）项目。
 
 它的主要职责是管理单个宿主机上完整的容器生命周期，包括：
+
 - 镜像的传输和存储
 - 容器执行和管理
 - 存储和网络接口的管理
@@ -40,6 +41,7 @@ Kubernetes 作为一个容器编排系统，为了屏蔽底层不同容器运行
 ### 17.6.3 为什么直接使用 containerd？
 
 对普通应用开发者来说，Docker 依然是本地开发和测试的首选。但对于构建云平台、自动化流水线或深度管理 Kubernetes 集群的系统工程师来说，直接使用 containerd 可以带来：
+
 - **更高的性能与更少的开销**：去掉了 Docker Daemon 等附加组件的资源占用，链路更短。
 - **更强的稳定性**：作为专注于运行时的底层组件，它的核心功能极为稳定且更新受控。
 - **直接符合 Kubernetes CRI 标准**：在生产级 Kubernetes 集群中作为标准配置。
diff --git a/18_security/18.2_control_group.md b/18_security/18.2_control_group.md
index 19452df..cde03f6 100644
--- a/18_security/18.2_control_group.md
+++ b/18_security/18.2_control_group.md
@@ -9,6 +9,7 @@
 默认情况下，Docker 容器对系统资源的使用是没有限制的：一个容器理论上可以使用宿主机所有的 CPU 计算能力、吃光所有的内存、耗尽所有的系统 PID。
 
 想象一下以下场景：
+
 - 一个恶意用户向你暴露在公网的应用发起海量并发请求。
 - 应用程序逻辑中存在内存泄漏漏洞。
 - 黑客在入侵容器后，在里面运行了挖矿木马程序。
diff --git a/18_security/18.3_daemon_sec.md b/18_security/18.3_daemon_sec.md
index 104ad94..6efa3f2 100644
--- a/18_security/18.3_daemon_sec.md
+++ b/18_security/18.3_daemon_sec.md
@@ -81,6 +81,7 @@ $ docker version
 在企业环境中，对 Docker 守护进程的访问控制往往不仅限于文件系统权限，还需要更细粒度的授权策略。**Authorization Plugin** 机制允许在 API 层级对请求进行拦截和审批。
 
 常见的授权插件包括：
+
 - **OPA/Conftest**：开放策略引擎，支持声明式策略定义。
 - **Prisma Cloud（Twistlock）**：商业容器安全平台。
 - 自定义脚本：根据请求内容（镜像、命令、用户等）做出允许/拒绝决定。
diff --git a/18_security/18.4_kernel_capability.md b/18_security/18.4_kernel_capability.md
index 2551703..fd877d1 100644
--- a/18_security/18.4_kernel_capability.md
+++ b/18_security/18.4_kernel_capability.md
@@ -9,12 +9,14 @@
 在默认情况下，即便一个容器是在以 `root` 用户运行，Docker 也只为其内核授予了所有可用能力中的 **一小部分“白名单”能力**。
 
 常见的 Linux Capabilities 包含：
+
 - `CAP_CHOWN`: 修改文件所有者。
 - `CAP_NET_BIND_SERVICE`: 绑定特权端口（即 1024 以下的端口）。
 - `CAP_NET_ADMIN`: 网络管理的最高权限（例如调整路由配置，设置防火墙规则等）。
 - `CAP_SYS_ADMIN`: 被誉为“Linux 内核的特权网管”，允许各种高危操作（挂载磁盘、访问敏感设备等）。
 
 为了在 **“最小特权原则”** 的指导下加强安全，Docker 默认 **移除了** 大量可能导致容器大范围破坏宿主机的能力，例如：
+
 * 完全禁止了任何通过 `CAP_SYS_ADMIN` 进行的核心挂载或设备操作。
 * 禁止修改内核模块。
 * 禁止直接访问硬件套接字。
diff --git a/18_security/18.5_other_feature.md b/18_security/18.5_other_feature.md
index f7ab6b6..4c681ed 100644
--- a/18_security/18.5_other_feature.md
+++ b/18_security/18.5_other_feature.md
@@ -43,6 +43,7 @@ chmod: /etc/passwd: Operation not permitted
 传统的 Linux 模型遵循 DAC（自主访问控制），这意味着如果一个文件被赋予了全员读写权限（`777`），普通隔离下任何人便都能修改。但 **MAC（强制访问控制）** 技术，诸如 `AppArmor` (常用于 Ubuntu/Debian) 或 `SELinux` (常用于 CentOS/RHEL)，可以制定比“文件所有权”更宏观且优先的策略控制模块。
 
 在开启了上述机制的机器上：
+
 - **AppArmor**: Docker 为所有启动的应用加载了一个默认的 `docker-default` 模板文件，如果你的某些异常写行为（比如往特殊的内核心脏目录写入配置）不在 AppArmor 许可列表之上，即使拥有物理 Root，写入同样失败。
 - **SELinux**: 所有的 Docker 操作强制附加特殊上下文标识标签。就算把主机的 `/` 绑定给了黑客的某服务，黑客对不属于 Docker 可见的标签的文件进行读写尝试亦会被阻止。
 
diff --git a/19_observability/19.1_prometheus.md b/19_observability/19.1_prometheus.md
index 6b2c81c..0b5a135 100644
--- a/19_observability/19.1_prometheus.md
+++ b/19_observability/19.1_prometheus.md
@@ -82,7 +82,7 @@ services:
       - prometheus
 
   node-exporter:
-    image: prom/node-exporter:v1.8.2
+    image: prom/node-exporter:v1.11.1
     ports:
       - "9100:9100"
     networks:
diff --git a/19_observability/19.3_performance_optimization.md b/19_observability/19.3_performance_optimization.md
index 43877c5..c6de396 100644
--- a/19_observability/19.3_performance_optimization.md
+++ b/19_observability/19.3_performance_optimization.md
@@ -122,6 +122,7 @@ networks:
     driver: bridge
 ```
 启动后访问 `http://localhost:8080` 查看：
+
 - 容器性能统计
 - 系统资源使用情况
 - 历史性能数据
@@ -176,7 +177,7 @@ services:
       - monitoring
 
   node-exporter:
-    image: prom/node-exporter:v1.8.2
+    image: prom/node-exporter:v1.11.1
     container_name: node-exporter
     ports:
       - "9100:9100"
diff --git a/appendix/learning_roadmap.md b/appendix/learning_roadmap.md
index ca91e33..1327e39 100644
--- a/appendix/learning_roadmap.md
+++ b/appendix/learning_roadmap.md
@@ -419,6 +419,7 @@ Kubernetes 进阶 (Week 24-36)
 **Docker Certified Associate (DCA)**
 
 考试信息：
+
 - 题目数：55 道
 - 时间限制：90 分钟
 - 及格分数：73%（约 41 道题）