Clarify intro chapter

01_introduction/1.3_why.md

@@ -45,9 +45,7 @@
 
 ### 1.3.2 Docker 如何解决这些问题
 
-Docker 的出现为上述问题提供了完美的解决方案。它通过 “一次构建，到处运行” 的核心理念，从根本上改变了软件交付的方式。
-
-#### 核心理念：一次构建，到处运行
+Docker 的出现为上述问题提供了系统性的解决方案。它通过 “一次构建，到处运行” 的核心理念，从根本上改变了软件交付的方式。
 
 ```mermaid
 flowchart LR
@@ -101,27 +99,27 @@ $ docker compose up
 #### 3. 资源效率
 
 Docker 容器共享宿主机内核，无需为每个应用运行完整的操作系统。以一台 64GB 内存的物理服务器为例：
-- **传统虚拟机方案**：每个虚拟机都需要运行完整的操作系统（每个额外占用如 2GB 内存），产生大量资源开销，实际可用于应用的内存可能只有约 18GB。
-- **Docker 方案**：容器直接共享宿主机系统，只需付出很少的基础开销（OS 及引擎约 4GB），即可将约 60GB 的内存全部用于实际应用。
+- **传统虚拟机方案**：每个虚拟机都需要额外运行一套完整操作系统，会带来持续的基础资源开销；随着实例数增加，可真正分配给业务进程的内存会被不断压缩。
+- **Docker 方案**：容器直接共享宿主机系统，只保留宿主机和容器引擎的基础开销，因此通常能把更多内存留给实际业务负载。
 
 ```mermaid
 flowchart TD
     subgraph VM ["传统虚拟机方案 ❌"]
         direction TB
         Server1["物理服务器 (64GB 内存)"]
-        subgraph VMs ["可用应用内存: 约 18GB"]
+        subgraph VMs ["可用应用内存: 较少"]
             direction LR
-            VM1["VM 1: 应用 1<br/>(含 2GB OS)"]
-            VM2["VM 2: 应用 2<br/>(含 2GB OS)"]
-            VM3["VM 3: 应用 3<br/>(含 2GB OS)"]
+            VM1["VM 1: 应用 1<br/>(含独立 OS 开销)"]
+            VM2["VM 2: 应用 2<br/>(含独立 OS 开销)"]
+            VM3["VM 3: 应用 3<br/>(含独立 OS 开销)"]
         end
         Server1 --- VMs
     end
 
     subgraph Docker ["Docker 方案 ✅"]
         direction TB
-        Server2["物理服务器 (64GB 内存)<br/>含约 4GB OS及引擎配置"]
-        subgraph Containers ["可用应用内存: 约 60GB"]
+        Server2["物理服务器 (64GB 内存)<br/>含宿主 OS 与引擎基础开销"]
+        subgraph Containers ["可用应用内存: 更多"]
             direction LR
             C1["容器 1: 应用 1<br/>(按需分配)"]
             C2["容器 2: 应用 2<br/>(按需分配)"]
@@ -160,7 +158,7 @@ Docker 可以在几乎任何平台上运行：
 
 #### 6. 微服务架构的基石
 
-现代微服务架构几乎都依赖容器技术。Docker 让你可以：
+现代微服务实践大量采用容器技术作为交付基础。Docker 让你可以先把每个服务标准化封装；而在更大规模场景下，通常还需要配合编排、服务发现、网络治理和可观测性体系一起落地：
 
 - **隔离服务**：每个服务运行在独立容器中，互不干扰
 - **独立扩展**：哪个服务负载高，就单独扩展哪个