生产环境必须用 composer install 配合预构建的 composer.lock，禁用 composer update；因后者会重算依赖、破坏版本锁定，引发静默变更、兼容性问题及不可重现构建。

生产环境不能直接运行 composer update，必须用 composer install 配合预构建的 composer.lock —— 这是底线，不是建议。

为什么线上绝不能跑 composer update

它会丢掉 composer.lock，重新从 Packagist 拉取满足 composer.json 约束的最新版本，哪怕只是 7.9.1 → 7.9.2，也可能触发静默行为变更：HTTP 超时缩短、日志字段改名、断言逻辑收紧。本地和 CI 跑得过，上线后接口超时或类加载失败，就是这么来的。

• CI/CD 流水线若误写成 composer update，每次构建拉的依赖版本都可能不同，破坏可重现性
• composer update --no-dev 仍会重算整个依赖图，不是“安全升级”，是“放弃锁定”
• 哪怕只升一个包，没加 --with-all-dependencies，它的间接依赖（如 symfony/http-foundation）可能卡在旧版，PHP 8.2 下直接报 Class not found

composer install 在线上怎么用才真安全

线上唯一合法操作是 composer install，但它必须满足四个硬条件，缺一不可：

• 部署包里已包含完整、匹配的 vendor/ 目录（推荐）或至少有 composer.lock 文件
• composer.lock 必须和当前 Git 分支/Tag 严格对应，且修改时间早于部署时间戳
• 命令必须带 --no-dev --optimize-autoloader --classmap-authoritative --no-interaction --prefer-dist
• 执行前确认 PHP 版本、扩展（如 mbstring、openssl）与构建环境一致，否则 composer install 会当场报错退出

漏掉 --classmap-authoritative？autoload 可能 fallback 到 PSR-4 扫描，性能掉一截；没 --optimize-autoloader？类加载慢 20%+；少 --no-dev？生产机装了 PHPUnit，等于给攻击面开后门。

Discussion Composer

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

下载

更新特定包时的最小影响操作

想升 monolog/monolog 或 guzzlehttp/guzzle？别全量重算，精准控制范围：

• 包名必须已在 composer.json 的 require 或 require-dev 中声明，写成 monolog（漏 /monolog）会报 Package "monolog" not found
• 只升自身： composer update monolog/monolog —— 它的依赖（如 psr/log）仍按 composer.lock 里的 SHA 安装
• 连带直系依赖：加 --with-dependencies，升 monolog/monolog + 它显式 require 的包
• 穿透整棵子树：加 --with-all-dependencies，但注意——如果其他包锁死了同一依赖（如 laravel/framework 锁 symfony/event-dispatcher ^5.4），会直接冲突报错，不是跳过

升级后立刻执行 composer dump-autoload -o，否则新类或命令行工具（如 php artisan）大概率报 Class not found。

主版本跃迁（Laravel 9→10、Symfony 5→6）的真实路径

这不是 composer update 能解决的事。Composer 不会替你做架构决策，它只服从约束。

• 先跑 composer outdated，带 ! 标记的才是主版本变化（如 laravel/framework 9.52 → 10.38 !）
• 手动编辑 composer.json：把 "laravel/framework": "^9.0" 改成 "^10.0"，同步调整 "platform" 和其他强依赖（如 "phpunit/phpunit": "^10.0"）
• 运行 composer why-not laravel/framework:10.* 查谁在拦路（常是第三方插件锁死 symfony/*）
• 确认无阻塞后，再执行 composer update laravel/framework --with-all-dependencies
• ThinkPHP 等框架更敏感：topthink/framework v8 要求 topthink/think-orm ≥ v3.0，裸跑 update 必然错位，必须显式改所有 topthink/ 包的约束再重装

升级后最常被忽略的是 composer.lock 提交和 opcache 清理——前者导致团队协作失效，后者让旧类缓存还在内存里跑着。