简介：本资源是一份系统化、分层级的云原生技术学习路线图，面向开发者、运维工程师及希望转型云原生领域的IT从业者，解决技术栈庞杂、学习路径不清晰、各组件关系难把握等核心痛点。路线图PDF文件共1个，大小1.29MB，内容覆盖初阶（容器基础、Kubernetes入门、微服务与配置中心）、中阶（Service Mesh、Serverless框架、可观测性体系、CI/CD工具链）到高阶（边缘计算、联邦集群、安全合规、编程语言深度适配）三大能力层级，包含etcd/Nacos/Harbor/Istio/Prometheus/Grafana/Argo/Terraform等超80项主流技术组件的定位、演进关系与学习建议。已有1072人学习下载，图文并茂、模块清晰，支持快速定位技术坐标、规划成长路径，并附有CSDN官方出品背书与阿里云专家联合编写说明，是构建完整云原生知识图谱的权威导览工具。

1. 云原生技术学习路线图：一张图，不是“学完就上岗”的速成班，而是帮你绕开三年踩坑路的导航仪

你有没有试过——在搜索引擎里输入“怎么学云原生”，结果跳出几百篇教程：有的从 Docker 命令讲起，有的直接甩出 Istio 的 YAML 配置，还有的上来就让你手写 Operator；你跟着学了两周，能跑通一个 Pod，但一问“为什么用 Helm 不用纯 YAML”就卡壳；再过一个月，发现 Service Mesh 换了新框架，Serverless 又出了新 Runtime，自己刚搭好的环境像被时代甩在站台上的旧车票……这不是你不够努力，而是缺一张真正“懂初学者困惑”的地图。

《云原生技术学习路线图》不是知识清单，而是一份按认知节奏设计的成长导航：它把 etcd、Prometheus、Kubernetes 这些名词，放进“初阶→中阶→高阶”的三层台阶里，每一步都标清楚“学什么、为什么学、不学它会卡在哪”。比如，它不会让你一上来就啃 Kubelet 源码，而是先告诉你：“缓存（Redis）和配置中心（Nacos）为什么必须放在微服务之前学？因为没它们，你的第一个 Spring Cloud 服务连配置都拉不下来。” 它也不回避现实水深——路线图里明确标出哪些工具已逐步退出主流（如 Conduit），哪些正成为事实标准（如 OpenTelemetry 替代 Zipkin/Jaeger），甚至提醒你：“别急着学所有 CNI 插件，Calico 和 Cilium 覆盖 90% 场景，其他留到排障时再查。” 这张图的价值，不在于告诉你“云原生有多火”，而在于帮你回答三个真实问题：我现在该停在哪？下一步往哪拐？哪些路根本不用走？

2. 到底什么是“云原生技术学习路线图”：它不是课程表，而是一套动态演进的能力坐标系

2.1 路线图的本质：把碎片技术拼成可验证的“能力拼图”

很多人误以为路线图就是“学完 Docker → Kubernetes → Istio → Serverless”的线性流程。错。真正的路线图，是把技术还原成解决具体问题的能力单元。比如，“部署一个高可用微服务”这件事，在路线图里被拆解为：

• 基础层能力：能用kubectl apply -f部署 Pod，并理解livenessProbe和readinessProbe的区别（不是背定义，是能说出“如果只配 readiness 不配 liveness，服务挂了却还在流量池里”）；
• 协作层能力：能用 Helm Chart 封装一个含 ConfigMap + Secret + Deployment 的应用包，并解释“为什么不能把密码明文写进 values.yaml”；
• 治理层能力：当服务响应变慢，能通过 Grafana 看到 Prometheus 抓取的http_request_duration_seconds_bucket分位数曲线，再结合 Jaeger 追踪链定位到某次 Redis 连接超时。

提示：路线图里每个方块（如 “Prometheus”）旁都标注了“掌握标志”，例如对 Prometheus 的要求是：“能独立配置 3 个自定义 Exporter（Node Exporter、MySQL Exporter、自研业务 Exporter），并写出告警规则判断‘连续 5 分钟 CPU 使用率 > 85%’”。这不是考试大纲，而是你合上电脑后，能立刻在公司测试环境里动手验证的最小闭环。

2.2 为什么需要分“初阶/中阶/高阶”：认知负荷决定学习效率的天花板

