composer install严格按composer.lock安装确定版本，确保环境一致；composer update忽略lock文件，重新解析composer.json并更新依赖，可能引入不兼容变更。
Composer 不是“装上就能用”的工具，它默认行为会踩坑——比如 composer install 严格按 composer.lock 还原，而 composer update 会无视 lock 文件重新解析依赖树，线上直接跑 update 很可能炸掉。
为什么 composer install 和 composer update 必须分清
这是最常混淆的两个命令，本质完全不同：
-
composer install：只读composer.lock，把里面锁定的每个包、每个精确版本（含哈希）原样下载到vendor/。没有composer.lock就报错Could not find a composer.json file（实际是缺 lock 或 json，但错误信息容易误导）。 -
composer update：完全忽略composer.lock，重新读composer.json的版本约束（如"monolog/monolog": "^3.0"），联网查 Packagist，找满足条件的最新版，再递归解所有传递依赖，最后重写composer.lock。 - CI/CD 流水线或线上部署必须用
composer install --no-dev，否则开发依赖（如 PHPUnit）也会被装进去，增大攻击面且浪费资源。
composer require 添加依赖时的版本写法陷阱
不写版本号或写错符号，会导致后续升级不可控：
- 直接运行
composer require monolog/monolog：默认加^3.0.0（当前最新稳定主版本），看似省事，但团队里有人本地跑过update后，composer.lock就可能升到3.5.0，别人install却拿到3.0.0—— 表面一致，实则行为差异可能藏 bug。 - 想锁死小版本（如只允许
3.4.x），应显式写composer require monolog/monolog:3.4.*；想兼容主版本但禁大升（如不进4.0），用^3.4比~3.4更稳妥（~3.4等价于>=3.4.0 ，而 <code>^3.4是>=3.4.0 ，二者在此场景相同，但 ^ 更通用）。 - 引入内部私有包时，如果没配自定义仓库（
repositories），require会直接报Could not find package xxx，不是网络问题，是 Composer 根本没去你公司 GitLab 查。
autoload 配置不生效？90% 是路径或命名空间没对齐
写了 "autoload": {"psr-4": {"App\": "src/"}} 却 still get Class 'App\Foo' not found，问题往往不在 Composer：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
立即学习“PHP免费学习笔记（深入）”；
- 类文件路径必须严格匹配：
src/Foo.php对应class Foo，src/Service/Bar.php对应class Service\Bar；如果文件在src/app/Foo.php但 namespace 是App，就找不到。 - 改完
composer.json的 autoload 后，必须手动执行composer dump-autoload -o（-o表示优化，生成静态映射表，提速明显）；只改配置不 dump，自动加载器根本不知道新规则。 - 如果项目入口（如
index.php）没写require __DIR__ . '/vendor/autoload.php';，第三方包能用，自己写的类一定报错——这个 require 是铁律，不能省。
国内环境不配镜像，composer install 可能卡死在 “Loading composer repositories”
Packagist.org 官方源在国内直连极慢，甚至超时中断，这不是 Composer 本身问题，是网络策略导致：
- 全局配置阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/；配置后所有项目都走镜像，无需重复设置。 - 如果公司用私有 Packagist（如 Satis 或 Private Packagist），必须在
composer.json里显式声明repositories，且 type 设为composer，url 填对，否则require私有包时会 fallback 到官方源并失败。 - 某些共享主机禁用
proc_open()，composer update会卡住不动或报proc_open(): fork failed；这种环境只能本地装好vendor/和composer.lock，再整体上传，别指望服务器上跑 update。
真正难的不是命令怎么敲，而是理解每个命令背后的数据流：json 定义意图，lock 锁定事实，vendor 是快照，autoload 是路由表。漏掉任意一环，依赖管理就从自动化退化成手工填坑。
