根本区别在于：composer install 严格按 composer.lock 安装精确版本，确保环境一致；composer update 忽略 lock，重新解析 composer.json 的版本约束并升级依赖、更新 lock 文件。
composer install 和 composer update 的区别到底在哪
根本区别在于：前者按 composer.lock 安装**精确版本**，后者按 composer.json 中的版本约束**重新解析并升级**依赖。
常见错误现象是：本地开发用 composer update 装了新版本，但上线后运行 composer install 却报错——因为 composer.lock 没提交，或被忽略，导致生产环境装的是旧版甚至缺失的依赖。
- 团队协作时，
composer.lock必须提交到 Git，否则无法保证环境一致 -
composer install在没有composer.lock时会退化为composer update行为（但不生成 lock 文件），这极易引发隐性不一致 -
composer update monolog/monolog只更新指定包，但会连带更新其子依赖——不是“只动这一行”，而是重跑整个依赖图谱
autoload 配置写错会导致类找不到，但报错不提示 autoload 问题
PHP 报错通常是 Class 'EasyUtilsStr' not found，而不是 “autoload 配置有误”。很多人花半小时查命名空间拼写，却漏看 composer.json 里 psr-4 映射路径是否少写了 src/ 或斜杠方向不对。
典型错误配置：
{
"autoload": {
"psr-4": {
"EasyUtils\": "src/EasyUtils/"
}
}
}
但如果实际文件结构是 src/Str.php（没嵌套 EasyUtils/ 目录），就必须改成：
"EasyUtils\": "src/"
- 路径必须是相对于项目根目录的，不能用
./src/或../src/ - 修改
autoload后，必须运行composer dump-autoload才生效，install/update不自动触发此步 - 使用
composer dump-autoload -o生成优化版加载器，适合生产环境，但开发中建议先不用-o，便于调试
require-dev 里的包为什么在生产环境还被加载
因为 autoload-dev 配置默认也会被 vendor/autoload.php 加载——只要它存在，不管是否启用 --no-dev。
也就是说：composer install --no-dev 只跳过安装 require-dev 下的包，但不会屏蔽 autoload-dev 的自动加载规则。
- 如果你把测试工具类（如
EasyUtilsTestsStrTest）放在autoload-dev里，又在生产代码中不小心use EasyUtilsTestsStrTest，就会在生产环境直接报错 - 安全做法是：把
tests/目录彻底排除在autoload和autoload-dev之外，仅靠 PHPUnit 自己的 autoloader 加载 - 检查是否误启用了 dev autoload，可临时删掉
autoload-dev块，再运行composer dump-autoload，看是否还报测试类找不到
私有包无法 install？先确认镜像源和认证方式
报错 Could not find package xxx/private-package at any version，90% 不是包不存在，而是 Composer 根本没去你配的私有源找。
Composer 默认只查 Packagist，私有仓库必须显式声明。常见配置遗漏点：
- 没在
composer.json里加repositories块，或类型写成vcs却没填url - Git 私仓需要 token 认证，但没配
auth.json，或 token 权限不足（比如只读 token 无法访问 private repo） - 公司内网镜像源地址写错，比如漏了
/packages.json后缀，或用了 HTTP 而非 HTTPS
验证方式：运行 composer config --list | grep repos 看仓库是否已注册；再用 composer show xxx/private-package 测试能否查到元信息。