初学者常犯的错误，是跳过“为什么需要这个”的背景，直接冲进“怎么用”。路线图的分阶逻辑，本质是匹配人类大脑处理复杂度的生理规律：

• 初阶（绿色区块）：聚焦“让系统跑起来”。核心是建立直觉——比如用 Minikube 搭本地集群，不是为了生产，而是让你亲手看到：“当我删掉一个 Pod，Kubernetes 真的会自动拉起一个新的”；用 Dockerfile 构建镜像时，强制要求你对比alpine和ubuntu镜像大小差异，从而理解“为什么云原生强调轻量”。这些操作看似简单，却是后续所有抽象概念的锚点。
• 中阶（蓝色区块）：转向“让系统稳下来”。这时引入 Nacos 做配置中心，不是因为它名字好听，而是因为你已经写过 3 个微服务，亲身体验过“改个数据库地址要改 5 个配置文件”的崩溃；学 Istio 的 VirtualService，是因为你发现用 Kubernetes Ingress 处理灰度发布太吃力——路线图在这里埋了“触发器”：只有当你在初阶遇到对应痛点，中阶内容才真正生效。
• 高阶（紫色区块）：目标是“让系统自己进化”。比如 OAM（Open Application Model）和 KubeVela，它们解决的是“运维同学写 YAML、开发同学改代码、双方在 Git 里反复冲突”的协作熵增问题。但如果你连 Helm 都没用熟，直接学 OAM 就像没学加减法就去解微分方程——路线图把这类抽象模型放在最后，正是因为它依赖前两阶积累的“系统观”。

2.3 路线图里的“非技术要素”：那些没人明说，但决定你走多远的关键习惯

技术路线图最易被忽略的部分，其实是隐性能力标注。比如在 “CI/CD” 区块下，除了 Jenkins/Argo，路线图特别强调：

• 必须掌握 GitOps 工作流：不是指会用 Flux，而是理解“为什么每次合并到 main 分支，必须自动触发集群状态比对，而不是手动kubectl apply”；
• 必须建立可观测性反射：当新功能上线后，第一反应不是“看日志”，而是打开 Grafana 查error_rate指标、用 Loki 搜level=error、再用 Jaeger 看调用链耗时分布——这种条件反射，比记住 10 个命令重要得多；
• 必须养成“降级验证”习惯：学完 Knative 后，路线图要求你做一件小事：把某个函数的内存限制从 512Mi 降到 64Mi，观察它是否优雅失败并返回 503，而不是直接 OOM Kill。这背后训练的，是云原生最核心的思维——资源永远有限，故障永远发生，预案必须前置。

这些习惯不会出现在任何官方文档里，却是某开发者在某次大促凌晨三点重启服务时，突然顿悟的“血泪经验”。路线图把它们固化为学习节点，是因为它知道：技术可以速成，但工程直觉，只能靠刻意练习长出来。

3. 初阶路线图里藏着的 5 个关键认知陷阱：你以为在打基础，其实已在挖坑

3.1 易混点：Docker 和 Kubernetes 是“父子关系”？

为什么混：教程常说“K8s 是容器编排平台，Docker 是容器运行时”，听起来像 Docker 生了 K8s。
怎么区分：Docker 是单机工具，Kubernetes 是分布式操作系统。类比：Docker 像一台能启动汽车的遥控器（按一下，容器跑起来），Kubernetes 像整个交通管制中心（实时监控 1000 辆车位置、自动调度红绿灯、发现事故车立即拖走并派新车顶上）。路线图初阶要求你先用 Docker Desktop 在本机跑通 Nginx，再用 Minikube 启动 K8s 集群——目的就是让你亲手感受：没有 K8s 时，你得自己写脚本监控容器是否存活；有了 K8s，kubectl get pods一行命令就看到全局健康状态。

3.2 易混点：Helm 是“K8s 的安装包管理器”，所以它和 apt/yum 一样？

为什么混：都叫“包管理器”，都用helm install类似apt install。
怎么区分：apt/yum 安装的是二进制程序，Helm 安装的是声明式配置模板。举个例子：helm install myapp bitnami/nginx看似安装 Nginx，实际是生成一份包含 Deployment + Service + ConfigMap 的 YAML，再kubectl apply到集群。路线图初阶特意安排你手动展开 Helm Chart（helm show values bitnami/nginx），然后对比helm template输出的原始 YAML——你会发现，所谓“Chart”，本质是 Go Template + YAML 的混合体，它的价值不在封装，而在参数化复用：同一份 Chart，改service.port就能部署测试/预发/生产三套环境。

