背景与动机
在 Symfony 项目中，依赖关系通常由 Composer 管理，依赖包之间的关系会形成一个庞大的有向图。通过对这些关系进行结构化处理，可以实现自动化依赖分析、可视化展示以及版本冲突的快速定位。核心目标是把这些复杂的依赖关系转换成一个可操作的数组结构，方便后续的统计、过滤和查询。
将依赖关系转换成数组的过程，有助于实现化繁为简的分析流程。对于企业级应用，准确的依赖清单和可重复的重现步骤是确保发布稳定性的关键。因此，我们需要一个清晰、可维护的实现方案来把 Symfony 的依赖树转成数组。
实现思路概览
实现的核心思路是从 Composer 的锁定文件（composer.lock）作为权威来源，读取并解析成一个结构化的数据模型，然后将每个包及其直接依赖映射到一个邻接表形式的数组中。此过程的关键点在于对数据源、数据结构和数据清洗的把控，确保结果可以在不同环境下复用。数据源的可靠性决定了最终数组的准确性。
在结果层面，我们通常需要两种常见的数据结构：邻接表（包名 => 直接依赖列表），以及在需要时的扁平化/递归合并版本的依赖集合。这两种形式都为后续的可视化、冲突检测和差异分析提供了强大的基础。
完整实现步骤
步骤一：获取并加载 composer.lock
首先从项目根目录读取 composer.lock，以获得所有包的元信息。此处的关键点是将 JSON 内容解析成 PHP 数组，保留 packages 与 packages-dev 的数据，以便后续合并处理。
通过将锁定文件作为唯一来源，可以确保转换后的数组结构在不同开发/部署环境中的一致性，降低版本漂移带来的影响。
步骤二：提取 packages 与 dev 依赖
依赖信息通常分布在 packages 与 packages-dev 节点中。将两者合并，得到完整的依赖集合，方便后续构建图结构。
在提取阶段，名称、版本、依赖关系字段是构建数组的关键要素，确保我们能够正确地表达每个包的直接依赖。
步骤三：构建依赖图（邻接表）
遍历所有包，为每个包创建一个入口，将包名映射到其直接依赖包的名称集合，从而形成一个清晰的邻接表结构。
该阶段的输出是一个可直接用于分析的数组，便于后续的遍历、可视化以及冲突判断。
步骤四：处理版本和替代/别名
某些依赖会带有版本约束、替代（provides）或别名（aliases），这些信息会影响依赖的准确性。我们在数组中以 名称 + 版本的组合作为标识，确保可重复性和区分性。
通过把版本信息纳入键值，可以在后续进行差异对比或过滤时避免歧义，从而得到更精确的依赖视图。
步骤五：输出最终数组结构
将结果以可读的数组形式输出，便于后续的分析、可视化或存储。目标是得到一个 “包名 => 直接依赖列表” 的可操作映射结构。
通过输出可以快速验证依赖关系是否完整，以及是否有缺失或异常的包信息。
进阶示例：将依赖关系转成扁平的数组
在某些场景下，我们需要将依赖树进行扁平化，得到每个包及其所有全路径依赖。实现的关键点在于进行 递归遍历与去重，确保不会重复计算并且结果可预测。
扁平化结果可以帮助快速判断某个包在整个依赖树中的暴露情况，以及是否存在循环依赖的风险。
$_) {$all[$k] = true;}}return array_keys($all);
}// 示例调用：对某个包收集所有依赖
$pkg = 'symfony/symfony';
$flatten = collectAllDeps($pkg, $graph);
print_r($flatten);
?>
