composer install 和 update 的核心区别是是否读取并遵守 composer.lock 文件：install 严格按 lock 安装确定版本，确保环境一致；update 忽略 lock，重算依赖并更新锁文件，可能引入不兼容变更。
别背命令缩写，先搞清 install 和 update 的语义边界——用错一个，线上就可能挂。
composer install 和 composer update 到底该用哪个
不是“快不快”的问题，是“对不对”的问题。
-
composer install：只读composer.lock，装里面记录的确切版本号，适合 CI/CD、生产部署、新同事拉代码后启动项目 -
composer update：忽略composer.lock，按composer.json重算依赖树，会改锁文件——只应在本地调试兼容性、升级主包或验证安全补丁时运行 - 首次执行
composer install时若无composer.lock，它会自动 fallback 到update并生成锁文件，这等于绕过团队约定；建议初始化后立即git add composer.lock - CI 脚本里一旦出现
composer update，就等于把构建结果交给网络延迟和上游包发布时间，凌晨告警大概率由此而来
加依赖必须用 composer require，但参数选错等于埋雷
手写 composer.json 再 install 是低效且易出错的路径。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 开发工具类（如
phpunit/phpunit、phpstan/phpstan）必须加--dev，否则进require区，上线也会加载 - 指定版本要带约束符：
composer require guzzlehttp/guzzle:^7.5（推荐），而不是7.5（会被解释为严格等于7.5.0，基本匹配不到） - 只想改
composer.json不安装？加--no-update，比如composer require symfony/console --no-update，后续可单独composer update symfony/console - 遇到
Your requirements could not be resolved且确认是 PHP 版本限制（如本地 PHP 8.3，但包声明只支持 8.2），可临时加--ignore-platform-reqs强装——但别提交，CI 禁用
autoload 不生效？先跑 composer dump-autoload
90% 的 Class not found 报错，不是命名空间或路径错了，而是 autoloader 没刷新。
- Composer 不监听文件增删，新增 PSR-4 目录、改了
autoload配置、甚至改了files类型的全局函数文件，都必须手动运行composer dump-autoload - 开发中频繁加类又不想每次
update，加-o生成 classmap：composer dump-autoload -o，比默认 PSR-4 查找快不少 - 用了
filesautoload（比如src/functions.php），改了那个文件也得重dump，否则不会生效
composer global require 装的命令为什么找不到
不是没装上，是 shell 找不到它的可执行文件位置。
-
composer global require laravel/installer装的是全局工具，但它不等于系统级命令——它依赖 Composer 自己管理的 bin 目录是否在$PATH里 - 查路径：
composer global config bin-dir --absolute，然后确认该路径已加入$PATH - 常见陷阱：不同 shell（zsh/bash）配置文件不同，改完记得
source ~/.zshrc或对应文件
最常被忽略的其实是 composer.lock 的存在感——它不是缓存，是契约；不是可选，是必需。一旦你开始靠 update 来“修 bug”，说明环境共识已经松动了。