3.3 易混点：etcd 只是 K8s 的“数据库”，学 K8s 时顺便了解就行？

为什么混：官方文档说“etcd 存储集群状态”，初学者觉得“反正不直接操作，等出问题再查”。
怎么区分：etcd 是 K8s 的“心脏起搏器”。当kubectl get nodes返回空，90% 可能是 etcd 不可用；当 Pod 一直处于ContainerCreating，可能是 kubelet 无法连接 etcd 获取 PodSpec。路线图初阶强制要求你：用etcdctl手动备份/恢复一个 key（如/registry/nodes），并故意 kill etcd 进程观察集群降级行为。这不是炫技，而是建立一个关键认知：K8s 的一切能力，都建立在 etcd 数据强一致的基础上。跳过这步，后面学 Operator、StatefulSet 时，你会反复栽在“为什么我的自定义资源没生效”这种玄学问题上。

3.4 易混点：Prometheus 监控 = 写几个 metrics，配个 Grafana 面板？

为什么混：太多入门教程教你“三步接入 Prometheus”，最后只展示一个 CPU 曲线图。
怎么区分：Prometheus 的核心不是采集数据，而是定义可观测性契约。路线图初阶要求你做两件事：

1. 用prometheus_client库给一个 Python Flask 服务添加/metrics接口，暴露http_requests_total{method="GET",status="200"}这样的指标；
2. 修改代码，让某个接口随机返回 500，并观察 Prometheus 中http_requests_total{status="500"}计数器是否实时增长。
   这背后训练的是：指标命名必须携带业务语义（不是myapp_error_count，而是http_requests_total{status=~"5.*"}），否则告警规则写出来就是“当 myapp_error_count > 10 就报警”，完全无法定位是登录失败还是支付超时。

3.5 易混点：YAML 是“配置文件”，写对缩进就能跑？

为什么混：kubectl create -f成功就以为 YAML 没问题，直到上线后发现服务连不上。
怎么区分：YAML 是 K8s 的“宪法”，每一行都是对集群状态的法律声明。路线图初阶专门设“YAML 陷阱排查”小节，要求你故意写错：

• 把spec.template.spec.containers[0].ports[0].containerPort写成port（K8s 会静默忽略，Pod 启动成功但端口未暴露）；
• 在 ConfigMap 中用data: {key: value}而不是data: {key: "value"}（YAML 解析器把 value 当变量，导致注入到容器的环境变量是空字符串）。
  这些错误不会报错，但会让服务处于“假成功”状态。路线图用这种方式逼你建立一个习惯：每次写完 YAML，必须用kubeval或kubectl apply --dry-run=client -o yaml验证结构合法性——这是所有云原生工程师的后悔药。

4. 中阶路线图的核心跃迁：从“会操作”到“懂取舍”，看懂技术选型背后的工程权衡

4.1 Service Mesh 选型：Istio、Linkerd、OpenServiceMesh，到底在比什么？

初阶学完 Kubernetes 基础后，中阶第一个分叉路口就是 Service Mesh。路线图没有罗列各家特性，而是用一张决策树表格帮你聚焦本质：

提示：路线图中阶明确建议——如果你的团队当前只有 3 个微服务，且没有合规审计硬需求，Linkerd 是更优起点。不是因为它“更好”，而是因为 Istio 的学习曲线会让你花 2 周时间配置 mTLS，而 Linkerdlinkerd inject一键注入后，mTLS 自动开启。技术选型的第一原则，永远是“用最小成本解决当前最大痛点”。

4.2 配置中心选型：Nacos vs etcd vs Consul，别被“支持 CP/AP”忽悠

很多教程一提配置中心就讲 CAP 理论，但路线图中阶直接抛出一个真实场景：

某电商大促前，运营同学需要动态调整“秒杀商品库存阈值”。这个配置必须：

• 强一致性：所有服务实例看到的值完全相同（不能 A 服务读到 100，B 服务读到 99）；
• 高可用：即使配置中心宕机 5 分钟，服务仍能用上次缓存的值继续运行；
• 热更新：修改后无需重启服务。

