Composer install装不出一致包的根本原因是锁文件缺失或未提交，导致CI/CD fallback至update行为，依赖解析结果随Packagist状态和PHP环境变动而非团队共识；composer.lock必须纳入Git且CI应校验其存在。
Composer 不是“装完就能用”的工具，它是一套依赖管理契约的执行引擎。项目能稳定运行，靠的不是 composer install 这条命令本身，而是你是否让 composer.json、composer.lock 和自动加载规则三者达成一致。
为什么 composer install 有时装不出和本地一样的包？
根本原因是锁文件缺失或未被提交。CI/CD 流水线里如果只跑 composer install 却没校验 composer.lock 是否存在、是否最新，就会 fallback 到 composer update 行为——即重新解析整个依赖树，结果取决于当前 Packagist 状态和平台环境（比如 PHP 版本），而非团队共识。
- 新项目首次
composer install时若无composer.lock，Composer 会自动执行一次update并生成锁文件，这等于绕过版本协商流程 -
composer.lock必须纳入 Git，且不能出现在.gitignore中；CI 脚本开头应加test -f composer.lock || exit 1防止漏检 - 线上部署必须用
composer install --no-dev --optimize-autoloader，否则可能加载开发依赖或使用慢速动态查找模式
composer require 参数写错会导致什么后果？
写错约束符或漏掉 --dev，会让依赖关系从源头失真。Composer 不会报错，但后续所有环节都会继承这个错误：锁文件记录错误版本、自动加载路径错位、CI 构建在不同 PHP 版本下行为不一致。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 开发工具（如
phpunit/phpunit）必须加--dev，否则会被打入require区，上线时也会被加载 - 版本号不带约束符（如写成
7.5）会被解释为严格等于7.5.0，几乎匹配不到任何包；应写^7.5或~7.5.0 - 只想改
composer.json但暂不安装？加--no-update，避免意外触发依赖重算
autoload 不生效，90% 的问题不在命名空间
Class not found 报错，多数情况不是类名写错，而是 autoloader 没刷新或 PSR-4 映射不合理。Composer 的自动加载器不会实时监听文件变化，必须显式重建。
- 修改了类文件路径或命名空间后，必须运行
composer dump-autoload，否则旧映射仍生效 -
"App": "src/"这种宽泛映射会让加载器扫描整个src/目录，包含配置、迁移、模板等非类文件，拖慢性能；应拆分为"App\": "src/App/"+"App\Helpers\": "src/Helpers/" - 生产环境启用
--classmap-authoritative（即composer dump-autoload -a）可跳过文件系统查找，但要求所有类都已收录进 classmap，否则直接报错
依赖冲突时，别急着删 composer.lock
暴力删除锁文件等于放弃版本控制权，可能引入不可逆的兼容性断裂。真正该做的是定位阻塞点，而不是重跑整个依赖树。
- 用
composer prohibits vendor/package查看哪个依赖在阻止目标包安装，输出会明确指出是哪个包的哪个版本约束导致冲突 -
composer diagnose可检测 PHP 版本、缺失扩展（如ext-zip）、权限问题等底层环境缺陷 - 临时绕过平台限制（如 PHP 版本不符）可用
--ignore-platform-reqs，但仅限调试，绝不能提交到 CI 或上线脚本中
最易被忽略的点是：Composer 的工程价值不体现在“能装包”，而在于它强制你把隐式依赖显式声明、把版本决策留痕、把加载逻辑标准化。一旦跳过 composer.lock 提交、混用 install/update、手写 require_once，就等于主动退出这套契约体系。
