composer init 交互式生成 composer.json 最稳妥，可避免手动编写时的语法错误和版本约束误写；支持跳过交互、区分开发依赖、配置国内镜像源等关键操作。
composer init 怎么安全初始化项目配置
直接手写 composer.json 容易漏逗号、引号错位、版本约束写成 7.5（实际被解释为严格等于 7.5.0，几乎匹配不到），用 composer init 交互式生成最稳妥。它会智能预设包名、PHP 版本约束（比如推荐填 php: ^8.1 而非 >=8.1）、作者信息等。
常见问题：
- 中途
Ctrl+C中断可能留下半截 JSON 文件，运行前先ls -la composer.json确认；若要重来，先rm composer.json - 想跳过交互（如 CI 脚本）：加参数
--name=vendor/project --description="My app" --require="php:^8.1" - 开发依赖（如 PHPUnit）必须用
--dev或--require-dev，否则上线时可能误装调试工具
install 和 update 到底该用哪个
composer install 只读 composer.lock，安装里面锁定的**精确版本**，确保本地、测试、生产环境完全一致；composer update 则重新解析 composer.json，按约束拉取最新兼容版，并重写 composer.lock。
关键区别：
- 线上部署、CI 流水线、团队协作——只允许用
composer install；用update可能引入不兼容变更，导致崩溃 - 本地开发想升级某一个包？用
composer update monolog/monolog，别直接update全量升级 - 首次运行
install时若无composer.lock，它会自动执行一次update并生成锁文件——这看似方便，但破坏了“先锁再装”的原则，建议团队统一先git commit composer.lock - 升级后出问题？立刻
git checkout composer.lock && composer install回滚，比查日志快得多
require/remove 为什么比手动改 JSON 更可靠
composer require vendor/package 不只是下载包，它会三步合一：写入 composer.json 的 require 字段 → 执行安装 → 更新 composer.lock；remove 同理反向清理。手动改 JSON 后忘了 update，会导致声明与实际安装不一致。
实操注意点：
- 指定版本必须带约束符：
composer require guzzlehttp/guzzle:^7.5（推荐）或~7.5.0；写成7.5就是==7.5.0，极难命中 - 加开发依赖：用
composer require --dev phpunit/phpunit，避免污染生产环境 - 只想加包、不升级其他依赖？加
--no-update，再单独composer update vendor/package
换国内镜像源总配不对？关键在配置项名称
国内访问 Packagist 慢，换镜像本质是修改 repo.packagist 配置项，但很多人错写成 repositories.packagist 或 packagist.org，导致无效。
正确姿势：
- 全局生效（推荐）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 仅当前项目生效：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（写进本项目composer.json的config字段） - 验证是否生效：
composer config --global --list | grep repo或composer config --list查看输出中是否有你设置的 URL
容易被忽略的一点：镜像配置后，composer update 或 require 第一次请求仍可能走慢速源（因缓存未刷新），可配合 composer clear-cache 强制清空。
