composer install 根据 composer.lock 中锁定的精确版本和依赖关系逐层展开构建 vendor 目录，是依赖解析结果的物理快照；无 lock 文件时退化为 update 并重新解析，结构可能完全不同。
Composer install 时 vendor 目录怎么生成的
vendor 目录不是凭空创建的，而是 composer install 根据 composer.lock 中锁定的精确版本、依赖图谱和安装策略逐层展开构建出来的。它本质上是「依赖解析结果的物理快照」。
关键点在于：没有 composer.lock 时，composer install 会退化为 composer update 行为（触发全新解析），此时 vendor 结构可能和之前完全不同——哪怕 composer.json 没变。
-
vendor/autoload.php是入口文件，由 Composer 自动生成，依赖composer.lock中记录的包路径和类映射关系 - 每个包的目录名格式为
vendor-name/package-name，比如monolog/monolog，这个命名直接来自composer.json的name字段，不经过任何缩写或转换 - 如果两个包声明了相同的
autoload psr-4命名空间前缀（如都映射到App\），后安装的包会覆盖先安装的——但 Composer 不报错，运行时才可能出问题
为什么 vendor/bin 下的可执行文件有时找不到
这是因为 vendor/bin 只是软链接或复制入口脚本的中转目录，其内容完全取决于包在 composer.json 中是否定义了 bin 字段，且该字段指向的文件必须存在于包的根目录下并具备可执行权限（Unix）或以 .bat/.ps1 结尾（Windows）。
- 某些包（如
phpunit/phpunit）在 10.0+ 版本移除了bin/phpunit，改用vendor/bin/phpunit作为符号链接指向vendor/phpunit/phpunit/phpunit；若你手动删过vendor/bin又没重跑composer install，链接就断了 - Windows 用户遇到
'phpunit' is not recognized，大概率是未把vendor/bin加入 PATH，或用了 Git Bash 但没启用core.autocrlf=false导致 .bat 文件换行符异常 -
composer config bin-dir vendor/bin可修改二进制目录位置，但改完必须重装依赖才能生效——已有包不会自动迁移
require-dev 包真的只在开发环境加载吗
不是。require-dev 包的代码只要被 autoload 规则覆盖，就会进入 vendor/autoload.php 的自动加载映射表，和 require 包无区别。它们的区别仅在于：composer install --no-dev 时不会下载、不会写入 vendor 目录，也不会出现在 composer.lock 的 packages-dev 段里。
- 如果你在生产环境运行了
composer install（没带--no-dev），所有 dev 包都会被安装，且它们的类可以被正常 new 或 use —— Composer 不做运行时环境判断 - 常见误操作：在 CI 中用
composer install装了 phpstan 或 pest，结果它们的 autoloader 把测试工具类注入到生产 autoloader，导致class_exists('PhpParser\NodeVisitor')返回 true，引发逻辑分支错乱 - 真正隔离的方式是：用
composer install --no-dev+ 确保生产部署不包含autoload-dev配置，同时避免在主autoload中引用 dev-only 命名空间
依赖冲突时 vendor 目录会残留旧包吗
不会残留。Composer 解析失败时（如 Your requirements could not be resolved），整个 vendor 目录保持原状或回滚到上一状态——前提是没加 --no-scripts 且 pre-install-cmd/post-install-cmd 没破坏性操作。
但要注意一个隐蔽行为：当你从 "foo/bar": "^2.0" 改为 "foo/bar": "dev-main" 后运行 composer update foo/bar，Composer 会先卸载 2.x 版本，再拉取 main 分支的代码。如果中途失败，旧包已被删，新包没装全，vendor 里只剩个空目录 foo/bar，此时 composer dump-autoload 会报错找不到类文件。
- 安全做法是：先
git status vendor确认无未提交变更，再运行 update；或用composer update --dry-run预检冲突 - CI 环境建议固定使用
composer install（靠 lock 文件），而非composer update，避免解析波动影响构建稳定性 - vendor 目录本身不应纳入版本控制，但它的结构一致性完全依赖
composer.lock的完整性——丢了 lock 文件，等于丢了 vendor 的构建说明书
