新项目必须用 composer install，它按 composer.lock 精确还原依赖；composer update 会忽略 lock 文件并升级包，易引发不兼容问题。
Composer install 和 update 到底该用哪个？
新项目拉下来必须用 composer install，不是 composer update。前者按 composer.lock 精确还原依赖版本，后者会无视 lock 文件、重新解析并升级所有包——这在生产环境或协作项目里等于主动引入不兼容变更。
- 本地开发刚 clone 项目？→ 无脑
composer install - 想升级某个包（比如
guzzlehttp/guzzle）到新主版本？→ 先确认composer.json里版本约束改对了，再跑composer update guzzlehttp/guzzle，别全量更新 -
composer.lock被删了或没提交？CI 构建大概率失败，因为不同机器上composer install会装出不同版本
Laravel 项目里 composer.json 的 "require" 和 "require-dev" 怎么分？
区分核心逻辑依赖和开发辅助工具，不是凭感觉，而是看「这个包是否参与运行时请求处理」。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行时必需：如
laravel/framework、spatie/laravel-permission、doctrine/dbal→ 放"require" - 只在本地写代码/测试时用：如
phpunit/phpunit、barryvdh/laravel-debugbar、laravel/pint→ 放"require-dev" - 错误示范：
fakerphp/faker写在require里——它只在 seed 或测试中用，上线后完全不需要，白占内存和安全扫描风险
为什么 vendor/autoload.php 不能手动 require？
Laravel 启动流程里，bootstrap/autoload.php 已经通过 Composer 自动加载机制引入了 vendor/autoload.php。你再手动 require 'vendor/autoload.php' 不仅多余，还会在某些部署场景（如 Docker 多阶段构建）导致路径不存在而报错 failed to open stream: No such file or directory。
- 自定义命令或 Artisan 命令里，直接用
use引入类即可，Composer 自动加载已就位 - 写独立脚本（比如导出数据的 PHP CLI 工具）要单独加载？→ 用
require __DIR__.'/../vendor/autoload.php';，但注意相对路径是否正确，别硬写vendor/autoload.php - 常见坑：在
config/app.php里写require，Laravel 还没启动自动加载器，直接炸
composer dump-autoload 什么时候真有用？
它只刷新自动加载映射，不装包、不改依赖。典型场景就两个：加了新类但没生效，或者改了 PSR-4 的命名空间配置。
- 新建了一个
app/Services/OrderService.php，但AppServicesOrderService找不到？→ 先确认composer.json里"psr-4"配置包含"App\"映射到"app/"，再跑composer dump-autoload - 把类从
app/Helpers移到app/Support，但旧路径还在 autoload 里缓存着？→ 改完composer.json后必须dump-autoload - 别在 CI 里无脑加这句：它解决不了依赖缺失或版本冲突，反而掩盖真实问题
lock 文件的约束力、autoload 的触发时机，以及每个命令背后到底动了哪一层。最常出问题的地方，往往不是命令不会打，而是没看清当前目录下有没有 composer.lock，或者没意识到 require-dev 里的包根本不会进生产环境 vendor。 
