有composer.lock就用install，确保环境一致；无lock则需负责人补交——install只读lock装固定版本，用于ci/cd和生产；update忽略lock重算依赖，仅限本地主动升级。
composer install 和 composer update 到底该用哪个
有 composer.lock 文件，就无脑跑 composer install；没有，说明项目初始化流程断了，别急着装，先确认是否该由负责人补提交一份。
composer install 只读 composer.lock，装的是里面写死的版本号，CI/CD、生产部署、新同事 setup 必须用它；composer update 会忽略 composer.lock，重新解析 composer.json 并重写锁文件，只应在本地验证安全补丁、升级主框架（如 Laravel 11）、或调试兼容性时运行。
裸跑 composer update 极易引入子依赖不兼容——比如只升 guzzlehttp/guzzle，但它的 psr/http-client 还卡在 v1.0，运行时报错才去查 changelog 就晚了。
- 首次执行
composer install时若无composer.lock，它会自动 fallback 到update并生成锁文件，这等于绕过团队约定 - CI 脚本里出现
composer update，等于把构建结果交给网络延迟和上游包发布时间，凌晨告警大概率由此而来
加依赖必须用 composer require，但参数错一个就埋雷
手写 composer.json 再 install 是低效且危险的路径：漏逗号、引号不闭合、版本写成 "7.5" 而非 "^7.5"，都会导致后续解析失败或装错版本。
开发工具（如 phpunit/phpunit、phpstan/phpstan）必须加 --dev，否则进 require 区，上线也会加载，徒增内存和启动开销。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
指定版本必须带约束符：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 - 只更新单个包？用
composer update monolog/monolog，加--with-dependencies可连带更新其直系依赖
autoload 不生效？先跑 composer dump-autoload
90% 的 Class not found 报错，不是命名空间错了，是 autoloader 没刷新。Composer 不监听文件增删，新增 PSR-4 目录、改了 autoload 配置、甚至只是改了 files 类型的全局函数文件（如 src/functions.php），都不会自动感知。
必须运行 composer dump-autoload 才能重建映射。开发中频繁加类又不想每次 update，加 -o 生成 classmap：composer dump-autoload -o，比默认 PSR-4 查找快不少。
- 用了
filesautoload（比如src/functions.php），改了那个文件也得重dump，否则不会生效 - 如果项目启用了
classmap-authoritative模式，dump-autoload -o是强制要求，否则类根本不会被加载
vendor 目录和镜像配置这些冷门但致命的点
想把 vendor 换成 libs，或让 phpunit 软链接到项目根目录的 bin 下？直接在 composer.json 的 config 字段里写："vendor-dir": "libs"、"bin-dir": "bin"；二者均需执行 composer install --no-dev 重装，并同步更新自动加载、CI 脚本及 IDE 配置。
不配镜像，composer install 卡在 “Loading composer repositories” 是常态。核心就两条：config.repo.packagist 设为 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}（目前最稳的国内镜像）；如果项目用私有 GitLab，还得加 config.gitlab-domains，比如 ["gitlab.example.com"]，不然 Composer 不知道该走 SSH 还是 HTTPS 认证。
- 切忌在 CI 环境里用
--global配镜像——不同项目可能依赖不同源，全局配置容易串包；优先写进项目composer.json或用auth.json配认证 -
cache-dir、autoloader-suffix、process-timeout这三个配置在 CI 中极易被忽略，但一旦出问题（缓存哈希误判、autoload 冲突、超时中断），排查成本极高
