上游 · 理解本功能前需先掌握的（1）：
下游 · 依赖/承接本功能的（0）：
暂无下游（建议学完它再进阶）
前置依赖包含从属概念升级流程承接
边方向 = 学习顺序（A→B 表示先学 A 再学 B）
为什么需要它
心智模型
你写了一个很好用的工具，想分享给别人用，或团队内部想统一管理依赖。如果散落在各处，版本乱了很难排查。Packages 像一个「快递仓库」，把你的软件包集中存放、统一版本号，别人安装依赖时直接从仓库取货。
历史背景 · 它为什么诞生诞生于 2019
诞生代码托管与包管理长期分离：开发者代码在GitHub，依赖包却要发布到npm/Maven/RubyGems/NuGet等外部registry，发布流程割裂、权限管理分散。GitHub希望把"代码和包放一起"，实现从源码到制品的全链路闭环。2019-05-10以GitHub Package Registry limited public beta发布。
演进从2019年beta支持5种格式，演进为2019-11-12 GA的GitHub Packages多语言registry并与GitHub深度集成（权限复用、Actions联动发布）。2020-03-16 GitHub宣布收购npm（1.3M包/月750亿下载）强化供应链安全。
历史教训
"代码和包放一起"精准命中开发者工作流中的真实断裂点——制品管理和代码管理不该是两套系统。通过收购生态枢纽（npm）而非硬碰硬竞争，是"打不过就买下来"的平台整合范例。
功能介绍
GitHub Packages 是 GitHub 提供的软件包托管服务（"a software package hosting service"），官方定义是允许你「公开或私有地托管软件包，并把它们当作依赖（dependencies）来使用」。它支持多种软件包管理器（Package Registry），包括 npm、Maven、Gradle、NuGet、Docker 容器（Container）等。和代码仓库一样，软件包也可以设置公开或私有，私有包只有被授权的人能拉取。它的最大好处是和 GitHub 账号、权限体系天然打通：谁能发版本、谁能安装，都沿用你在仓库里配好的权限。官方还提供快速上手（Quickstart）指南，教你用 GitHub Actions 在推送新版本时自动把包发布到 Packages，让「发布」这件事全程自动化。
核心术语
软件包托管服务（Package Hosting Service）依赖（Dependencies）包注册表（Package Registry）容器（Container）npm / Maven / Gradle / NuGet私有包（Private Package）
适用场景
- 当你写了一个 npm 库想发布给全世界使用时
- 当团队内部的公共组件想私有托管、不对外公开时
- 当你想让 Docker 镜像和代码在同一个平台管理时
- 当你想用 Actions 在打版本时自动发布新包时
怎么操作（网页 vs 命令行 双轨）
🖱️ 网页操作 (GitHub.com)
- 打开仓库首页，点击右侧 Packages 区域，可查看该仓库已发布的软件包
- 点击某个软件包，进入详情页可看到版本列表、安装命令和下载量
- 在「Settings → Packages」中可配置软件包的公开/私有权限
⌨️ 命令行 (进阶)
`npm publish --registry=https://npm.pkg.github.com/` # 发布 npm 包到 GitHub Packages`npm install <包名> --registry=https://npm.pkg.github.com/` # 从 GitHub Packages 安装依赖`docker pull ghcr.io/<用户名>/<镜像名>:<版本>` # 拉取容器镜像
新手建议先从网页操作入手，熟悉概念后再尝试命令行。命令行是真实开发中更常用的方式。
与其他功能的关系
| 关系（前置依赖 / 包含从属 / 概念升级 / 流程承接） | 说明 |
|---|---|
| 流程承接自动化部署：GitHub Actions（动作） | 用 Actions workflow 自动发布包到 Packages |
官方文档
小结
SUMMARY
GitHub Packages 把软件包和代码放在同一平台，支持 npm、Maven、NuGet、容器等多种格式，权限沿用仓库设置，还能用 Actions 自动发布。下一步：打开 Quickstart，发布你的第一个软件包。