多阶段构建不直接解决依赖传递难题，但通过环境隔离与显式产物流转提供可管理框架：分阶段锁定依赖来源、用COPY--from白名单传递产物、结合ARG/ENV参数化控制、协同构建工具固化依赖树。
多阶段构建本身不直接解决依赖传递难题，但它通过隔离构建环境和显式控制产物流转，为依赖传递问题提供了可管理、可预测的落地框架。关键在于把“依赖如何来、怎么用、是否带入运行时”这三件事拆开处理。
分阶段锁定依赖来源
复杂项目中，不同环节对依赖的要求完全不同：编译需要完整工具链和开发库，测试可能要 mock 工具，而运行时只需最小依赖集。多阶段构建允许你在每个阶段使用最匹配的基础镜像，并只安装该阶段真正需要的依赖。
- 第一阶段（如
builder）用完整镜像（golang:1.21或python:3.10-slim），安装全部构建依赖（gcc、pip、node等）并完成编译/打包 - 第二阶段（如
runner）切换到极简镜像（alpine:latest或distroless），只复制上一阶段产出的二进制或静态资源，不带任何构建工具或开发依赖 - 这样就天然切断了“构建依赖向运行时泄露”的路径，避免了因间接依赖版本冲突导致的运行时异常
用 COPY --from 显式声明依赖传递
多阶段构建不自动继承文件系统或环境变量，所有跨阶段数据流动都必须通过 COPY --from=xxx 明确写出。这迫使开发者思考：“哪些东西是真正需要传给下一阶段的？”
- 比如 Python 项目中，可在
builder阶段安装依赖到/root/.local，再用COPY --from=builder /root/.local /root/.local复制到运行阶段 - Go 项目中，只复制最终生成的静态二进制，不复制
$GOPATH或源码，彻底规避模块路径和go.mod解析带来的传递性干扰 - 这种“白名单式”传递，比传统单阶段中隐式携带整个构建环境更可控，也更容易审计依赖来源
结合 ARG + ENV 控制参数化依赖行为
当项目需根据不同环境加载不同依赖（如 dev vs prod 的前端包、不同数据库驱动），可通过 ARG 在各阶段分别声明，并用 ENV 固化为运行时变量，实现依赖策略的条件化注入。
- 在
builder阶段用ARG NODE_ENV=production决定是否安装 devDependencies - 在
runner阶段重新声明同名ARG NODE_ENV，再通过ENV NODE_ENV=$NODE_ENV传给应用进程 - 这样既保持各阶段独立性，又让依赖行为可配置、可复现，避免因环境变量未透传导致的“本地正常、CI 报错”问题
与构建工具协同，收敛依赖树
多阶段构建不是替代 Maven、Go Modules 或 pip-tools 的方案，而是它们的执行容器。它把工具链的依赖解析结果“固化”为阶段产物，屏蔽了解析过程中的不确定性。
- Maven 项目可在
builder阶段执行mvn package，生成标准target/*.jar，其中dependency:tree已确定所有传递依赖版本 - Python 项目用
pip-compile生成requirements.txt后，在builder阶段安装，再将site-packages整体复制——此时依赖树已冻结，不会因 CI 中 pip 版本差异而变动 - 这种“先解析、再固化、最后裁剪”的流程，把依赖传递从运行时/构建时的动态过程，变成构建流水线中一个确定的中间状态