对照这个需求看选型：

• etcd：CP 模型，强一致，但无客户端 SDK 热更新能力，需自己实现监听+缓存；
• Consul：AP 模型，可用性高，但默认不保证强一致（需开启 Raft），且配置变更推送机制复杂；
• Nacos：AP+CP 可切换，内置客户端 SDK 支持自动监听+本地缓存+失败降级，专为这个场景设计。
  路线图中阶结论很直白：“除非你已在用 Consul 做服务发现且不愿增加组件，否则 Nacos 是配置中心的默认答案”。它不鼓吹技术先进性，只问一句：“它能不能让运营同学在大促前 10 分钟，安全地改完配置并确认生效？”

4.3 CI/CD 工具链：Jenkins、Argo CD、Tekton，谁在解决真问题？

中阶路线图把 CI/CD 拆成两个独立能力：持续集成（CI）和持续交付（CD），并指出：

• Jenkins是 CI 时代的王者，但它的 Pipeline-as-Code（Jenkinsfile）本质是“用 Groovy 脚本描述过程”，难以被 GitOps 工具管理；
• Tekton是 Kubernetes 原生 CI 框架，所有构建任务都定义为 CRD（Task/Pipeline），天然支持版本化、复用、权限隔离；
• Argo CD是 CD 专用工具，它不负责构建，只专注一件事：确保 Git 仓库中的 YAML 与集群实际状态 100% 一致。

路线图中阶给出一个典型组合：

# Tekton Pipeline 定义构建流程（CI） apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: build-and-push spec: tasks: - name: build-image taskRef: name: kaniko - name: push-to-registry taskRef: name: gcr-push --- # Argo CD Application 定义部署目标（CD） apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: myapp-prod spec: source: repoURL: https://github.com/myorg/myapp.git targetRevision: main path: k8s/prod # 此目录下的 YAML 会被自动同步到集群

这段代码背后是路线图的深层逻辑：CI 关注“如何构建”，CD 关注“如何交付”，强行用一个工具覆盖两端，只会让两者都做不深。所以中阶推荐“Tekton + Argo CD”组合，而非“Jenkins All-in-One”。

4.4 日志方案选型：ELK vs EFK vs Loki，存储成本决定技术命运

路线图中阶用一个数字刺破幻想：

一个中等规模微服务集群（50 个 Pod），每天产生约 200GB 原始日志。若用 ELK（Elasticsearch + Logstash + Kibana）：

• Elasticsearch 存储成本 ≈ 2TB（因倒排索引膨胀 10 倍）；
• 查询延迟 ≈ 3~5 秒（海量数据下聚合计算慢）；
• 运维复杂度：需调优 JVM、分片、副本、冷热分离。

而 Loki 方案：

• 存储成本 ≈ 200GB（只索引标签，不索引全文）；
• 查询延迟 ≈ 1 秒内（基于标签的精准过滤）；
• 运维极简：用对象存储（如 S3/MinIO）存日志块，用 Promtail 采集。

路线图中阶结论毫不客气：“除非你有全文检索刚需（如客服系统搜索用户投诉关键词），否则 Loki 是日志方案的默认选择”。它把技术选型拉回工程本质：不是谁功能多，而是谁让团队少加班。

5. 高阶路线图的终极考验：当“学完所有技术”后，你能否定义自己的云原生？

5.1 OAM 与 KubeVela：为什么需要“应用模型”这一层抽象？

高阶路线图的第一个挑战，是理解“为什么 Kubernetes 原生 API 不够用”。看一个真实案例：
某公司有 3 个团队——A 团队用 Spring Boot，B 团队用 Node.js，C 团队用 Python Flask。他们都要部署服务，但需求不同：

• A 团队需要：自动扩缩容（HPA）、蓝绿发布、日志收集到 Loki；
• B 团队需要：自动 TLS（Cert-Manager）、API 网关路由、链路追踪（Jaeger）；
• C 团队需要：GPU 资源调度、模型版本管理、A/B 测试分流。

如果每个团队都直接写 Kubernetes YAML，会出现什么？

• 重复造轮子：3 个团队各自实现 HPA、TLS、日志采集逻辑；
• 权限失控：C 团队为 GPU 调度申请了 cluster-admin 权限；
• 协作断裂：运维同学看不懂 B 团队的 Ingress 配置，A 团队的 HPA 参数调错导致雪崩。

