DevOps 术语表（Glossary）

本术语表收录 DevOps 学习过程中遇到的核心概念。每个术语保留英文原文，附中文解释。随课程推进持续更新。

基础概念

DevOps

Development + Operations 的合成词。一种文化和实践，旨在打破开发与运维之间的壁垒，通过自动化工具链实现软件的快速、可靠交付。不是一个具体职位。

CI/CD

Continuous Integration / Continuous Delivery（或 Deployment）的缩写。持续集成：频繁将代码合并到主干并自动测试。持续交付：确保代码始终处于可发布状态。持续部署：每一个通过测试的变更自动部署到生产环境。

Infrastructure as Code (IaC)

基础设施即代码。用声明式配置文件（如 Terraform 的 HCL、Ansible 的 YAML）来定义和管理服务器、网络、数据库等基础设施，而非手动操作。基础设施可以版本控制、review、自动化。

Pipeline (流水线)

一组自动执行的步骤序列。从代码提交开始，经过构建、测试、部署等阶段，最终将软件交付到目标环境。CI/CD 流水线是 DevOps 的核心工具。

SRE

Site Reliability Engineering，站点可靠性工程。Google 提出的理念：用软件工程的方法解决运维问题。SRE 和 DevOps 是互补关系，不是替代关系。

Shift Left

「左移」。将测试、安全检查等环节尽可能提前到开发周期的早期（流水线的左侧），而非等到部署前才做。越早发现问题，修复成本越低。

Linux & 命令行

Shell

命令行解释器。用户输入命令，Shell 翻译给操作系统执行。最常见的 Shell 是 Bash（Bourne Again Shell）。

stdin / stdout / stderr

标准输入（文件描述符 0）、标准输出（1）、标准错误（2）。每个进程都有这三个数据流。管道 | 连接 stdout 到 stdin，2>/dev/null 丢弃 stderr。

Pipe (管道)

| 符号。将左边命令的标准输出（stdout）连接到右边命令的标准输入（stdin），实现命令串联。

systemd

现代 Linux 的初始化系统和服务管理器。PID 1。通过 systemctl 管理后台服务（启动、停止、重启、开机自启）。

SSH (Secure Shell)

加密的远程登录协议。DevOps 日常：ssh user@host 进入服务器，scp 传文件。所有远程操作的基础。

Package Manager (包管理器)

管理软件安装、升级、卸载的工具。Debian/Ubuntu 用 apt，RHEL/CentOS 用 yum/dnf，macOS 用 brew。

/dev/null

Linux 的「黑洞」——写入的数据被丢弃，读取立即返回 EOF。常用于丢弃不需要的输出。

Shell 脚本编程

