composer.lock 必须提交到 git 仓库，它是依赖解析结果的快照，确保团队环境一致；vendor 目录永远不提交，应被 .gitignore 排除；ci/cd 中生产环境用 composer install --no-dev，测试环境用 composer install。

composer.lock 必须提交到 Git 仓库

不提交 composer.lock 是团队协作中最常见的失控源头。它不是“中间产物”，而是依赖解析结果的快照——PHP 版本、平台扩展、甚至 Composer 自身版本微小差异，都可能导致 composer install 在不同机器上装出不一致的包版本。

常见错误现象：composer install 在 CI 上失败，或本地运行正常但测试环境报 Class not found；有人手动删了 composer.lock 后重生成，悄悄引入了不兼容的次版本更新。

• 所有项目（包括私有库）都应把 composer.lock 提交进 Git，且禁止 .gitignore 排除它
• CI/CD 流程必须用 composer install --no-dev（生产环境）或 composer install（测试环境），绝不用 composer update
• 如果需要升级依赖，由专人执行 composer update vendor/package-name 并提交更新后的 composer.lock，而非全量 update

dev-dependencies 的管理边界要清晰

require-dev 里的包（比如 phpunit、infection）只影响开发和测试流程，但它们的版本同样受 composer.lock 约束。问题在于：这些工具常对 PHP 版本或扩展敏感，而生产环境根本不需要它们。

使用场景：CI 跑测试时需完整安装 require-dev，但部署到线上服务器时必须跳过——否则可能因缺少扩展（如 pcov）导致 composer install 报错，或意外暴露开发工具入口。

Discussion Composer

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

下载

• CI 配置中明确使用 composer install（保留 dev 包）
• 线上部署脚本必须加 --no-dev 参数，且最好配合 --optimize-autoloader
• 避免在 require-dev 中写死带 @dev 或 dev-main 的不稳定版本；这类包一旦被 lock 住，就很难安全回退

Git 分支策略影响依赖一致性

分支合并时，composer.lock 冲突不是“随便选一边”就能解决的。它本质是 JSON 格式的多维依赖图，手工改错一个哈希值，就可能导致后续 install 校验失败。

常见错误现象：合并 PR 后 CI 报 The lock file does not contain require-dev information；或本地 composer install 提示 Lock file is not up to date with composer.json，但 composer update 又不敢乱跑。

• 冲突时优先保留目标分支（如 main）的 composer.lock 内容，再在当前分支运行 composer update --lock 重新生成（仅更新 lock，不改依赖版本）
• 不要在 feature 分支里执行 composer update，除非明确要升级某依赖并已同步团队
• 若团队使用 GitHub Actions，建议在 PR 检查中加入 composer validate --strict 和 git status --porcelain composer.lock，确保 lock 文件与 composer.json 一致且未被意外修改

vendor 目录永远不进 Git

vendor/ 是构建产物，不是源码。把它塞进 Git 会迅速拖垮仓库体积、引发无意义 diff、且完全违背 Composer 的设计契约。

性能影响：一次 composer install 可能下载数百 MB 的包，而 Git 对二进制和重复文件压缩效率极低；兼容性影响：Windows 和 macOS 下 vendor/ 的符号链接、文件权限处理方式不同，直接提交会导致 clone 失败或 autoload 异常。

• 确认 vendor/ 已在项目根目录的 .gitignore 中，且没有被 git add -f 强行跟踪过
• 如果历史提交误入了 vendor/，用 git filter-repo --path vendor/ --invert-paths 清理（注意备份 + 强制推送）
• 某些老旧部署脚本仍尝试 rsync vendor/，应替换成标准的 composer install --no-dev --optimize-autoloader

事情说清了就结束。真正难的不是记命令，而是每次 git commit 前，多看一眼 composer.lock 是否真变了、为什么变、谁该为这次变更负责。