OAM（Open Application Model）的出现，就是为了解决这个“抽象断层”。它把应用拆成：

• Component（组件）：描述“我是什么”（如type: webapp,image: nginx:1.20）；
• Trait（特征）：描述“我要什么能力”（如autoscaler,ingress,logsidecar）；
• ApplicationConfiguration（应用配置）：描述“组件和特征如何组合”。

KubeVela 是 OAM 的工业级实现。路线图高阶要求你用 KubeVela 部署同一个应用，但为不同环境绑定不同 Trait：

# dev 环境：只启用日志采集 apiVersion: core.oam.dev/v1beta1 kind: ApplicationConfiguration metadata: name: myapp-dev spec: components: - componentName: myapp traits: - trait: apiVersion: core.oam.dev/v1alpha2 kind: LogSidecar spec: image: fluentd:1.14

# prod 环境：启用扩缩容+网关+链路追踪 apiVersion: core.oam.dev/v1beta1 kind: ApplicationConfiguration metadata: name: myapp-prod spec: components: - componentName: myapp traits: - trait: apiVersion: core.oam.dev/v1alpha2 kind: Scaler spec: minReplicas: 2 maxReplicas: 10 - trait: apiVersion: core.oam.dev/v1alpha2 kind: Ingress spec: domain: myapp.prod.example.com - trait: apiVersion: core.oam.dev/v1alpha2 kind: Trace spec: backend: jaeger

这段代码的意义，不是语法炫技，而是路线图想传递的高阶认知：云原生的终点，不是学会所有工具，而是有能力设计一套符合自己组织基因的交付语言。OAM/KubeVela 就是这样一种语言——它让开发同学只关注 Component（业务逻辑），让运维同学只关注 Trait（基础设施能力），让平台同学只关注 ApplicationConfiguration（组织策略）。

5.2 Serverless Runtime 选型：Knative vs Kubeless vs Fission，冷启动不是唯一指标

高阶路线图对 Serverless 的要求，是穿透“函数即服务”的表象，直击业务本质。它提出一个尖锐问题：

你的函数，是“事件驱动型”（如上传图片触发压缩）还是“请求驱动型”（如 API 网关转发 HTTP 请求）？

• Knative Serving：为请求驱动优化，支持 HTTP 流量自动扩缩（包括缩容到 0），但冷启动延迟 ≈ 1~3 秒（需拉起 Pod）；
• Kubeless/Fission：为事件驱动优化，通过消息队列（Kafka/RabbitMQ）解耦，函数实例常驻内存，冷启动 ≈ 0，但不支持 HTTP 自动扩缩；
• CloudEvents：不是运行时，而是事件格式标准。路线图高阶强调：无论选哪个 Runtime，必须用 CloudEvents 规范事件数据结构，否则未来换平台时，所有函数都要重写解析逻辑。

路线图高阶结论务实：“如果业务是 Web API，选 Knative；如果是后台异步任务（如订单结算），选 Fission + CloudEvents”。它拒绝空谈“谁更先进”，只问：“你的业务流量模型，匹配哪种扩缩机制？”

5.3 云原生的“反模式”清单：那些路线图里没写，但你必须避开的深渊

高阶路线图最后一页，是一份手写风格的“反模式清单”，它不教你怎么对，只警告你哪里绝对不能错：

• 反模式 1：把 Kubernetes 当虚拟机用

  表现：给每个 Pod 分配 8 核 32G，部署单体 Java 应用，用hostPath挂载磁盘。
  后果：资源利用率 < 10%，集群扩容毫无意义，失去弹性优势。
  路线图对策：强制要求所有容器镜像使用alpine基础镜像，CPU limit 必须 ≤ 2 核，内存 limit ≤ 2Gi。

• 反模式 2：YAML 全家桶主义

  表现：一个deployment.yaml里塞满 InitContainer、Sidecar、Volume、Affinity、Toleration……
  后果：配置不可读、不可复用、Git Diff 失效，一次修改引发连锁故障。
  路线图对策：推行“单一职责 YAML”——Deployment 只管容器，ConfigMap 只管配置，Secret 只管密钥，用 Helm/Kustomize 组装。

