必须用不带任何符号的三位数字版本号，如"monolog/monolog": "2.9.1"；写成"^2.9.1"、"~2.9"、"2.9"或"2.9.*"均不算锁死，因允许语义化升级；改完需立即运行composer update monolog/monolog同步lock文件，否则无效。
composer.json 里写什么才算真正锁死一个包
必须用不带任何符号的三位数字版本号，比如 "monolog/monolog": "2.9.1"。写成 "^2.9.1"、"~2.9"、"2.9" 或 "2.9.*" 都不算锁死——这些写法都允许 Composer 在语义化版本规则内自动升级。
特别注意："2.9" 在不同 Composer 版本中解析行为不一致：2.0+ 默认补为 2.9.0，但旧版可能当 2.9.x 处理；别赌兼容性，直接写全三位。
-
"phpunit/phpunit": "9.6.15"✅ 真锁定 -
"phpunit/phpunit": "dev-main#abc1234"✅ 分支 + commit hash 也算（但仅限调试） -
"phpunit/phpunit": "dev-main"❌ 每次 update 都拉最新 commit，完全漂移
改完 composer.json 后必须立刻执行什么命令
只改 JSON 文件，不运行命令，等于没改。Composer 不会自动同步 lock 文件。
正确操作是立即运行：composer update monolog/monolog（把 monolog/monolog 换成你要锁定的包名）。它会重写 composer.lock 并安装指定版本，不影响其他包。
- 不能跑
composer update（无参数）：会重新解析整棵树，可能连带升级/降级其他依赖 - 不能删
vendor/后只跑composer install：如果composer.lock还没更新，install 仍装旧版 - CI 脚本里用了
composer install --no-lock？等于直接绕过锁定逻辑，部署必出错
为什么本地装对了，上线却还是升了版本
根本原因不是 Composer 不靠谱，而是锁定链断在某个环节：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 改了
composer.json，但忘了运行composer update vendor/package→composer.lock仍是旧的 -
composer.lock没提交进 Git → 新机器或 CI 执行composer install时，因 lock 缺失而退化为按 JSON 重解析 - 部署脚本写了
composer update而非composer install→ 它根本不看 lock，只认 JSON 的约束范围 - 有人手动删了
composer.lock，又只跑composer install→ 等同于执行一次全量composer update
验证是否生效：运行 composer show monolog/monolog，输出必须只有一行 versions : 2.9.1；再跑一次 composer update monolog/monolog，若提示 Nothing to install or update，才算真正锁住。
间接依赖怎么防漂移
你写的 require 只锁直接依赖，guzzlehttp/guzzle 或 psr/log 这类间接依赖，由上游包决定。它们容易在 composer update 时悄悄升级，引发 Class not found 或 Method not found。
目前最可靠、无副作用的方式是用 conflict 字段硬控：
{
"conflict": {
"guzzlehttp/guzzle": ">=8.0.0",
"psr/log": ">=3.0.0"
}
}
这样 Composer 解析阶段就会拒绝掉你不想要的版本，而不是等装完再 patch。它兼容所有 Composer 2.x/3.x 版本，且不会影响正常安装流程。
注意：conflict 不是“推荐不装”，而是“强制禁止”——只要依赖树里出现冲突版本，composer update 或 install 都会直接报错退出。
