从写下第一行代码，到它稳定跑在生产环境，中间隔着一整条工具链：版本控制、构建、IDE、操作系统、容器、持续集成。这一区讲的是这些工具「为什么这么设计、关键机制在哪、常见坑怎么绕」，目标是遇到问题能定位、能动手，而不是只会背命令。

工具链全景

一个后端工程师的日常，大致会跑过这样一条链路：

每个环节都既是「效率放大器」，也是「故障高发区」：Git 用错会丢代码，Maven 依赖冲突会让程序在运行期才炸，Docker 镜像写得不合理会让部署慢一倍，CI 没配好会把带病代码放进主干。理解原理，是为了在这些时刻能快速判断「是谁的问题」。

默认节点

注意 id 是框中显示的内容。

文本框节点

也可以在不同于 id 的框中设置文本。 如果多次这样做，它将是为将使用的节点找到的最后一个文本。 此外，如果您稍后为节点定义边，则可以省略文本定义。 渲染框时将使用先前定义的那个。

图形

This statement declares the direction of the Flowchart.

This declares the flowchart is oriented from top to bottom (TD or TB).

Compose 用一个声明式的 YAML 文件描述「一组容器」及其关系（网络、依赖、数据卷），一条 docker compose up 就能把本地开发所需的全栈依赖（数据库、缓存、消息队列、应用）拉起来。它把「记住一长串 docker run 参数」变成了「读一份进版本控制的配置」。

1. Compose 解决什么

单容器用 docker run 没问题，但一个真实服务往往要同时起应用、MySQL、Redis、Kafka，还要它们能互相访问、按顺序启动。用手敲 docker run 的问题：

Docker 用「镜像 + 容器」把应用和它依赖的运行环境打包成一个可移植的单元，从而解决「在我机器上是好的」这类环境不一致问题。理解它的核心机制——分层镜像、写时复制、命名空间与 cgroups 隔离——是写出小而快、安全可控的镜像的前提。

1. 为什么用容器

传统部署把应用直接装在服务器上，问题在于：环境漂移（开发机是 JDK 17，服务器是 8）、依赖冲突（两个服务要不同版本的库）、扩缩容慢（克隆整台机器）。虚拟机能隔离但这层太「重」——每台 VM 都带一个完整操作系统，启动以分钟计、资源开销大。

分支模型是团队协作的「交通规则」：它规定代码怎么流、谁能合、什么时候能发。选错模型不会立刻出事，代价会以「合并越来越难、主干越来越不敢发」的形式慢慢累积。

1. 分支的本质

在 Git 里，分支就是一个指向某次提交的可移动指针，.git/refs/heads/ 下只是一个存着提交哈希的小文件。创建分支是写一个 41 字节文件，切换分支是改一下 HEAD 并更新工作区——所以 Git 的分支又快又廉价，随便建、随便删。

正因为分支廉价，「分支模型」讨论的从来不是技术成本，而是协作约定：什么时候开分支、分支存活多久、如何合回主干、发布怎么打、事故怎么修。下面三种模型对应三种协作节奏。

Git 是分布式版本控制系统（Distributed Version Control System, DVCS）：每个克隆都是一份带完整历史的仓库，不依赖中央服务器也能提交、查看历史、创建分支。它真正解决的问题不是「存副本」，而是「让多人在同一份代码上并行改动、且任何一步都能回退」。

1. 为什么是 Git

初级做法是给目录加时间戳备份（code_final_v2.zip），问题很快暴露：

• 找不到「谁、在什么时间、为什么」改了某一行，无法追责与追溯。
• 两个人改同一文件只能人工合并，冲突时容易覆盖对方的修改。
• 想试验一个新方案，只能复制整个目录；试错成本高，就不敢改。
• 想回滚到「上周三能用的版本」，只能靠记忆和运气。

1.1 简介

Gradle是一个基于Apache Ant和Apache Maven概念的项目自动化构建开源工具;官网

• Gradle是一个基于JVM的构建工具
• 是一款通用灵活的构建工具
• 支持maven， Ivy仓库
• 支持传递性依赖管理，而不需要远程仓库或者是pom.xml和ivy.xml配置文件
• 基于Groovy，build脚本使用Groovy编写
• 它使用一种基于Groovy的特定领域语言(DSL)来声明项目设置
• 目前也增加了基于Kotlin语言的kotlin-based DSL，抛弃了基于XML的各种繁琐配置
• 面向Java应用为主。当前其支持的语言C++、Java、Groovy、Kotlin、Scala和Swift，计划未来将支持更多的语言
• gradle对多工程的构建支持很出色，工程依赖是gradle的第一功能
• gradle支持局部构建
• 支持多方式依赖管理：包括从maven远程仓库、nexus私服、ivy仓库以及本地文件系统的jars或者dirs
• gradle是第一个构建集成工具，与ant、maven、ivy有良好的相容相关性
• 轻松迁移：gradle适用于任何结构的工程，你可以在同一个开发平台平行构建原工程和gradle工程。通常要求写相关测试，以保证开发的插件的相似性，这种迁移可以减少破坏性，尽可能的可靠。这也是重构的最佳实践
• gradle的整体设计是以作为一种语言为导向的，而非成为一个严格死板的框架
• 免费开源

现代 IDE 早已不是「带高亮的编辑器」，而是一个集索引、重构、调试、数据库、HTTP 客户端、版本控制于一体的工作台。会用和不会用，同一个人一天能产出的有效工作可能差出一倍——差距主要不在打字速度，而在导航、重构、调试这三件事上。

1. 效率的来源

把开发时间拆开看，真正「写新代码」的比例往往很低，大头花在：找到要改的那段代码、理解它的上下文、验证改动是否正确。IDE 的价值就在于压缩这三段：导航让你几秒定位到目标，重构让结构改动自动而安全，调试让你直接观察运行时而非靠打印猜。下面以 IntelliJ IDEA 为主线（快捷键以 macOS 为主，Windows/Linux 把 ⌘ 换成 Ctrl、⌥ 换成 Alt）。

持续集成（Continuous Integration, CI）的核心约定是：开发者频繁地把改动合回主干，每次合入都自动触发「编译 + 测试 + 检查」，让问题在几分钟内暴露。Jenkins 是最老牌、插件最丰富的 CI 服务器之一，而 Pipeline as Code 让构建流程本身也进了版本控制、可评审、可追溯。

1. CI/CD 是什么

三个常被混用的概念：

• CI（持续集成）：频繁合并 + 自动验证。目标是「主干始终是可构建、可测试的」。
• CD（持续交付，Continuous Delivery）：在 CI 基础上，让每个通过验证的版本都随时可发布（发布动作仍可能手动点一下）。
• CD（持续部署，Continuous Deployment）：进一步，通过验证的版本自动上生产。

后端的代码最终都跑在 Linux 上。掌握它不是为了背几百条命令，而是建立一套「出问题知道先看哪里」的直觉：文件在哪、权限够不够、进程活没活、端口通不通、日志说了什么。这套直觉能让你在没人帮忙的深夜独立把服务救回来。

1. 为什么后端要懂 Linux

应用在本机跑得好好的，一上服务器就各种意外：文件路径大小写敏感、找不到 Java、目录没写权限、内存被 OOM Killer 干掉、端口被占用、时区差 8 小时。这些问题都不难，难在不知道从哪查。懂 Linux 的是那些能顺着「进程 → 端口 → 日志 → 资源」的链路自己走到底的人。