发布于2026-07-06 阅读(0)
扫一扫,手机访问
先来一个直接结论:composer install 和 composer update 这两个命令的区别,本质上不是手速快慢的问题,而是你对环境是否可控的判断问题。用错一个,线上环境就可能直接崩掉。下面这张图可以帮你快速回忆起它们各自的角色——

无脑跑 composer install。它只读 composer.lock,按照里面写死的版本号安装,确保你本地、提交者、CI 以及生产环境完全一致,不会因为某次上游的小版本发布而炸掉。
composer.lock,install 会自动 fallback 到 update 并生成新的锁文件——这意味着绕过了团队约定。建议初始化后立刻把 composer.lock 加入版本控制。composer update 会忽略 composer.lock,重新解析 composer.json,改锁文件,升级所有满足约束的包。除非你在本地调试兼容性或验证安全补丁,否则别碰它。composer update,等于把构建结果交给网络延迟和上游发布时间。凌晨告警大多由此而来。手写容易漏字段、搞错格式,或者版本约束不带符号,导致后续解析失败或装错版本。必须用 composer require,但参数要到位:
phpunit/phpunit、phpstan/phpstan)必须加 --dev,否则会进 require 区,上线也会被加载。composer require guzzlehttp/guzzle:^7.5(推荐),而不是 7.5(会被解释为严格等于 7.5.0,基本匹配不到)。composer.json 不安装?加 --no-update,比如 composer require symfony/console --no-update。--ignore-platform-reqs 强装——但别提交,CI 里要禁用。真正的原因是 autoloader 没有刷新。Composer 不监听文件增删,新增 PSR-4 目录、改了 autoload 配置、甚至改了 files 类型的全局函数文件,都必须手动运行 composer dump-autoload。
update,可以加 -o:composer dump-autoload -o,生成 classmap,比默认 PSR-4 查找更快。files autoload(比如 src/functions.php),改了那个文件也得重 dump,否则不会生效。--classmap-authoritative:composer dump-autoload --optimize --classmap-authoritative。这不是习惯问题,是 PHP 自动加载机制决定的——它是一次性注册,一旦某个类名被首次引用而未定义,就会触发致命错误,后续的 require_once 补救完全无效。
session_start(); echo 'hello'; require 'vendor/autoload.php'; new Monolog\Logger('app'); ——会报 Cannot send session cache limiter 或 Class 'Monolog\Logger' not found。require __DIR__ . '/vendor/autoload.php';,并且路径一定要用 __DIR__,别用 ./vendor/autoload.php(CLI 和 Web 下相对路径行为不一致)。"classmap": ["lib/", "includes/"],然后跑一次 composer dump-autoload。最后提一个国内开发者每天都要面对的问题:卡在 Loading composer repositories 是常态,不是你网络坏了。换镜像源是唯一解,而且必须全局配置:composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。其他操作都只是浪费时间。