排查第三方依赖臃肿包的关键是识别未被运行时使用的间接依赖；需用 docker history 定位大体积层，dive 分析文件级冗余，pipdeptree 检查传递依赖，并通过多阶段构建隔离构建期与运行期依赖。
排查第三方依赖引入的臃肿包，关键不是“看装了什么”，而是“哪些被装进去了但根本没用”。镜像体积膨胀往往藏在依赖树的底层——比如你只 pip install 了一个库，它却悄悄拖进来几十个间接依赖，其中不少是开发期用的调试工具、文档生成器或测试框架，全被打包进了生产镜像。
用 docker history 定位体积大户
这是最直接的第一步。执行：
docker history your-image:tag查看每层大小和对应指令。重点关注那些体积突增的层，尤其是 RUN pip install 或 apt-get install 所在的层。如果某一层占了几百MB，基本可以断定依赖安装出了问题。
注意：单看命令不够，要结合后续是否清理。例如 RUN pip install -r requirements.txt && rm -rf ~/.cache/pip 这样的合并写法，才能真正避免缓存残留。
用 dive 工具深入文件级分析
dive 是专为镜像瘦身设计的可视化探查工具，能穿透每一层，告诉你哪些文件被写入、又被删掉（即“隐形体积”），哪些文件一直存在但从未被运行时加载。
- 安装后运行：dive your-image:tag
- 进入后按 Tab 切换到“Layers”视图，观察各层贡献比
- 选中可疑层，按 Enter 查看该层新增的所有文件
- 重点筛查：/usr/local/lib/python3.x/site-packages/ 下非主依赖的包（如 black、mypy、pytest、sphinx）、/usr/share/doc、/usr/share/man 等文档类目录
检查依赖树中的冗余传递依赖
Python 项目常用 pipdeptree 查清真实依赖关系：
pip install pipdeptreepipdeptree --reverse --packages torch,scikit-learn
加上 --reverse 可看到哪些包是被谁拉进来的。常见臃肿源头包括：
- setuptools 和 pkg_resources 被大量旧包强依赖，但新项目通常不需要
- typing-extensions、importlib-metadata 等在高版本 Python 中已内置，重复安装纯属冗余
- jupyter-core、nbconvert 等 Jupyter 相关包，常因 notebook 依赖意外流入训练镜像
建议在 requirements.txt 中显式排除非运行必需项，或改用 pip install --no-deps + 手动指定最小依赖集。
结合多阶段构建做依赖隔离
把依赖安装和最终镜像彻底分开：
- Build 阶段：用 python:3.11-slim + pip install --no-cache-dir -r requirements.txt
- Runtime 阶段：用 gcr.io/distroless/python3 或 python:3.11-slim，仅 COPY site-packages/ 和应用代码
- 这样可剥离编译工具链、头文件、测试脚本、.pyc 缓存等全部构建期产物
实测显示，对典型 ML 推理服务，该方式可剔除 60% 以上的第三方包体积，同时消除 90%+ 的 CVE 漏洞来源。
