vendor 目录不该提交到 git，因为它由 composer 根据 composer.json 和 composer.lock 自动还原，提交会导致仓库臃肿、diff 失控、协作冲突，并可能混入 dev-only 包；git 中只需保留 composer.json 和 composer.lock。

为什么 vendor 目录不该提交到 Git

因为 vendor 是 Composer 根据 composer.json 和 composer.lock 自动还原出来的，不是你写的代码。提交它会导致仓库臃肿、diff 失控、协作冲突频发，还可能混入本地调试时临时安装的 dev-only 包。

Git 里只留 composer.json 和 composer.lock 就够了——别人克隆后运行 composer install 就能拿到完全一致的依赖树。

.gitignore 里加 vendor 的正确写法

直接在项目根目录的 .gitignore 文件末尾加一行就行，但要注意路径和斜杠细节：

• /vendor —— 推荐。开头的 / 表示只忽略项目根下的 vendor 目录，避免误伤子目录里同名的 vendor
• 别写成 vendor/ 或 vendor（没斜杠也没前缀），前者在某些旧 Git 版本中行为不稳，后者会匹配所有含 vendor 字样的路径（比如 myvendor.php）
• 如果之前已经提交过 vendor，光改 .gitignore 没用，得先让 Git “忘记”它：git rm -r --cached vendor，再 git commit

composer install 和 composer update 的区别影响 Git 状态

这两个命令对 composer.lock 的处理方式，直接决定你是否该提交这次变更：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• composer install —— 只读 composer.lock，装里面锁定的版本。不改任何文件，不用提交
• composer update —— 升级依赖、更新 composer.lock。只要 composer.lock 变了，就必须 git add composer.lock && git commit
• 漏提交 composer.lock 是最常见协作问题：别人 composer install 装出来的包版本跟你本地不一致，环境就“看似一样实则不同”

CI/CD 或部署脚本里别跳过 lock 文件校验

很多自动化流程图省事，直接 composer install --no-interaction，但前提是 composer.lock 必须存在且已提交。否则 Composer 会退化成 composer update 行为，装最新兼容版——这跟本地开发环境就不一致了。

检查点很实在：

• CI 脚本开头加一句：test -f composer.lock || { echo "composer.lock missing"; exit 1; }
• 部署机上如果 composer install 报错 “Your lock file does not contain a compatible set of packages”，说明 composer.json 和 composer.lock 已脱节，得先本地 composer update 并提交新 lock

vendor 目录本身是临时产物，但 composer.lock 是契约。契约松动，比没写 .gitignore 更难排查。