必须加开头斜杠，因/vendor精确匹配根目录vendor目录，避免误匹配myvendor.php等；改.gitignore后须执行git rm -r --cached vendor清除缓存；vendor/bin/、composer.phar也需忽略；composer.lock必须提交并严格对齐。
为什么 /vendor 必须加开头斜杠才有效
不加 / 的 vendor 会被 Git 当作通配符，匹配任意路径中含该字符串的文件或目录——比如 myvendor.php、src/vendor_api/、甚至 vendorize。这不仅漏忽略真正要排除的 vendor/ 目录，还可能意外屏蔽你本想提交的源码文件。
/vendor 明确限定只作用于项目根目录下的 vendor 目录，Git 所有版本都按此语义解析，无歧义。
改完 .gitignore 后为什么 git status 还显示 vendor/ 文件
因为 Git 已经把 vendor/ 提交过（或曾被暂存），修改 .gitignore 不会自动从索引中移除已追踪的文件。常见现象是：新人克隆后 git status 一堆未暂存修改，实际是旧缓存残留。
GitCode API Usage
下载
简单易用的 GitCode API SKILL，提供 CLI 和轻量级 Python SDK 两种调用方式，用于与 GitCode 的 REST API 进行交互。支持加密访问令牌、异步调用以及完善的类型提示。 - 文档：https://gitcode-api.readthedocs.io/ - PyPI 页面：https://pypi.org/project/gitcode-api - GitHub 仓库：https://github.com/Trenza1ore/GitCode-API
- 执行
git rm -r --cached vendor：从索引删除，但保留本地文件（不影响当前开发） - 执行
git commit -m "remove vendor from git tracking" - 验证是否生效：
git ls-files | grep "^vendor/"应无输出
别漏掉 vendor/bin/ 和 composer.phar
vendor/bin/ 里全是符号链接或包装脚本，不同系统生成行为不一致；composer.phar 是可执行工具，不是项目源码。它们和 /vendor 一样，属于可再生产物，必须一并排除。
- 在
.gitignore中追加两行：vendor/bin/和composer.phar - 若自定义了
bin-dir（如"config": {"bin-dir": "tools/bin"}），对应路径也要加进.gitignore - 不用写
!vendor/bin/autoload.php这类反向规则——整个/vendor已被忽略，内部文件天然不受影响
composer.lock 比 .gitignore 更关键
.gitignore 只管“不跟踪”，不管“不污染”。只要 composer.lock 没对齐，vendor 目录哪怕完全没进 Git，环境照样不一致。
-
composer.lock必须提交，且每次composer update后要立刻git add composer.lock && git commit - CI 脚本开头建议加校验：
test -f composer.lock || { echo "composer.lock missing"; exit 1; } - 部署机报
Your lock file does not contain a compatible set of packages，说明composer.json和composer.lock已脱节，不是.gitignore的问题
