如何通过Composer优化开发流程，提高工作效率？

本文共计1172个文字，预计阅读时间需要5分钟。

Composer 不是装完就完的工具，它的最佳实践是直接决定项目能否长期稳定协作、CI 是否准时通过、线上是否半夜报警。

用错一个命令、漏提一个文件、多加一个 --dev，都可能在两周后让新人的 clone 失败，或让 CI 构建卡在 autoload 阶段。

composer install 和 composer update 必须分清场景

这不是语义区别，而是环境控制权的归属问题。

• composer install：只读 composer.lock，装里面记录的**确切版本**。CI/CD、生产部署、新同事首次 setup —— 唯一该用的命令
• composer update：忽略 composer.lock，按 composer.json 重算整个依赖树。它会改锁文件，且不保证兼容性 —— 只应在明确要升级某个包、且已人工审查变更时使用
• 首次运行 composer install 时若无 composer.lock，它会自动 fallback 成 update 并生成锁文件 —— 这等于绕过团队共识。建议提前 git commit 一个空锁文件，或由负责人统一生成并提交
• CI 脚本里一旦出现 composer update，就等于把版本控制权交给了网络和时间 —— 凌晨告警大概率由此而来

require 和 require-dev 的边界必须物理隔离

错放不仅浪费磁盘和内存，更会引发运行时冲突或安全风险。