composer require是最安全、最标准的引入方式，它自动校验版本合法性、更新composer.json与composer.lock、触发scripts并生成autoload映射，而手动编辑require后仅运行install会跳过校验、缺失元信息、不执行脚本且autoload不生效。
Composer 不是“安装工具”，而是依赖声明+解析+加载的一整套机制；直接运行 composer require 是最安全、最不易出错的起点。
composer require 为什么比手动改 composer.json 更可靠
手动编辑 composer.json 容易写错版本约束格式（比如把 ^2.0 写成 2.0.*），或漏掉逗号导致 JSON 解析失败，composer install 会直接报错 Your requirements could not be resolved。而 composer require vendor/package-name 会自动校验包名是否存在、版本是否合法，并同步更新 composer.json 和 composer.lock。
- 它强制走 Packagist 的元数据验证，避免拼错包名（如把
guzzlehttp/guzzle写成guzzle/guzzle） - 默认使用
^语义化版本（例如^7.0允许安装7.0.0到7.999.999），比写死"7.0.0"更健壮 - 如果项目已有
composer.lock，require会按锁文件策略合并新依赖，不会意外升级其他包
vendor/autoload.php 怎么用才不报 Class not found
引入 vendor/autoload.php 是启用 PSR-4 自动加载的前提，但常见错误是路径写错或执行时机不对。
- 必须在所有业务代码之前引入，且只能引入一次（重复
require_once没问题，但require会报错） - 路径要相对于当前脚本位置，比如入口文件在
public/index.php，就得写require __DIR__.'/../vendor/autoload.php'; - 如果类仍找不到，先确认该包是否真被安装：
ls vendor/vendor-name/；再检查包自身是否声明了 autoload 配置（多数主流包都有，但某些老旧私有包可能没配 PSR-4）
composer install 和 composer update 的本质区别
composer install 是“还原”，composer update 是“求解”——这个差异直接影响部署稳定性和协作一致性。
立即学习“PHP免费学习笔记（深入）”；
- 项目存在
composer.lock时，install只按锁文件精确安装，不查 Packagist，速度快、结果确定 -
update会重新解析composer.json中所有版本约束，尝试找最新兼容版本，可能升级次要版本甚至补丁版本，带来意外交互风险 - CI/CD 或生产环境部署必须用
install（且确保--no-dev），否则update可能装上开发期才需要的phpunit或php-cs-fixer
国内用户绕不开的镜像和内存问题
Packagist 官方源在国外，直连常超时或卡住；同时 Composer 解析依赖树时内存占用高，尤其含大量依赖时。
- 全局换源：运行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（阿里云镜像，稳定） - 临时换源不影响全局配置：加
-vvv参数可看到实际请求地址，用于排查是否生效 - 内存不足报错
Allowed memory size of XXX bytes exhausted？在命令前加COMPOSER_MEMORY_LIMIT=-1，或改 PHP CLI 的memory_limit
真正容易被忽略的是 composer.lock 文件本身——它不是中间产物，而是团队协作和线上部署的契约。删掉它再跑 install，等同于放弃版本控制；提交时漏掉它，等于让别人自己猜依赖版本。
