必须用不带任何符号的三位数字版本号，如"monolog/monolog": "2.9.1"；写成"^2.9.1"、"~2.9"、"2.9"或"2.9.*"均不算锁死，因允许语义化升级，且"2.9"在不同composer版本中解析不一致。
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 后必须立刻执行什么命令
只改 composer.json 文件，不运行命令，等于没改。Composer 不会自动同步 composer.lock 文件。
正确操作是立即运行：composer update monolog/monolog（把 monolog/monolog 换成你要锁定的包名）。它会重写 composer.lock 并安装指定版本，不影响其他包。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 不能跑
composer update（无参数）：会重新解析整棵树，可能连带升级/降级其他依赖 - 不能删
vendor/后只跑composer install：如果composer.lock还没更新，install仍装旧版 - CI 脚本里用了
composer install --no-lock？等于直接绕过锁定逻辑，部署必出错
为什么本地装对了，上线却还是升了版本
根本原因不是 Composer 不靠谱，而是锁定链断在某个环节：
-
composer.json里没写死，只靠composer.lock—— 但 CI 流水线可能只拉代码不带 lock，或用了--no-lock - 有人本地执行了
composer update再提交，composer.lock变了，但composer.json没同步更新 - 私有仓库配置缺失或镜像源未同步，导致
install时 fallback 到 Packagist，而目标版本在镜像里不存在
验证方式很简单：上线机器上运行 composer show vendor/package，再对比 composer.json 和 composer.lock 里该包的版本是否完全一致。
require 和 require-dev 中指定版本的行为差异
行为完全一致，区别只在依赖用途：运行时需要的放 require，开发期才用的（比如 PHPUnit、PHPStan）放 require-dev。
- 如果在
require-dev里装了symfony/var-dumper，它依然会被 autoload，只是composer install --no-dev会跳过安装 - 两个字段若出现同一包不同版本（比如
require要2.1.0，require-dev要2.2.0），Composer 会报依赖冲突，必须手动协调 - 无论放在哪一栏，只要写的是
"vendor/package": "1.2.3"，就具备同等锁定效力
最易被忽略的一点：composer.lock 是结果，composer.json 是声明；声明没写死，结果就不可控——尤其在跨环境、跨团队、跨 CI 工具时，这点几乎必然暴露。