Shebang (#!)

脚本第一行的 #!/bin/bash。告诉操作系统用哪个解释器执行脚本。必须写在第一行。

Exit Code (退出码)

每个命令/脚本结束时返回的整数。0 = 成功，非 0 = 失败。$? 变量获取上一条命令的退出码。exit 0 正常退出，exit 1 报错退出。

set -e

Bash 选项。任何命令返回非 0 退出码时立即终止脚本。DevOps 脚本几乎必用，防止错误被忽略。

set -u

Bash 选项。使用未定义变量时立即报错退出。防止拼写错误导致静默 bug。

set -o pipefail

Bash 选项。管道中任何命令失败都导致整个管道失败，而非只看最后一个命令。

Command Substitution (命令替换)

$(command) 语法。将命令的标准输出作为字符串嵌入。如 TODAY=$(date)。旧语法 `command` 不推荐。

Trap

捕获信号或错误并执行指定命令。如 trap 'echo "Failed at $LINENO"' ERR 在脚本出错时打印行号。

容器 & 编排

Container (容器)

一种轻量级的虚拟化技术。将应用及其所有依赖（运行时、库、配置）打包在一起，确保在任何环境中行为一致。Docker 是最流行的容器工具。

Image (镜像)

容器的静态模板。包含运行应用所需的完整文件系统。镜像是只读的，容器是镜像的运行实例。

Docker

最广泛使用的容器平台。提供构建镜像、运行容器、管理镜像仓库的完整工具链。

Kubernetes (K8s)

容器编排平台。管理成百上千个容器的部署、扩缩容、负载均衡、自愈。K8s 是「K」和「s」之间 8 个字母的缩写。

Pod

Kubernetes 的最小调度单元，包含一个或多个紧密耦合的容器。

Dockerfile

定义如何构建 Docker 镜像的文本文件。包含 FROM、COPY、RUN、CMD 等指令。相当于镜像的「食谱」。

Docker Compose

Docker 官方工具，用 YAML 文件定义和运行多容器应用。一个 docker compose up 启动全部服务。

Docker Layer (层)

Dockerfile 中每条指令（RUN、COPY 等）生成一个只读层。Docker 按层缓存：未变的层直接复用，加速构建。COPY package*.json 放在 COPY . . 前面就是为了利用层缓存。

Multi-stage Build (多阶段构建)

一个 Dockerfile 包含多个 FROM 指令。第一阶段编译/构建，第二阶段只复制产物。最终镜像不包含构建工具，体积大幅减小。

Volume (卷)

Docker 的数据持久化机制。容器的文件系统是临时的（容器删除数据丢失），Volume 将数据存在宿主机上，跨容器生命周期保留。数据库数据必须用 Volume。

Docker Registry (镜像仓库)

存储和分发 Docker 镜像的服务。Docker Hub 是默认公共仓库（类似 npm registry）。docker push/pull 与之交互。

Alpine Linux

一个超轻量 Linux 发行版（~5MB）。Docker 官方镜像大多提供 Alpine 版本（如 node:22-alpine），是生产环境首选基础镜像。

CI/CD

GitHub Actions

GitHub 内建的 CI/CD 平台。通过 YAML 文件定义自动化工作流，免费额度慷慨（公开仓库无限用）。触发条件包括 push、PR、定时、手动。

Workflow (工作流)

GitHub Actions 的顶层单元。一个 YAML 文件 = 一个 Workflow。定义触发条件（on）、要跑的任务（jobs）及其执行环境。

Job (任务)

Workflow 中的独立执行单元。多个 Job 默认并行运行，可用 needs 指定依赖顺序。

Runner (执行器)

执行 Workflow 的虚拟机。GitHub 免费提供 ubuntu-latest、macos-latest、windows-latest。也可自建 runner。

GitHub Secrets

仓库级别的加密变量。存储敏感信息（密码、Token、SSH Key），Workflow 中用 ${{ secrets.NAME }} 读取，日志中自动屏蔽。

Matrix Build (矩阵构建)

同一个 Job 在多个参数组合上并行运行。如同时在 Node 18/20/22 和 Ubuntu/macOS 上跑测试，确保跨平台兼容性。

Artifact (制品)

Workflow 运行产生的文件（构建产物、测试报告、覆盖率数据）。可在 Job 之间传递或下载保存。

部署 & 网络

Reverse Proxy (反向代理)

位于客户端和后端服务器之间的中间层。接收客户端请求，转发给后端，返回响应。Nginx 是最常用的反向代理。作用：SSL 终止、负载均衡、静态文件服务、安全隔离。

Nginx

高性能 HTTP 服务器和反向代理。DevOps 标配：站在应用前面处理 HTTPS、静态文件、请求转发。配置文件在 /etc/nginx/sites-available/。

Let's Encrypt

免费、自动化的 SSL/TLS 证书颁发机构。通过 Certbot 工具自动获取和续期 HTTPS 证书，90 天有效期，自动续期。

rsync

远程文件同步工具。只传输变化的文件，比 scp 全量复制更高效。常用于部署：rsync -avz ./ user@server:/opt/app/。

Zero-downtime Deployment (零停机部署)

部署新版本时不中断服务。常用策略：蓝绿部署（两套环境切换）、滚动更新（逐个替换实例）、金丝雀发布（先给小部分流量）。

Infrastructure as Code

Provider (Terraform)

Terraform 的「驱动」。通过 Provider 与具体平台（AWS、Docker、GCP 等）的 API 交互。每个 Provider 定义了一套可用的 Resource 类型。

Resource (Terraform)

Terraform 管理的基本单元——服务器实例、安全组、DNS 记录、Docker 容器等。在 .tf 文件中用 resource "type" "name" { ... } 定义。

State (tfstate)

Terraform 的核心文件，记录「上次 apply 后基础设施的实际状态」。用于计算 plan diff。包含敏感信息，不能提交 Git。团队协作用 Remote State（S3、Terraform Cloud）。

HCL (HashiCorp Configuration Language)

Terraform 的配置语言。声明式语法，类似 JSON 但更人性化。支持变量、函数、模块、条件表达式。

Module (Terraform)

一组可复用的 Terraform 资源配置，相当于「函数」。封装常见模式（如「一个 VPC + 子网 + 安全组」），通过输入变量参数化。

Ansible / 配置管理

Ansible

Red Hat 出品的配置管理工具。Agentless（仅需 SSH），用 YAML 写 Playbook，声明式定义服务器应达到的状态。与 Terraform 互补：Terraform 创建基础设施，Ansible 配置服务器内部。具备幂等性——重复执行不会导致重复操作。

Inventory（清单）

Ansible 的「通讯录」——列出要管理哪些机器（主机名/IP + 分组）。支持静态文件（INI/YAML）和动态生成（从 AWS/GCP 查询）。

Playbook（剧本）

Ansible 的执行单元，YAML 文件定义一组 Task（任务），按顺序在指定主机上执行。相当于声明式版本的 Shell 脚本。

Idempotency（幂等性）

Ansible 的核心属性：同一个 Playbook 执行多次，结果相同。如果目标状态已满足，Task 自动跳过。与 Bash 脚本「每次跑都可能有副作用」形成对比。

Module（模块）

Ansible 的原子操作单元（如 apt、service、copy、template、docker_container）。3000+ 内置模块覆盖 DevOps 日常 95% 的操作。永远优先用专用模块而非 shell 模块。

Handler

Ansible 的特殊 Task，只在被 notify 通知时才执行。典型场景：Nginx 配置文件变化时才重启 Nginx，配置没变就不重启。减少不必要的服务中断。

Jinja2

Python 模板引擎，Ansible 用它做变量替换和条件渲染。在 .j2 模板文件中使用 {{ variable }} 和 {% if %} 等语法，生成配置文件。

Role（角色）

Ansible 的可复用配置包。将 Task、变量、模板、Handler 按约定目录结构组织。相当于「装一套东西的模板」，如 nginx-role、docker-role。

监控 & 告警

PromQL

Prometheus Query Language。Prometheus 的查询语言，用于检索和聚合时间序列数据。核心函数：rate()、avg()、sum()、increase()。

Node Exporter

Prometheus 生态的「探针」。装在每台服务器上，暴露 CPU、内存、磁盘、网络等系统指标的 /metrics 端点。

Alertmanager

Prometheus 的告警管理组件。接收 Prometheus 发出的告警，进行去重、分组、静默、路由，推送到 Slack/钉钉/邮件/PagerDuty。

RED Method

服务监控方法论。对每个服务关注三个指标：Rate（每秒请求数）、Errors（错误率）、Duration（响应延迟）。面试常考题。

USE Method

系统监控方法论。对每个资源关注：Utilization（利用率）、Saturation（饱和度）、Errors（错误数）。与 RED 互补，RED 看服务，USE 看资源。

Scrape (抓取)

Prometheus 的数据采集方式。Prometheus 定期 HTTP GET 目标的 /metrics 端点，拉取指标数据存入时间序列数据库。与「推送」模式相对。

云 & 基础设施

Cloud Provider (云服务商)

提供按需计算、存储、网络资源的公司。三大公有云：AWS、Azure、Google Cloud。国内：阿里云、腾讯云、华为云。

Terraform

HashiCorp 出品的基础设施即代码工具。用 HCL 语言声明式地定义云资源，执行 terraform apply 即可创建/更新实际基础设施。

Ansible

Red Hat 出品的配置管理工具。用 YAML 定义服务器配置，通过 SSH 执行，无需在被管理节点上安装 agent。

Load Balancer (负载均衡器)

将进入的流量分发到多个后端服务器，提高可用性和吞吐量。

监控 & 可观测性

Observability (可观测性)

通过系统的外部输出（日志、指标、追踪）来理解系统内部状态的能力。比「监控」更全面。

Metrics (指标)

可量化的测量值，如 CPU 使用率、请求延迟、错误率。Prometheus 是最流行的指标收集系统。

Logging (日志)

系统和应用产生的事件记录。ELK Stack (Elasticsearch, Logstash, Kibana) 是最常见的日志方案。

Prometheus

CNCF 孵化的开源监控和告警系统。按时间序列收集指标，配合 Grafana 做可视化。

Grafana

开源的数据可视化和仪表盘平台。通常与 Prometheus 配合使用。

日志系统

Loki

Grafana Labs 出品的轻量级日志聚合系统，CNCF 项目。设计哲学：像 Prometheus 但用于日志——只索引元数据标签，不索引日志全文，大幅节省资源（~200MB 内存起步）。适合容器和云原生环境。

Promtail

Loki 的日志采集 agent。部署在每台服务器或每个节点上，tail 日志文件或通过 Docker socket 采集容器日志，加标签后推送给 Loki。相当于日志版的 Node Exporter。

LogQL

Loki Query Language，Loki 的查询语言。语法：{label="value"} | filter | parser，类似 PromQL。如 {container="app"} |= "error" | json。

Structured Logging（结构化日志）

将日志输出为 JSON 格式而非纯文本，每个字段（level、timestamp、userId、traceId 等）都是可查询的维度。生产环境三原则：1. 永远 JSON 2. 永远带 level 3. 永远带 traceId。

ELK Stack

Elasticsearch + Logstash + Kibana 的简称。最知名的集中式日志方案，功能强大但资源消耗高（4GB+ 内存起步）。适合日志量极大且需要毫秒级全文搜索的场景。

Log Level（日志级别）

日志严重性分级。标准级别（从低到高）：DEBUG（调试）→ INFO（一般信息）→ WARN（警告）→ ERROR（错误）→ FATAL（致命）。生产环境通常只输出 INFO 及以上。

版本控制 & 协作

Git

分布式版本控制系统。DevOps 工具链的基础——几乎所有自动化流程都由 Git 事件触发。

SCM (Source Control Management)

源代码管理。在 DevOps 语境中通常泛指 Git + GitHub/GitLab 等平台。

GitOps

一种操作模式：将 Git 作为声明式基础设施和应用的「单一事实来源」。Git 仓库中的变更自动同步到实际系统。

Rebase

变基。将一系列 commit「搬到」另一个 commit 之后，重写提交历史为线性。与 merge 不同，rebase 不产生 merge commit。黄金法则：不要 rebase 已经 push 到共享分支的 commit。

Cherry-pick

摘樱桃。将某一个 commit 的改动复制到当前分支，不合并整个分支。常用于将 hotfix 中的单个修复移植到 release 分支。

Stash

暂存。将工作区未提交的改动临时保存，恢复干净工作区。用 git stash pop 恢复。

Bisect

二分查找。自动通过二分法定位引入 bug 的 commit。每步标记 good/bad，Git 自动缩小范围。

Reflog

引用日志。记录 HEAD 和分支引用的所有移动历史。即使 commit 被 reset 删除，reflog 仍能找到。默认保留 90 天。

Git Hook

Git 钩子。在特定 Git 事件（commit、push、receive）触发时自动执行的脚本。pre-commit、pre-push 用于本地检查，post-receive 用于触发 CI/CD。

Conventional Commits

约定式提交。一种 commit message 规范：type(scope): description（如 feat(auth): add login）。有利于自动化生成 changelog 和版本号。

GitOps

GitOps

CNCF 定义的部署模式：将 Git 仓库作为集群期望状态的唯一真相来源（Single Source of Truth）。任何对集群的手动修改都会被自动回滚。核心原则：声明式（Git 里的 YAML 定义一切）、版本化（所有变更可追溯、可回滚）、自动化（Git 变了集群自动同步）。

ArgoCD

CNCF 毕业项目，GitOps 的事实标准实现。部署在 K8s 集群内部，持续监控 Git 仓库变化并自动同步到集群。核心概念：Application（定义一个 Git 仓库 + K8s 资源路径 + 目标集群）、Sync（拉集群到 Git 期望状态）。

Sync（同步）

ArgoCD 的核心操作：将 K8s 集群的实际状态拉到 Git 声明的期望状态。支持手动触发和自动同步（检测到 Git 变化即触发）。同步状态：Synced（一致）、OutOfSync（不一致）。

Drift Detection（漂移检测）

ArgoCD 每 3 分钟对比 Git 期望状态和集群实际状态。发现不一致（如有人手动 kubectl edit 改了副本数）→ 标记 OutOfSync → 自动或手动修复。这是 GitOps 区别于传统 CI/CD push model 的关键特性。

Self-healing（自愈）

ArgoCD 的自动修复能力。开启后，任何对集群的手动修改都会被自动回滚到 Git 声明的状态。例如：手动 scale replicas=10 → 几分钟后自动改回 Git 里的 replicas=3。

Pull Model vs Push Model

GitOps 使用 Pull Model（集群内部主动拉取 Git 状态），而非 Push Model（CI 从外部推送变更到集群）。好处：集群无需暴露 kubeconfig，CI 不需要访问集群，安全性更高。

Application（ArgoCD）

ArgoCD 管理的单元。一个 YAML 文件声明了：Git 仓库 URL + K8s 资源路径 + 目标集群 + 同步策略。等价于「把 Git 的哪个目录，同步到哪个集群的哪个 namespace」。

云平台 (Cloud Platform)

VPC (Virtual Private Cloud)

虚拟私有云。云上所有资源的网络容器，可自定 IP 范围、划分子网、配路由表和网关。Public Subnet 有出网路由（Internet Gateway），Private Subnet 无公网 IP 更安全（数据库放这里）。

Security Group（安全组）

作用在云实例（EC2/ECS）级别的有状态防火墙。有状态 = 允许 inbound 的请求，响应自动允许 outbound（不需要配 outbound 规则）。与 NACL（子网级无状态）互补。

IAM (Identity and Access Management)

云的权限管理体系。三个核心概念：User（人）、Role（角色，给服务用的临时凭证）、Policy（JSON 权限文档，Allow/Deny 特定 Action 在特定 Resource）。最小权限原则：只给刚好够用的权限。

IAM Role vs IAM User

User 有永久 Access Key，适合人用；Role 提供临时凭证（自动轮转），适合 EC2/Lambda 等服务用。最佳实践：永远不给 EC2 配 Access Key，用 Role。

S3 (Simple Storage Service)

AWS 的对象存储。Key-Value 模型，无限容量，11 个 9 持久性。典型用途：静态网站托管、CI/CD 制品存储、日志归档、Terraform State 后端。

RDS (Relational Database Service)

云的托管数据库服务。自动处理备份、升级、高可用（Multi-AZ 自动故障切换 < 2 分钟）、磁盘扩容。比自己装数据库省掉 90% 的运维工作。

Multi-AZ

RDS 高可用模式：主库 + 同步备库在不同可用区。主库故障自动切到备库，数据零丢失。生产数据库必开。

Elastic IP

AWS 的静态公网 IP 地址。可以随时绑定到不同的 EC2 实例——但不要给每台机器绑，贵且浪费。应该用 Load Balancer 对外暴露服务。

DevSecOps / 安全

DevSecOps

Development + Security + Operations 的融合。核心理念：安全不是上线前的「检查点」，而是内嵌在 CI/CD 每一步的自动化流程。Shift Left = 安全检测尽量左移（代码阶段），早期发现成本最低。

SAST (Static Application Security Testing)

静态应用安全测试。不运行代码，直接读源码找安全漏洞（SQL 注入、XSS、硬编码密钥）。代表工具：Semgrep、SonarQube。

Secret Scanning（密钥扫描）

扫描 Git 历史和当前代码，检测误提交的 API Key / Token / 密码。代表工具：gitleaks、truffleHog。最佳实践：pre-commit hook 在提交前拦截 + CI 中二次检测。

Container Image Scanning

扫描 Docker 镜像的基础系统包和应用依赖，检测已知漏洞（CVE）。代表工具：Trivy、Snyk。按严重级别（CRITICAL/HIGH/MEDIUM/LOW）分级，有 CRITICAL 应阻止发布。

CVE (Common Vulnerabilities and Exposures)

公开已知的安全漏洞编号系统。如 CVE-2024-21626 是 runc 容器逃逸漏洞。Trivy 等扫描器用 CVE 数据库来比对镜像里的软件包版本。

OPA / Gatekeeper

Open Policy Agent。K8s 的策略引擎，用 Rego 语言写策略规则。Gatekeeper 是其 K8s 原生的实现——把策略做成 Custom Resource。禁止 latest tag、强制 resource limits、禁止 hostPath 等策略都通过它落地。

Distroless Image

Google 推出的超精简容器基础镜像。不含 shell、包管理器、甚至不含 ls——只有你的应用和它最少的运行时依赖。攻击者在容器里拿到 shell 也没用，因为没有 shell。

数据库运维

Database Migration（数据库迁移）

对数据库 schema 的版本化变更。每个迁移包含 up（正向）和 down（回滚）两个文件，和代码一起版本控制，CI/CD 自动执行。代表工具：golang-migrate、Flyway、Alembic。

RPO (Recovery Point Objective)

恢复点目标。能容忍丢失多少数据（时间维度）。RPO = 1 小时 → 万一现在炸了，最多丢最近 1 小时的数据。由备份频率决定。

RTO (Recovery Time Objective)

恢复时间目标。从故障发生到服务恢复的最长允许时间。RTO = 30 分钟 → 从炸到好必须在 30 分钟内完成。

PITR (Point-in-Time Recovery)

时间点恢复。利用 PostgreSQL WAL 归档，可以将数据库恢复到过去任意时间点（「回到昨天下午 3:05 的状态」）。比 pg_dump 定时备份更精细。

WAL (Write-Ahead Log)

写前日志。PostgreSQL 在修改实际数据页之前，先把操作记录写入 WAL 日志。WAL = 数据库的「录像」，用于崩溃恢复和 PITR。

PgBouncer

PostgreSQL 轻量级连接池（~2MB 内存）。应用连接 PgBouncer :6432 → PgBouncer 用少量实际连接转发到 PostgreSQL :5432。Transaction Pooling 模式：每个事务用完立刻还连接，是生产推荐配置。

缓存穿透 / 击穿 / 雪崩

Redis 面试三连击。穿透：查不存在的数据，绕过缓存直接命中 DB——用布隆过滤器。击穿：一个热点 key 过期，大量请求打向 DB——用互斥锁/mutex。雪崩：大量 key 同时过期或 Redis 宕机——TTL 加随机值 + 高可用集群。

maxmemory-policy

Redis 内存满后的淘汰策略。allkeys-lru（淘汰最近最少用的）适合缓存场景；noeviction（不淘汰，拒绝写入）是默认值但生产中几乎不用。

GitHub 协作 & 发布

Issue

GitHub 的项目管理单元——不只是 bug 报告器。Label 分类、Milestone 按版本分组、Assignee 指派负责人、Projects 看板视图。DevOps 团队也用 Issue 追踪基础设施变更。

Pull Request (PR)

代码变更的最小协作单元。包含 diff 对比、讨论线程、CI 检查结果、审批状态。合并后关联的 Issue 自动关闭（Closes #N）。

Branch Protection（分支保护）

GitHub 仓库的 gates（门禁）。规则包括：必须走 PR、必须 N 人审批、必须 CI 通过（Require status checks）、必须解决所有讨论。这是 CI/CD 和 Git 工作流的连接点。

CODEOWNERS

.github/CODEOWNERS 文件。定义「谁拥有哪些代码的审查权」——当有人修改匹配文件时，对应的 owner 自动被设为 PR Reviewer。

Semantic Versioning (SemVer, 语义化版本)

版本号命名规范 2.0.0：MAJOR.MINOR.PATCH。MAJOR = 不兼容变更，MINOR = 向后兼容新功能，PATCH = 向后兼容 bug 修复。一旦发布不可修改。

Git Tag（annotated）

指向特定 commit 的不可变引用。Annotated tag（git tag -a v1.0.0 -m "..."）包含 tagger、日期、message，可 GPG 签名——永远用 annotated，不用 lightweight。

GitHub Release

基于 git tag 的发布单元。包含 release notes（可自动生成）、可下载的二进制/assets、预发布标记。Tag push 可以触发 CI/CD 自动创建 Release。

CHANGELOG.md

给人看的版本日志。keepachangelog.com 格式：Added / Changed / Deprecated / Removed / Fixed / Security 六大分类，每个版本标注日期。

Conventional Commits（约定式提交）

标准化 commit message 格式：type(scope): description。feat:→MINOR, fix:→PATCH, feat!:或含BREAKING CHANGE:→MAJOR。配合 semantic-release 实现全自动版本发布。

semantic-release

自动化发布工具。分析 Conventional Commits → 自动决定版本号 → 生成 CHANGELOG → 创建 git tag → 创建 GitHub Release → 发布到包管理器。零手动操作。

Community Health Files

GitHub 自动识别的仓库「健康文件」：README、LICENSE、CONTRIBUTING、CODE_OF_CONDUCT、SECURITY、SUPPORT。在 Insights → Community 查看完整度评分。

LICENSE（许可证）

没有许可证的公开仓库 = 保留所有权利，别人不能合法使用。MIT（最宽松）、Apache 2.0（MIT + 专利保护，K8s/Terraform 用）、GPL（Copyleft，用了就必须开源）。

GitHub Discussions

仓库的社区论坛——Issue 是待办任务，Discussion 是开放式对话。支持 Q&A（可标记 Accepted Answer）、Ideas、Announcements、General。

GitHub Pages

把仓库的 docs/ 目录或 gh-pages 分支发布为静态网站（https://user.github.io/repo）。适合项目文档站。支持 GitHub Actions 自动部署。

.github Repository

组织下的特殊仓库（myorg/.github）。里面的 Community Health Files 和 Issue/PR 模板会作为所有组织仓库的默认值——避免每个仓库复制粘贴。

BDFL（Benevolent Dictator for Life）

「仁慈的终身独裁者」——开源治理模型。一个人（通常是项目创始人）对重大决策有最终决定权。Linux（Linus）、Python 早期（Guido）都是 BDFL 模型。