• 反模式 3：监控只看“黄金指标”，不看“业务指标”

  表现：Grafana 面板全是 CPU、内存、HTTP 5xx，但从不监控“用户下单成功率”“支付回调延迟”。
  后果：系统 100% 健康，业务已瘫痪 2 小时。
  路线图对策：强制每个微服务暴露至少 3 个业务指标（如order_create_success_rate,payment_callback_latency_ms），并设置告警。

这份清单没有技术细节，只有血淋淋的后果和一句路线图式的总结：“云原生不是技术堆砌，而是用技术约束，倒逼工程文化升级。”

6. 我的真实踩坑记录：从把 MinIO 当对象存储，到用 OAM 定义公司交付标准

去年，我接手一个遗留系统迁移项目：把某高校实验室的图像分析平台，从物理服务器迁移到云原生架构。团队有 5 人，没人用过 Kubernetes，但老板说“必须用最新技术”。我翻遍所有教程，信心满满地画出架构图：Docker → Kubernetes → Istio → Prometheus → Grafana —— 典型的“路线图初阶到中阶”路径。

第一周：MinIO 的幻觉
我选 MinIO 作为对象存储，因为“它兼容 S3 API，文档写得最全”。上线后，用户上传一张 2GB 的 MRI 图像，前端卡死。查日志发现：MinIO 默认内存映射模式，在大文件上传时吃光 16G 内存。我连夜调参、加 swap、换 SSD……最后发现，路线图中阶早有一句小字提示：“MinIO 生产环境务必启用--drives模式直写磁盘，禁用--cache”。我漏看了，因为当时只盯着“怎么部署”，没读“怎么避坑”。

第三周：Istio 的雪崩
为实现灰度发布，我上了 Istio。配置 VirtualService 时，把weight写成100（应为100.0），导致 10% 流量被路由到不存在的服务，触发级联超时。排查 36 小时后，我在路线图中阶的“Istio 调试清单”里找到答案：“所有数值型字段，必须带小数点”。这不是 bug，是 Istio 的 YAML 解析器严格遵循 JSON Schema。那一刻我明白：路线图里那些“看起来多余的细节”，全是别人用通宵换来的教训。

第六周：OAM 的顿悟
当第 7 个团队来问“怎么给我的服务加自动扩缩容”，我放弃了手写 HPA YAML。我打开路线图高阶章节，照着 KubeVela 示例，定义了一个AutoScalerTrait：

apiVersion: core.oam.dev/v1beta1 kind: TraitDefinition metadata: name: scaler spec: appliesToWorkloads: - deployments.apps workloadRefPath: spec.workloadRef schematic: cue: template: | output: { apiVersion: "autoscaling/v2" kind: "HorizontalPodAutoscaler" metadata: { name: context.name + "-hpa" } spec: { scaleTargetRef: { apiVersion: "apps/v1" kind: "Deployment" name: context.name } minReplicas: parameter.min maxReplicas: parameter.max metrics: [{ type: "Resource" resource: { name: "cpu" target: { type: "Utilization" ; averageUtilization: parameter.cpu } } }] } } parameter: { min: *2 | int max: *10 | int cpu: *80 | int }

然后，所有团队只需在 ApplicationConfiguration 中声明：

traits: - trait: apiVersion: core.oam.dev/v1alpha2 kind: Scaler spec: min: 2 max: 5 cpu: 70

——从此，扩缩容不再是运维的魔法咒语，而成了开发可配置的开关。

从那以后，我每次启动新项目，都强制走一遍路线图的“三问检查”：

1. 初阶检查：这个技术，能否用 Minikube 在 10 分钟内跑通最小闭环？（不能，就暂缓）
2. 中阶检查：它解决的痛点，是否已被我当前的 3 个线上故障复现过？（没有，就标记为“观察”）
3. 高阶检查：它的抽象层级，是否匹配我们团队的协作半径？（比如 OAM 对 5 人团队可能过重，但对 50 人跨部门项目就是救命稻草）

这张图没有承诺“学完就能年薪百万”，但它确实让我少写了 2000 行重复 YAML，少熬了 17 个通宵，更重要的是，它帮我把“云原生”从一个模糊的热词，变成了每天早上打开终端时，心里有底的那几行命令。希望帮到你。

本文还有配套的精品资源，点击获取