启用 "config": { "lock": true } 可强制校验 lock 文件一致性：若 composer.json 变更而 lock 未更新，install 直接报错退出，杜绝“改需求不更新快照”导致的版本混乱。
团队里依赖版本不一致、本地能跑线上报错、CI 构建失败——90% 是因为没把 composer.lock 当成核心契约，而不是“可有可无的缓存文件”。
为什么 composer install 在不同机器上装出不同版本？
根本不是 Composer “不可靠”，而是有人绕过了 lock 文件的约束：
- 手动执行了
composer update，但没提交新生成的composer.lock -
composer.lock被.gitignore错误排除，或被 Git 误设为 skip-worktree - CI 脚本写了
composer update --no-interaction，以为“自动”就安全——其实它会无视 lock，重算依赖树 - 本地 PHP 版本或 Composer 版本和 CI 不一致（比如 CI 用 Composer 2.5，本地还在 1.10），导致 lock 文件结构不兼容
解决办法不是“教育大家别乱点”，而是让错误操作根本走不通。
怎么让 composer install 拒绝装错版本？
启用 "config": { "lock": true } 配置，这是 Composer 2.2+ 内置的硬性校验开关：
- 只要
composer.json有改动（比如新增了require），但composer.lock没同步更新，composer install就直接报错退出，不给你机会装错 - 它不阻止你升级依赖，只防止“改了需求却没更新快照”这种低级失误
- 旧版 Composer（
把这个配置加进所有项目的 composer.json，比写一百遍文档都管用。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
Git 提交前如何自动拦住漏更新 composer.lock？
靠人眼检查 git status 不现实。用 pre-commit 钩子强制校验：
- 脚本逻辑很简单：如果
composer.json被修改（git status --porcelain | grep '^[AM] composer.json'），就检查composer.lock是否也在暂存区（git ls-files --cached composer.lock） - 没暂存？拒绝提交，并提示
Run "composer update --lock" first - 钩子脚本放项目根目录
.git/hooks/pre-commit，加可执行权限即可生效
这个钩子不依赖全局工具，也不需要每个人都手动安装，开箱即用。
CI/CD 和部署脚本最容易漏掉的关键参数
漏掉 --no-dev 是线上事故高频原因，尤其在 Symfony/Laravel 项目里：
- 不加
--no-dev，composer install会把phpunit、symfony/debug-bundle全装进生产镜像——debug-bundle 可能暴露/_profiler接口，infection的 autoload-dev 规则还可能污染自动加载顺序 - Dockerfile 中应固定写成：
composer install --no-interaction --optimize-autoloader --no-dev - CI 测试环境用完整安装（保留
require-dev），但生产部署脚本必须显式带上--no-dev；别指望COMPOSER_ENV=prod自动生效，它不控制安装行为
真正麻烦的不是参数本身，而是团队对“dev 包是否影响运行时”的认知偏差——有些包看似只是工具，实则通过 autoload-dev 注入了运行时类，一旦混入生产，问题往往延迟暴露。
