composer install后出现嵌套vendor目录不是正常行为，而是因在vendor内执行install或克隆含vendor的包所致；需用find命令定位，人工核验引用关系后安全清理，并通过scripts添加ci/钩子防护。
为什么 composer install 后还会多出嵌套的 vendor 目录
这不是 Composer 的正常行为，而是项目结构被污染或误操作导致的。常见原因是：在 vendor 目录内又执行了 composer install 或 git clone 了含 vendor 的第三方包，导致出现类似 vendor/foo/bar/vendor/autoload.php 这种路径。这类嵌套 vendor 不仅浪费磁盘空间，还可能干扰自动加载、引发类冲突或安全扫描误报。
用 find 命令快速定位所有冗余 vendor 子目录
Composer 本身不提供“扫描嵌套 vendor”的命令，得靠系统工具辅助。最直接有效的是用 find 配合路径排除主目录：
find . -path './vendor' -prune -o -name 'vendor' -type d
这条命令的意思是：跳过顶层 ./vendor，然后找出其余所有名为 vendor 的目录。输出结果就是所有可疑的嵌套位置。注意 Windows 用户需改用 PowerShell 或 WSL 执行，原生 cmd 不支持这种 -prune 语法。
- 如果项目用了 Docker，记得在宿主机而非容器内运行该命令，避免挂载覆盖干扰路径判断
-
find默认区分大小写，某些 macOS 默认文件系统不区分，可加-iname替代-name提高容错 - 若输出为空，基本可确认无嵌套；若有结果，继续人工核验是否真为冗余（比如某些历史遗留的私有包确实需要独立
vendor）
如何安全清理，又不破坏依赖结构
找到冗余目录后，不能一概 rm -rf，得先确认它是否被任何 autoload 或脚本引用：
- 检查该目录下是否有
composer.json—— 如果有，说明它本应是一个独立项目，此时应考虑将其转为 proper package 并通过repositories引入，而不是放进来 - 搜索项目代码中是否硬编码引用了该路径，例如
require '/path/to/nested/vendor/autoload.php' - 运行
composer dump-autoload --no-dev看是否报错，若因删除某嵌套vendor导致 autoload 失败，说明有隐式依赖 - 清理前建议用
git status确认这些目录未被跟踪；若已被 commit，先git rm -r --cached再删文件
预防下次再出现：CI 和本地钩子怎么加
靠人眼检查不可持续。可在 composer.json 的 scripts 中加入防护：
"scripts": {
"check-nested-vendor": "find . -path './vendor' -prune -o -name 'vendor' -type d | grep -q '.' && (echo 'ERROR: nested vendor found' >&2; exit 1) || echo 'OK'"
}
然后在 CI 的 before_script 或本地 pre-commit 钩子里调用 composer run check-nested-vendor。注意这个检查必须在 composer install 之后运行，否则 vendor 还没生成，会漏检。
真正容易被忽略的是：某些 IDE 插件或前端构建工具（如 Webpack 的 resolve.modules）会把 node_modules 或 vendor 当作模块根目录递归扫描，意外触发内部 composer install —— 这类自动化行为比手动误操作更难排查。
