Remove blank lines after code block markers

01_introduction/1.3_why.md

@@ -15,7 +15,6 @@
 │   └── 测试："这个功能在测试环境跑不起来"
 └── 开发者："不可能，在我电脑上明明能跑啊……"
 ```
-
 笔者统计过，这个问题通常由以下原因导致：
 
 - Python/Node/Java 版本不一致
@@ -34,7 +33,6 @@
 ├── Day 4：问老同事怎么配的，他也忘了
 └── Day 5：终于能跑起来了！但不知道为什么……
 ```
-
 #### 场景三：服务器迁移的恐惧
 
 ```bash
@@ -43,7 +41,6 @@
 运维："当时是一个已经离职的同事配的……"
 所有人：😱
 ```
-
 ### 1.3.2 Docker 如何解决这些问题
 
 Docker 的出现为上述问题提供了完美的解决方案。它通过 “一次构建，到处运行” 的核心理念，从根本上改变了软件交付的方式。
@@ -57,7 +54,6 @@ flowchart LR
     test -- "有问题<br/>反馈修改和更新" --> dev
     test -- "没问题<br/>发布" --> prod["生产环境"]
 ```
-
 ### 1.3.3 Docker 的核心优势
 
 除了解决上述痛点，Docker 还拥有诸多显著的技术优势，包括环境一致性、秒级启动、高效的资源利用等。
@@ -71,7 +67,6 @@ Docker 镜像包含了应用运行所需的 **一切**：代码、运行时、
 - ✅ 新人入职，一条命令就能启动开发环境
 
 ```bash
-
 ## 新同事入职第一天
 
 $ git clone https://github.com/company/project.git
@@ -81,7 +76,6 @@ $ docker compose up
 
 ...
 ```
-
 #### 2. 秒级启动
 
 传统虚拟机启动需要几分钟 (引导操作系统)，而 Docker 容器启动通常只需要 **几秒甚至几百毫秒**。
@@ -132,7 +126,6 @@ flowchart TD
         Server2 --- Containers
     end
 ```
-
 #### 4. 持续交付和部署
 
 Docker 完美契合 DevOps 的工作流程：
@@ -143,7 +136,6 @@ flowchart LR
     B --> C["自动测试<br/>(容器内运行测试)"]
     C --> D["自动部署<br/>(容器滚动更新)"]
 ```
-
 使用 [Dockerfile](../04_image/4.5_build.md) 定义镜像构建过程，使得：
 
 - 构建过程 **可重复、可追溯**
@@ -190,7 +182,6 @@ flowchart TD
         Worker --> DB
     end
 ```
-
 ### 1.3.4 Docker 不适合的场景
 
 笔者认为，技术选型要客观。Docker 并非银弹，以下场景可能不太适合：