2. 依赖基础
在文件系统构建工程中，依赖裁剪之所以困难，根本原因在于“依赖”并不是一个单一概念。一个模块声明了依赖，并不意味着它一定被加载；一个依赖被加载，也不意味着它一定参与构建。要做出正确的裁剪决策，必须先区分依赖的几种基本形态：直接依赖、传递依赖、可选依赖，以及运行时依赖与构建时依赖。本节将围绕这五类概念建立清晰的分类框架，为后续裁剪策略提供判断依据。
一、直接依赖与传递依赖：依赖链的起点与延伸
直接依赖是指当前模块在构建描述文件中显式声明的依赖。例如在 package.json 中写入 dependencies，或在 pom.xml 中写入 <dependency>，都属于直接依赖。它是依赖图的“第一层边”，来源明确、可审计、可控制。
传递依赖则是直接依赖所携带的依赖，即“依赖的依赖”。假设模块 A 依赖 B，B 又依赖 C，那么 C 对 A 而言就是传递依赖。传递依赖不会出现在 A 的声明文件中，却会真实进入构建产物或运行时环境。文件系统构建中常见的体积膨胀、符号冲突、许可证污染，大多来自传递依赖的失控。
A (直接依赖 B)
└── B (直接依赖 C、D)
├── C (传递依赖，对 A 而言)
└── D (传递依赖，对 A 而言)
└── E (二级传递依赖)理解依赖链的深度和宽度，是裁剪的第一步。裁剪传递依赖时，必须确认它是否被上层模块真实调用，否则容易造成运行时缺失。
二、可选依赖：存在但不必然参与
可选依赖（optional dependency）是指声明方认为“可能需要，但缺失也能工作”的依赖。它通常用于功能增强、平台适配或插件式扩展。例如某文件系统工具在支持压缩时需要 zlib，但未安装时仍可处理未压缩文件。
可选依赖的关键特征是：缺失不导致构建失败，也不导致核心功能失败。因此它在裁剪中属于“优先候选对象”，但前提是确认目标运行场景确实不需要该增强能力。若误将可选依赖当作普通依赖裁剪，可能不会报错，却会在特定输入下静默降级，这是排障中最隐蔽的问题之一。
三、运行时依赖与构建时依赖：生命周期视角
按依赖在生命周期中的作用位置，可分为运行时依赖与构建时依赖。
- 运行时依赖：程序执行期间必须存在，如动态库、运行时框架、文件系统驱动模块。裁剪运行时依赖会直接导致启动失败或功能异常。
- 构建时依赖：仅在编译、打包、代码生成阶段需要，如编译器插件、类型定义、构建脚本工具。构建完成后，它们不应进入最终产物。
在文件系统构建中，典型的构建时依赖包括代码生成器、镜像打包工具、静态检查器；典型的运行时依赖包括内核模块、挂载工具、校验库。裁剪时最容易犯的错误，是把构建时依赖误打进运行时镜像，造成体积浪费；或者反过来，把运行时依赖误判为构建时依赖而删除，导致系统无法挂载。
四、五类依赖的对比与判断表
| 依赖类型 | 声明位置 | 是否进入产物 | 缺失后果 | 裁剪优先级 |
|---|---|---|---|---|
| 直接依赖 | 显式声明 | 通常进入 | 构建或运行失败 | 低，需逐项确认 |
| 传递依赖 | 由上游引入 | 可能进入 | 运行期缺失 | 中，需分析调用链 |
| 可选依赖 | 显式声明为可选 | 按需进入 | 功能降级 | 高，优先评估 |
| 运行时依赖 | 运行配置或声明 | 必须进入 | 启动失败 | 极低，禁止误删 |
| 构建时依赖 | 构建配置 | 不应进入 | 构建失败 | 高，应隔离 |
五、案例场景：一次误裁传递依赖的复盘
某文件系统镜像在裁剪后体积下降 18%，但上线后出现“大文件写入偶发失败”。排查发现，被裁掉的传递依赖是一个底层校验库，它由直接依赖的压缩模块间接引入，仅在写入超过阈值时触发。该依赖既不是直接声明，也不是可选依赖，而是典型的传递运行时依赖。
复盘结论有三点：第一，传递依赖必须结合调用路径判断，不能只看声明文件；第二，可选依赖与传递依赖可能重叠，需分别标注；第三，构建时依赖应通过多阶段构建隔离，避免混入运行时层。
六、核心原理小结
依赖分类的本质，是回答三个问题：谁声明了它、它在哪个阶段被需要、缺失后会发生什么。直接依赖与传递依赖描述来源，可选依赖描述必要性强度，运行时与构建时依赖描述生命周期位置。三者交叉，才能形成完整的裁剪判断矩阵。