composer.lock 文件是决定安装版本的最终依据，它记录精确版本、哈希值和 dist URL，使 composer install 可重复、安全；而 composer.json 仅定义版本范围。

靠 composer.lock 文件，不是靠 composer.json。 它才是决定“装什么版本”的最终依据，composer.json 只是描述“大概想装什么范围”。

为什么 composer install 比 composer update 更安全

执行 composer install 时，Composer 会跳过版本解析，直接读取 composer.lock 中记录的每个包的精确版本、哈希值和 dist URL，然后原样安装。哪怕某个包昨天发布了 v2.1.0，只要锁文件里写的是 v2.0.3，它就只装 v2.0.3。

• composer update 会重新计算整个依赖树，可能升级多个间接依赖，引入未测试的变更
• CI/CD 流水线、生产服务器、新同事拉代码后，必须用 composer install，不能用 composer update
• 如果 composer.lock 不存在（比如首次克隆项目），composer install 会自动触发一次 update 并生成锁文件——这个行为不可禁用，但你可以立刻 git add composer.lock 并提交

require-dev 不是“可选”，而是“环境开关”

开发工具（如 phpunit/phpunit、phpstan/phpstan）必须放在 require-dev 字段，否则它们会进入生产环境。

Discussion Composer

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

下载

• 本地开发：运行 composer install，默认安装 require + require-dev
• 生产部署：必须加 --no-dev 参数，例如 composer install --no-dev --optimize-autoloader
• 从 Composer 2.5 开始，如果 composer.lock 里有 require-dev 包，但你用了 --no-dev，Composer 不会报错；但如果 composer.lock 缺少 composer.json 中声明的 require 包，install 会直接失败——这是强制一致性校验

哪些操作会悄悄破坏一致性

看似无害的操作，可能让团队成员或部署环境拿到不同依赖。

• 手动编辑 composer.lock：哈希不匹配会导致安装失败，且难以追溯改动来源
• 只提交 composer.json 却忽略 composer.lock：这是最常见也最致命的疏忽
• 在生产机上运行 composer update：相当于绕过锁文件，等于把“保险锁”撬开了再重装一把
• 用 composer require package-name 后没提交 composer.lock：新包版本可能因时间差而不同，尤其当别人也在更新依赖时

真正起作用的从来不是“大家记得要怎么做”，而是 composer.lock 是否存在、是否被提交、是否被严格遵循——它不依赖人，只依赖 Git 和命令习惯。