composer.lock 文件由 composer install 自动生成并隐式锁定依赖版本，其存在即生效；composer update 才会重新解析依赖并生成新 lock，更新后必须提交至 git 以确保可重现性。
composer.lock 文件不是手动编辑的，而是由 composer install 自动生成的
很多人误以为要“执行”某个命令来“锁定版本”，其实 Composer 的依赖锁定是隐式行为：只要项目根目录存在 composer.lock 文件，composer install 就会严格按它安装，不查 composer.json 中的版本约束。而 composer update 才会忽略 lock 文件、重新解析依赖并生成新 lock。
所以所谓“执行锁定”，本质是确保 lock 文件存在且最新——这通常发生在首次安装或更新后。常见错误现象包括：
- 团队成员运行
composer install却装出不同版本，大概率是有人提交了过期或缺失的composer.lock - CI 环境报错 “Your lock file does not contain the required package”，说明
composer.json有新增依赖但没运行composer update更新 lock
用 composer update 更新 lock 文件时，必须明确指定范围
直接运行 composer update 会升级所有依赖（含子依赖），极易引入破坏性变更。生产环境应避免无约束更新。
推荐做法是只更新明确需要的包，并保留其余依赖版本不变：
- 更新单个包：
composer update monolog/monolog - 更新多个包：
composer update doctrine/dbal symfony/console - 更新某类包（如仅 dev 依赖）：
composer update --dev - 禁止 major 版本升级（更安全）：
composer update --with-dependencies配合^或~约束
注意：composer update 后必须提交新的 composer.lock 到 Git，否则锁定失效。
composer install --no-dev 不改变 lock 文件，但会跳过 dev 依赖安装
这个命令常被误解为“锁定生产环境依赖”，其实它只是按现有 composer.lock 安装，且过滤掉 require-dev 中的包。它不会生成或修改 lock 文件，也不校验 composer.json 是否与 lock 一致。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
典型使用场景：
- 部署到生产服务器时，避免安装测试/调试类库（如 phpunit、symfony/debug-bundle）
- CI 构建中加速安装流程
如果 lock 文件里本就包含 dev 依赖，--no-dev 只是跳过它们；但如果 lock 文件已由 composer install --no-dev 生成（极少见），那它本身就缺 dev 包记录——这种情况应避免，lock 文件应始终反映完整依赖图。
CI/CD 中必须用 composer install，而不是 composer update
很多构建脚本错误地在 CI 中执行 composer update，导致每次构建都可能拉取新版依赖，破坏可重现性。正确流程是：
- 开发阶段：改
composer.json→ 运行composer update xxx→ 提交更新后的composer.lock - CI 阶段：检出代码 → 运行
composer install（不带--no-interaction以外的参数）→ 严格按 lock 安装
额外提醒：若 CI 报 The lock file does not contain require-dev information，说明 lock 文件是用 --no-dev 生成的，需重生成完整 lock 并提交。
真正关键的不是“怎么锁定”，而是谁负责更新 lock、何时更新、是否经过测试——这些没法靠一个命令解决，得靠流程卡点。
