根本原因是vendor目录已被Git跟踪，导致.gitignore失效；需先执行git rm -r --cached vendor移除索引，再确保.gitignore中仅含vendor/且不忽略composer.lock。
composer install 时 vendor 目录被意外提交了怎么办
根本原因不是 composer install 本身有问题，而是 .gitignore 没生效或写法有误。最常见的是：vendor 目录早已被 Git 跟踪过，后来才加进 .gitignore —— 这时规则完全不触发。
检查是否已被跟踪：git ls-files --cached | grep vendor。如果有输出，说明它还在索引里。
补救操作（必须按顺序）：
- 运行
git rm -r --cached vendor（保留工作区文件，只从 Git 索引中移除） - 确认
.gitignore里有且仅有一行vendor/（不要写成vendor/*或*/vendor/） - 提交这次变更：
git add .gitignore && git commit -m "ignore vendor dir"
为什么 composer.lock 必须出现在 .gitignore 之外
composer.lock 不该被忽略，反而要确保它被 Git 跟踪——这是项目依赖可重现的唯一依据。一旦它被 .gitignore 错误包含，CI 构建、队友拉代码、甚至你换机器重装，都会退化为 composer update 行为，导致版本漂移。
验证方式：git check-ignore -v composer.lock。如果返回匹配行，说明它正被忽略，立刻从 .gitignore 中删掉对应规则。
顺带检查 CI 配置（如 .gitlab-ci.yml）是否在缓存逻辑里误用了 composer.lock 的哈希但实际文件没提交——GitLab 的 cache: key: files: [composer.lock] 会静默失效。
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
composer create-project 后 .gitignore 缺失的根源
composer create-project 不生成 .gitignore，它只是把模板仓库的文件原样复制过来。缺失意味着你用的模板（比如某个私有 skeleton）根目录下压根没这个文件，或者它被 .gitattributes 标记为 export-ignore，打包时被剔除了。
快速补救（别手写）：
- 用 GitHub 官方 PHP 模板：
curl -o .gitignore https://raw.githubusercontent.com/github/gitignore/main/PHP.gitignore - 加上 vendor 安全写法：
echo -e "\nvendor/\n!vendor/bin/\n!vendor/autoload.php" >> .gitignore - 检查是否漏掉其他常见项：
node_modules/、.env、storage/logs/（Laravel 场景）
CI 流水线里 vendor 和 .gitignore 的协作陷阱
GitLab CI 或 GitHub Actions 中，.gitignore 对 composer install 没直接影响，但它决定哪些文件会被上传到 runner 工作区——如果 .gitignore 里漏了 composer.lock，而你又没在 CI 脚本里显式检查它是否存在，整个构建就建立在错误假设上。
安全写法（以 GitLab 为例）：
- 在
before_script加校验：test -f composer.lock || { echo "composer.lock missing"; exit 1; } - 缓存配置必须绑定
composer.lock内容：cache: key: files: [composer.lock] - 安装命令必须带
--no-dev --prefer-dist --optimize-autoloader，否则即使.gitignore正确，vendor 也会因冗余文件变大、加载变慢
真正容易被忽略的点是：.gitignore 规则只作用于 Git 操作，不影响 Composer 自身行为；但它的缺失或错误，会让所有依赖管理动作失去上下文锚点——尤其是当团队成员各自手动执行 git add . 时，一个没被忽略的 vendor/ 就足以污染整个仓库历史。
