指定精确版本号如composer require vendor/package:1.2.3会严格锁定版本，composer.json中写入"vendor/package": "1.2.3"，update不升级；-dev后缀按分支处理，不稳定；^和~控制update时的兼容升级范围。
composer require 时如何指定精确版本号
直接写死版本号是最简单可靠的锁定方式，适用于你明确知道哪个版本稳定可用的场景。
- 用
composer require vendor/package:1.2.3会安装且在composer.json中写入"vendor/package": "1.2.3"—— 这是严格锁定，composer update不会升级 - 注意：如果包本身不带
dist信息或未发布到 Packagist，Composer 可能报错Could not find package vendor/package，此时需确认包名拼写、是否私有源、是否已配置repositories - 带
-dev后缀（如dev-main）不是语义化版本，不能被^或~解析；它会被当作分支名处理，composer update可能拉取最新提交，实际不具备稳定性
使用 caret（^）和 tilde（~）控制兼容性范围
这两个符号定义的是“允许自动升级的上限”，不是“最低要求”——它们影响的是 composer update 的行为，而非首次安装。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
^1.2.3≈>=1.2.3 ：允许补丁和次要版本升级，但跨主版本会拒绝（比如不会升到 <code>2.0.0） -
~1.2.3≈>=1.2.3 ：只允许补丁升级，更保守；适合对次要变更敏感的依赖 - 常见陷阱：
^0.1.0实际等价于>=0.1.0 ，因为 <code>0.x主版本被视为不稳定，^在0.x下收缩得比预期更紧 - 运行
composer show vendor/package可查看当前解析出的实际版本和约束规则，验证是否符合预期
用 --no-update 避免意外升级已有依赖
当你只想修改 composer.json 中的版本约束，又不想立刻触发安装或更新其他包时，这个参数很关键。
-
composer require vendor/package:^2.1.0 --no-update只改 JSON 文件，不执行下载或重装 - 后续可手动运行
composer update vendor/package单独更新该包，避免composer update全局扫描引发的连锁升级 - 若跳过
--no-update直接执行require，Composer 默认会install或update，可能把其他依赖也带到新版本，破坏现有兼容性
锁定生产环境依赖：composer install --no-dev --prefer-dist
版本范围写进 composer.json 只是声明，真正起效靠 composer.lock —— 它记录了每个包的确切版本和哈希值。
- CI/CD 或部署时务必用
composer install --no-dev --prefer-dist，确保读取composer.lock而非重新解析composer.json - 如果项目里删掉了
composer.lock，再跑composer install就会按composer.json里的范围重新计算版本，结果可能和之前不同 - 团队协作中，
composer.lock必须提交进 Git；忽略它等于放弃版本锁定能力
composer.lock 文件，不是 composer.json 里的约束字符串。改完 require 后忘记 commit lock，或者部署时没校验 lock 是否存在，才是线上环境版本漂移最常见的原因。
