composer install装不出新包是因为它只读composer.lock，不解析composer.json；改完json必须运行composer update或composer require更新锁文件，否则install仍按旧锁安装。
composer install 为什么有时装不出你刚加的包？
因为 composer install 根本不读 composer.json 里的新行——它只认 composer.lock。你改了 composer.json，但没跑 composer update 或 composer require，锁文件里就没有那条依赖，install 就当它不存在。
- 常见现象：
composer install后vendor/里找不到新包，Class not found报错 - 根本原因：锁文件未更新，
install不做任何版本求解，只按锁文件“照单发货” - 正确做法：加依赖必须用
composer require vendor/package:^x.y；手改composer.json后，得补一句composer update vendor/package（或全量update） - 陷阱：加了
--no-dev却想装phpunit/phpunit？它在require-dev区，install --no-dev会跳过，update --no-dev也压根不解析它
composer update 真的只动你指定的包吗？
不。默认情况下，composer update vendor/package 会重载整个依赖图，再以该包为锚点重新求解——哪怕你只想升 guzzlehttp/guzzle，psr/http-client、symfony/polyfill 这些间接依赖也可能被连带升级或降级。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 不加
--with-dependencies：子依赖可能“卡在旧版”，导致运行时行为异常（比如 PHP 8.3 下polyfill缺少新函数） - 加了
--with-dependencies：实际改动范围远超预期，尤其当通配符如symfony/*遇上宽泛约束（"^5.4 || ^6.0"），整条链路可能跃迁到 v6 - 安全做法：执行前先跑
composer update --dry-run，看清哪些包会变、升到什么版本 - 生产环境严禁裸跑
composer update：它会联网查 Packagist、触发完整 NP-hard 求解，CI 构建可能卡两分钟，且结果不可复现
为什么 CI/CD 和生产环境必须用 install 而不是 update？
composer install --no-dev 是“复现”，composer update --no-dev 是“重算”——一字之差，构建确定性彻底不同。
-
install --no-dev：跳过require-dev区，且完全绕过依赖求解器；只按composer.lock里写死的哈希、URL、版本号批量下载解压，快、稳、可预测 -
update --no-dev：仍要联网请求 API、校验 PHP 版本/扩展/所有子依赖约束，本质是重跑一遍求解器，只是最后不装 dev 包而已 - CI 失败常见原因：Git 忽略了
composer.lock，或有人删了锁文件再提交 → 其他人install就退化成update，构建结果随网络和镜像状态漂移 - 关键纪律：
composer.lock必须提交到 Git；它不是缓存，是团队协作的契约
没有 composer.lock 时 install 为什么会生成它？
这不是 bug，是设计行为：composer install 的逻辑由锁文件是否存在决定，而非命令本意。
- 有
composer.lock→ 严格按锁安装，不碰composer.json的约束 - 没有
composer.lock→ 自动 fallback 到composer update行为：解析composer.json、跑求解器、生成新锁文件 - 新人克隆项目后首次
install出现锁文件，说明团队流程已断裂——该由负责人统一生成并提交一份标准锁文件 - 注意：首次生成的锁文件，和你本地手动
composer update的结果可能不同，比如对dev-main分支的处理倾向不一致
