多阶段构建不处理依赖传递，仅隔离环境并按需复制产物；依赖传递由构建语言机制（如go.mod、package.json）决定，须在构建阶段完成解析与下载，避免运行镜像污染。
多阶段构建本身不处理“依赖关系的传递”，它只负责分阶段隔离环境、按需复制产物。真正影响依赖传递的是构建语言本身的依赖管理机制（如 go 的 go.mod、node.js 的 package.json、java 的 module-info.java 或 maven 的 pom.xml），而多阶段构建要做的，是让这些机制在合适阶段被正确触发，并避免把传递依赖错误地带入运行镜像。
关键：依赖解析必须发生在构建阶段，且要分层缓存
依赖传递（比如 A → B → C）在编译前就应完成解析和下载，否则运行阶段会缺失间接依赖。多阶段构建通过把依赖安装和源码编译拆开，确保传递依赖只参与构建，不污染最终镜像。
- Go 项目中，先
COPY go.mod go.sum .，再RUN go mod download—— 这一步会递归拉取所有直接+间接依赖（含 B 依赖的 C），但仅存在于 builder 阶段 - Node.js 项目中，在 builder 阶段
RUN npm ci --only=production不够，应改用npm ci（含 dev 依赖）完成完整构建，再将dist/或build/复制到 nginx 阶段 - Java/Maven 项目中，builder 阶段运行
mvn clean package，Maven 自动解析整个依赖树（包括传递依赖），生成的.jar已内嵌或声明了所有运行所需，后续阶段只需复制该 jar
避免运行阶段意外暴露传递依赖
有些框架（如 Spring Boot）会把依赖清单（META-INF/MANIFEST.MF 或 BOOT-INF/lib/）打进 fat jar；而另一些（如 Go 静态二进制）默认不带任何依赖路径。多阶段构建要根据语言特性决定是否需要额外清理：
- Go 编译时加
-ldflags="-s -w"去除调试符号，静态链接后无外部.so依赖，无需担心传递库泄漏 - Python 项目若用
pip install安装包，builder 阶段应使用--no-deps或虚拟环境隔离，再用pip wheel提前固化依赖，防止COPY --from=builder时误带site-packages全量目录 - 前端项目打包后，检查
index.html中 script 标签是否仍引用 CDN 资源——这类“远程传递依赖”不会被 COPY 捕获，需在构建阶段通过环境变量或构建配置提前替换
跨阶段依赖传递？不存在，但可模拟
Docker 多阶段之间没有自动依赖传递。每个阶段从零开始，上一阶段的文件系统不可见，除非显式 COPY --from。但你可以利用这个机制“手动传递”：
- 多个 builder 阶段协作：例如第一阶段用
python:3.11生成 proto 文件，第二阶段用golang:1.21编译 Go 代码，第三阶段用alpine运行 —— 各阶段只COPY --from上一阶段产出的特定文件（如.pb.go），不传整个/usr/local/lib - 用
--from=image:tag引用预构建的依赖镜像：比如把通用工具链（clang、cmake、openssl-dev）打包成my-build-base:latest，各业务构建阶段都COPY --from=my-build-base提取头文件或静态库，实现“依赖复用”而非“依赖传递”
真正要管住的，是构建工具链自身的依赖传递
比如 go build 默认启用 -mod=vendor 或 -mod=readonly，会影响 go.sum 中记录的间接依赖版本；又比如 npm install 在不同 Node 版本下解析 ^ 语义可能不同，导致传递依赖版本漂移。这些不是 Docker 的责任，但多阶段构建提供了控制点：
- 固定构建工具版本：用
golang:1.21.10而非golang:1.21，避免 minor 版本升级导致go mod tidy解析出不同间接依赖 - 构建阶段末尾执行
go list -m all > deps.txt并COPY出来，用于审计传递依赖清单 - 对
package-lock.json或pnpm-lock.yaml做COPY+npm ci，确保锁定所有层级依赖，不因网络或 registry 变更而改变传递结果
