新环境或部署用 composer install，开发中改依赖用 composer update；前者按 lock 文件安装一致版本，后者按 json 重新解析并更新 lock；ci/cd 中须确保 lock 已提交且未被忽略。
composer install 和 composer update 到底该用哪个？
看项目阶段决定：新环境或部署用 composer install，开发中改依赖用 composer update。前者读 composer.lock 装完全一致的版本，后者按 composer.json 重新解析并更新锁文件。
常见错误是 CI/CD 流水线里漏了 ls -la composer.lock 检查步骤，导致缓存命中旧 lock 或压根没生成 lock，结果装出和本地不一致的依赖。尤其在 GitLab CI 或 GitHub Actions 中，必须确保 composer.lock 已提交且未被 .gitignore 排除。
- 上线前务必确认
composer install --no-dev+--optimize-autoloader组合使用 - 本地开发改了
composer.json后，别直接 push，先跑一遍composer update并提交更新后的composer.lock - 如果只想更新某一个包（比如只升
guzzlehttp/guzzle），用composer update guzzlehttp/guzzle，避免连带升级其他包引发意外 break
怎么让 autoload 更快？别只靠 dump-autoload
composer dump-autoload --optimize 确实能生成类映射表，但真正影响性能的是 PSR-4 配置是否合理。如果 "App\": "src/" 下混着大量非类文件（如 config/、migrations/），自动加载器仍会扫描整个目录树。
更有效的方式是拆分 autoload 配置：
- 把核心类路径单独列在
psr-4里，例如"App\": "src/App/" - 用
classmap显式指定已知的单文件类（如src/Helpers/Str.php） - 开发时加
"optimize-autoloader": true到config，生产环境再通过--optimize-autoloader参数触发
顺带一提：composer dump-autoload -a（即 --classmap-authoritative）会让 autoloader 完全跳过文件系统查找，只查 classmap —— 这要求所有类都已被收录进 map，否则会报 Class not found。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
依赖冲突时，先别急着删 lock 文件
运行 composer prohibits package/name 比盲目 composer update 更靠谱。它会列出所有阻止该包安装的依赖及其约束条件，比如输出 your/project v1.0.0 requires monolog/monolog ^1.0 -> satisfiable by monolog/monolog[1.x-dev]，说明是项目自身锁死了旧版。
另一个高频动作是检查平台要求是否匹配：
- 执行
composer diagnose，它会提醒你 PHP 版本、扩展缺失等底层问题 - 若报
Your requirements could not be resolved且涉及php或ext-xxx，加--ignore-platform-reqs只是临时绕过，真实解法是调整composer.json中的"php": "^8.1"或补装扩展 - 手动指定版本时，用
composer require monolog/monolog:^2.0 --with-all-dependencies可强制连带升级其子依赖，比单纯require更彻底
私有包和镜像配置容易被忽略的细节
公司内网用私有 Packagist 或 Satis 时，很多人只配了 repo 地址，却忘了加 "type": "composer"。没有这个字段，Composer 会跳过该源，导致 require 失败。
国内开发者常用阿里云镜像，但要注意全局配置和项目级配置的区别：
- 全局镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，影响所有项目 - 项目级镜像：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g），只作用于当前目录，适合混合公私源的场景 - 镜像不是万能的：某些私有包或带 git submodules 的包，镜像可能无法代理，此时需在
repositories中单独声明"vcs"类型源
最后提醒一句：镜像地址一旦配置，composer show 查包时默认走镜像，但 composer update 仍可能回源拉取 dist 包 —— 如果你发现下载速度没变快，大概率是包本身用了 dist 方式发布，而镜像没同步这部分资源。
