Composer最佳实践核心是严格区分composer install（按lock文件精确安装，用于CI/CD和生产）与composer update（重算依赖树，仅限人工审查后升级），require与require-dev须物理隔离，lock文件必须提交且与json语义一致，生产部署需用--no-dev--optimize-autoloader--classmap-authoritative组合。
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 的边界必须物理隔离
错放不仅浪费磁盘和内存，更会引发运行时冲突或安全风险。
- 进
require的，必须是运行时真正需要的库：比如doctrine/dbal（迁移必需）、guzzlehttp/guzzle（HTTP 客户端） - 进
require-dev的，仅限开发、测试、构建阶段用到的工具：比如phpunit/phpunit、laravel/pint、roave/security-advisories（它本身不提供代码，只做安装拦截） -
composer install --no-dev会跳过require-dev，但某些功能（如日志驱动切换）若靠 dev/require 拆分来实现，会导致线上行为异常 —— 应优先通过配置控制，而非依赖位置 - 本地跑通但测试环境报
Class not found？先检查composer.lock是否被.gitignore忽略，或是否有人没提交它 —— 这不是“可能出问题”，是“一定出问题”
autoload 优化不能只图快，得看环境
--optimize-autoloader 和 --classmap-authoritative 不是“加了就快”，而是有明确分工和使用边界。
-
composer dump-autoload -o：生成静态类名→路径映射表（vendor/composer/autoload_classmap.php），PHP 7.4+ 下还能进 opcache —— 开发和生产都该开 -
composer dump-autoload -a：启用权威模式，告诉自动加载器“映射里没有，那就真没有”，彻底跳过文件系统扫描 —— **只适合部署或 CI 构建，开发环境绝对不要加**，否则新增类不生效 - 线上构建黄金组合：
composer install --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative - 本地开发频繁加类又不想每次
dump-autoload？加-o就够了；别加-a，否则热重载失效
镜像、缓存、Xdebug 这三件事不调，Composer 就永远慢
慢的从来不是 Composer 本身，而是你让它在错误的条件下运行。
- 关掉 Xdebug：
php -d zend_extension= composer install临时禁用，或配个不含 Xdebug 的 CLI PHP —— 它会让 Composer 变慢 3–5 倍 - 换国内镜像源：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/—— 海外服务器可换 Laravel China 镜像 - 跳过开发依赖：
composer install --no-dev——phpunit、larastan等大包，生产环境根本用不上，省掉 30–60% 时间 - 缓存目录别挂到 NFS 或 Docker volume 上，
"cache-dir": "/tmp/composer-cache"更稳；CI 中要显式缓存~/.composer/cache，并用composer.lock的 hash 当 cache key
最常被忽略的点：composer.lock 必须和 composer.json 同时提交，且两者需语义匹配 —— 比如 lock 文件里的 platform 配置要和 json 里 config.platform.php 一致。否则，CI 构建失败、本地与线上行为不一致，都是必然结果，不是概率事件。
