包管理、构建与任务脚本：从依赖恢复到可复现构建
包管理器负责回答“依赖从哪里来、选中哪个版本、落到哪里”，构建系统负责回答“哪些输入生成哪些输出、什么变化需要重做”，任务运行器负责把团队命令组织成稳定入口。三者经常出现在同一个终端里，却不是同一层工具。
命令清单不能证明构建可复现。读者应先能在干净目录跑通，再理解依赖图和执行图，最后能判断锁文件、缓存、私有源、凭证、跨平台和 CI 差异会在哪里破坏可复现性。
七个子家族
| 子家族 | 主要对象 | 先解决的问题 |
|---|---|---|
| JavaScript 包管理 | npm、pnpm、Yarn Modern、Corepack、Bun | 版本来源、磁盘模型、lockfile、workspace 与迁移 |
| JVM 构建 | Maven、Gradle | Wrapper、项目模型、依赖、插件、toolchain、任务与缓存 |
| Python 包与环境 | pip / venv、Poetry、uv | 解释器、环境、项目元数据、锁定、wheel 与 index |
| 语言与平台构建 | Go、Rust、Swift、.NET、PHP、Ruby | 各生态官方 manifest、lock、cache、私有源和构建入口 |
| 原生构建与依赖 | Make、CMake、Ninja、Meson、Conan、vcpkg | 依赖图、生成器、执行器、toolchain 与二进制包 |
| 任务与命令入口 | Package Scripts、Task、Just | 参数、退出码、跨平台 shell、任务依赖与团队入口 |
| 可复现构建治理 | 源、锁文件、缓存、证据、本机 / CI 合同 | 来源可信、输入完整、失败可解释、结果可重建 |
先建立一条构建证据链
一次“构建成功”至少要能回答：
运行的是哪个可执行文件和版本，版本由谁声明。项目从哪个 manifest、lockfile、settings 和环境输入形成有效配置。依赖从哪个源解析，缓存命中是否改变了结果。
哪些生命周期脚本、插件、生成器或任务获得了代码执行权限。产物由哪些输入生成，干净环境能否得到等价结果。本机与 CI 是否调用同一个权威入口，失败证据是否可比较。
只记录“在我电脑上运行了 build”不构成证据。版本、配置、来源、输入、执行图和产物身份缺一不可。
按项目现场选择阅读路线
Node.js 或前端仓库先进入 JavaScript 包管理，已有多包仓库仍先读普通 workspace；affected、任务图和远端缓存转到 31。Java / Kotlin 项目先读 Maven 或 Gradle，再用选型迁移文判断是否值得转换构建系统。Python 项目先分清解释器和虚拟环境，再在 pip / venv、Poetry、uv 中选择项目合同。
Go、Rust、Swift、.NET、PHP、Ruby 项目直接进入对应生态文章，不把其他语言的 lockfile 结论机械套用。C/C++ 项目先分清构建描述、生成器、低层执行器和包管理器，再选择 Make、CMake / Ninja、Meson、Conan 或 vcpkg。多语言仓库需要统一开发命令时读 Task / Just；它们不能替代各语言真实构建系统。
构建链路何时需要其他工具
运行时安装和版本管理属于开发机基础环境，IDE 项目导入属于IDE 与编辑器，容器运行环境属于 05，制品仓库服务端和可信发布属于 18，Nx、Turborepo、Rush、Bazel 与远端构建缓存属于 31。
验证构建合同时，需要在 CI 中运行等价命令、连接客户端私有源，并在容器内完成最小构建。问题进入 Runner 运维、环境晋级、生产发布或服务端仓库高可用后，继续沿 18 制品与交付家族排查，避免把客户端构建失败和平台服务故障混为一谈。
团队落地检查
独立工具文章给出官方入口、安装或启用、配置、最小实验、预期结果和清理回滚。核心工具解释自己的依赖模型、执行模型、缓存层、锁定语义和跨平台边界。常见失败按现象、判断、原因、修复、再验证闭环，不把删缓存作为默认答案。
示例不含真实 registry、内部模块路径、账号、token、证书私钥或生产配置。生命周期脚本、插件、远程任务、构建日志和缓存进入供应链与敏感信息审查。本机与 CI 使用同一权威入口，干净 clone、冷缓存和必要的离线场景有可复验记录。