孤立包指未在composer.json中声明但存在于vendor目录的第三方库，通常因历史遗留或依赖变更导致。可通过检查依赖差异、使用静态分析工具或尝试移除后测试来识别。常见原因为曾显式引入后删除配置但未执行composer remove，或依赖同步异常。处理方式包括定期审查require列表、使用composer remove卸载、保持composer.lock一致，并在CI中启用严格安装模式以优化自动加载。遵循规范流程可有效避免此类问题。
Composer 的孤立包（orphaned packages）通常指那些被安装在项目中，但没有在 composer.json 文件中明确声明依赖关系的第三方库。这些包可能是由于历史原因、手动操作或依赖传递链变化而留在 vendor/ 目录中，当前项目实际上不再需要它们。
虽然 Composer 本身没有“orphaned package”这个官方术语，但在实际使用中，开发者常用来描述这类“无主”的、未被直接引用的包。它们的存在可能占用磁盘空间、增加自动加载负担，甚至带来安全风险。
如何识别孤立包
要判断哪些包是“孤立”的，可以借助以下方法：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 检查 composer.json 和 vendor 目录差异：运行 composer install 后，所有存在于 vendor/ 中的包都应是依赖树的一部分。如果某个包不在 composer.json 或其依赖的 require 中，但它仍存在，说明它是间接引入的——这不一定是问题，除非你确认没人用它。
- 使用工具分析使用情况：可结合静态分析工具如 deptrac、phpstan 或自定义脚本扫描代码中是否引用了某个包的命名空间。
- 尝试移除并测试：对可疑包执行 composer remove vendor/package，然后运行测试套件，看是否有报错。
导致孤立包的常见原因
- 曾经显式 require 过某个包，后来删除了配置但没运行 composer remove。
- 某些包作为其他依赖的子依赖被引入，但主依赖已移除，而子依赖仍残留在 vendor/（通常不会发生，因为 composer update 会清理）。
- composer.lock 和 vendor/ 不同步，例如手动复制了 vendor 文件夹。
处理孤立包的方法
确保项目依赖干净的最佳实践包括：
- 定期审查 require 和 require-dev：检查 composer.json 中每一项是否真的被使用。
-
使用 composer remove 卸载包：不要手动删除 vendor/ 中的目录，应通过命令让 Composer 管理依赖关系：
composer remove vendor/package-name - 提交 composer.lock 并保持一致：确保团队成员都基于相同的依赖版本，避免意外引入多余包。
- 启用严格模式安装：在 CI 环境中使用 composer install --prefer-dist --no-dev --optimize-autoloader --classmap-authoritative，有助于暴露未使用的类加载问题。
基本上就这些。Composer 会自动管理依赖树，只要遵循规范流程操作，孤立包问题很少真正出现。关键在于坚持使用 composer remove 而非手动清理，并定期审视项目的依赖列表。不复杂但容易忽略。
