composer install 严格按 composer.lock 还原依赖，确保版本一致；composer update 则忽略 lock 文件，重新解析 composer.json 约束并升级至最新兼容版本，仅限开发环境使用。
composer 命令本身不是“一个功能”，而是 PHP 依赖管理的控制入口——它不直接干活，而是调度安装器、解析器、自动加载器和事件系统协同工作。你敲下的每条命令，本质是在触发 Composer 内部不同阶段的生命周期钩子。
composer install 和 composer update 的行为差异在哪
这是最常混淆的两个命令，区别不在“装不装”，而在“依据谁来装”：
-
composer install：只读composer.lock，严格复现已锁定的版本组合；若无 lock 文件，则先做一次update逻辑生成它 -
composer update：忽略 lock 文件，重新跑 SAT 求解器，从所有源拉取元数据，尝试满足composer.json中的约束并选最新兼容版本 - 生产环境必须用
install，否则会绕过 lock 文件导致不可控升级（比如某天guzzlehttp/guzzle推出不兼容的8.0.0，update就可能悄悄装上） - CI/CD 流水线里写
composer install --no-interaction --prefer-dist是标准做法；update只应在开发机上人工触发，并配合--dry-run预览变更
为什么 vendor/autoload.php 不是“写死”的文件
它由 composer dump-autoload 动态生成，内容取决于 autoload 字段配置和实际存在的类文件。常见误区：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 改了
src/下的命名空间但没运行dump-autoload→ 类找不到，报Class not found - 用了
psr-4却把类放在lib/而非src/→ 自动加载规则不匹配，路径映射失效 - 加了
--optimize（即-o）后，会生成 classmap，跳过文件扫描，但要求所有类必须在autoload配置中显式声明或能被扫描到；漏配就会“有类却加载不到” - 多人协作时，有人提交了新类但忘了
git add src/NewService.php→dump-autoload -o生成的 classmap 里就没有它，本地正常、CI 报错
scripts 字段不是“写 shell 脚本的地方”，而是生命周期代理
composer.json 里的 scripts 不是简单执行 shell 命令，而是绑定到 Composer 内部事件的回调入口。例如：
-
"post-install-cmd": "php artisan optimize"这类写法看似直白，但实际执行时机是install成功后、自动加载器重写完成前——此时vendor/autoload.php还没刷新，artisan可能因类未加载而失败 - 正确做法是用
"post-autoload-dump": "php artisan optimize"，确保自动加载就绪后再调用业务命令 - 自定义脚本如果要访问 Composer 实例（比如读当前 package 名），不能靠
getcwd()或硬编码路径，得通过$event->getComposer()->getPackage()->getName() - 脚本中调用
php命令时，别写死/usr/bin/php，应使用php（让系统 PATH 决定）或$_SERVER['PHP_BINARY']（更可靠）
真正容易被忽略的是：Composer 的“流程感”极强，每个命令背后都是一串不可跳过的内部阶段。跳过 lock、绕过 autoload 生成、在错误事件点执行脚本，看起来省了一步，实则把问题压到了运行时才暴露。
