应用型项目必须提交composer.lock，库项目不该提交；判断依据是项目角色：部署可运行服务则为应用型，需提交；发布供他人require的包则为库项目，不提交。
应用型项目必须提交 composer.lock，库项目不该提交——这不是风格选择，是构建可靠性的底线。
怎么判断你的项目该不该提交 composer.lock
关键看项目角色，不是看规模或是否“内部使用”：
- 你部署的是一个可运行的服务（Laravel 网站、Symfony API、WordPress 插件后台、Swoole 微服务）→ 是应用型项目 →
composer.lock必须进 Git - 你写的是一个会被别人
require的包（比如acme/log-helper），发布到 Packagist → 是库项目 → 不提交composer.lock，它对下游无意义，还可能误导 - 不确定？问自己：CI 流水线执行
composer install后，是否直接用于提供 HTTP 服务或 CLI 命令？如果是，就按应用处理
composer.lock 被 .gitignore 拦了怎么办
这是最常被忽略的故障源头，现象是 git status 根本不显示它，但 CI 报 Class not found 或本地和服务器 vendor 差一堆文件。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先验证：运行
git check-ignore -v composer.lock，如果有输出，说明它正被忽略 - 检查
.gitignore里是否有类似/composer.lock、composer.*、*lock*这类宽泛规则，删掉或收紧 - 如果项目用过某些脚手架（如旧版 Laravel installer 或某些 CI 模板），它们可能偷偷加过 ignore 规则，别信默认配置
- 修复后执行
git add -f composer.lock强制加入，再git commit
CI/CD 和部署脚本里 composer install 怎么用才安全
生产环境一旦漏掉 --no-dev 或误用 composer update，轻则装不上，重则引入不兼容的 dev 工具导致 500 错误。
- 测试环境 CI：用
composer install（保留require-dev，跑 PHPUnit 需要） - 生产部署脚本：必须用
composer install --no-dev --optimize-autoloader - 绝对禁止在部署流程里出现
composer update—— 它会绕过 lock 文件重新解析，彻底破坏一致性 - Docker 构建中，
RUN composer install --no-dev必须出现在COPY . .之后、ENTRYPOINT之前，且镜像层不能缓存 vendor 目录
composer.lock 冲突了，能手动改哈希值吗
不能。JSON 里的 content-hash 和每个包的 dist.shasum 是校验关键，改错一个字符，composer install 就会报 Content hash mismatch 并退出。
- 分支合并冲突时，不要手工编辑 JSON；用
git checkout --ours composer.lock或--theirs选一边，然后立刻composer install验证能否成功生成 vendor - 如果两边 lock 都不可靠， safest 方式是删掉
composer.lock，再跑一次composer install重建（前提是composer.json本身没冲突） - 团队应约定：升级依赖由专人操作，
composer update vendor/package-name后提交新 lock，避免多人同时update导致哈希震荡
真正难的不是生成或提交 composer.lock，而是让所有人理解：它不是“生成物”，而是依赖状态的权威声明——删它、忽略它、跳过它，等于主动放弃环境一致性。
