composer require 找不到包主因包名拼写错误、源不可用或稳定性不匹配；require 为运行时依赖，require-dev 仅开发期使用且上线排除；手动改 composer.json 后通常用 install，update 会重解析依赖树；autoload 修改后须 dump-autoload。
composer require 添加依赖时为什么找不到包
常见现象是执行 composer require vendor/name 后报错 Could not find package vendor/name，本质不是命令写错，而是包名拼写、仓库源或稳定性设置不匹配。
- 检查包名是否完整准确——比如
monolog/monolog不能简写成monolog；大小写敏感，guzzlehttp/guzzle不是GuzzleHttp/Guzzle - 确认当前 Composer 源是否可用：
composer config repo.packagist.org.url应为https://packagist.org；国内用户常因源被墙导致超时或 404，可临时切回官方源：composer config -g repo.packagist.org.url https://packagist.org - 包默认只拉取
stable版本，若想装dev-main或alpha版，得显式加--stability=dev --prefer-source，否则会静默跳过
require 和 require-dev 的区别到底在哪
区别不在“能不能用”，而在“什么时候装”和“会不会打进生产环境”。require-dev 里的包不会被 composer install --no-dev 安装，而线上部署几乎都会加这个参数。
-
require：运行时必需，比如symfony/http-kernel，没它项目直接报Class not found -
require-dev：仅开发期需要，比如phpunit/phpunit、friendsofphp/php-cs-fixer，CI/CD 构建测试阶段才用，上线前应排除 - 误把工具类库（如
psy/psysh）放require，会导致生产环境多装几十 MB 无用代码，还可能引入安全风险
composer.json 手动改完后要不要 run update
手动编辑 composer.json 增删依赖后，composer install 通常够用；只有当你改了版本约束（比如从 "^2.0" 改成 "^3.0"）或想强制刷新锁文件时，才需要 composer update。
-
composer install严格按composer.lock安装，哪怕composer.json里版本范围更宽，也不会升级 -
composer update会忽略composer.lock，重新解析所有依赖树，可能导致意外升级——比如某间接依赖从1.2.3升到2.0.0，破坏兼容性 - CI 环境务必用
composer install，而不是update，否则每次构建结果不可控
autoload 自动加载配置写错的典型表现
写完 "autoload": { "psr-4": { "App\": "src/" } } 却提示 Class AppFoo not found？问题往往出在命名空间声明、目录结构或未 dump-autoload。
- PHP 文件顶部必须有
namespace App;，且文件路径必须严格对应：比如AppFoo对应src/Foo.php，不能是src/foo.php（Linux 下大小写敏感） - 改完
autoload段后，必须运行composer dump-autoload，否则新规则不生效；加-o参数可生成优化后的映射表，提升加载速度 - 避免混用
psr-4和classmap：前者靠约定，后者靠扫描，同时存在易冲突；调试时可加--verbose看 Composer 实际加载了哪些路径
最常被忽略的是 composer.lock 文件的语义——它不是缓存，而是依赖快照。删了它再 install，等同于重走一遍 update，线上千万别手抖。
