composer init可交互式生成合法composer.json，避免手写错误；install按lock安装确保环境一致，update按需升级并重写lock；require/remove自动同步配置，validate/show/prohibits等命令辅助排查。
初始化项目：用 composer init 快速生成 composer.json
别手写 composer.json——composer init 会交互式帮你填包名、作者、描述、依赖等，连默认值都智能预设。执行后直接生成合法 JSON，省去格式错误、引号漏写、逗号多写等低级坑。
常见问题：composer init 不会覆盖已有 composer.json，但如果你中途 Ctrl+C 中断，可能留下半截文件，建议先 ls -la composer.json 确认是否已存在；若要强制重写，先 rm composer.json 再运行。
实用技巧：
- 加
--name=vendor/project等参数可跳过交互，适合 CI 脚本或批量初始化 - 依赖项填
php: ^8.1比php: >=8.1更安全，Composer 会据此校验环境 - 开发依赖（如 PHPUnit）务必用
--require-dev或后续composer require --dev，避免上线环境误装调试工具
安装与更新依赖：分清 install 和 update 的本质区别
composer install 是“按锁安装”：它只读 composer.lock，确保所有人（包括生产服务器）装的版本完全一致；而 composer update 是“按需升级”：它重新解析 composer.json，拉取满足约束的最新版，并重写 composer.lock。
线上部署必须用 install，否则可能因 update 引入不兼容变更导致崩溃。本地开发想尝新功能才用 update，且建议加 --with-dependencies 避免只升主包、留旧子依赖引发冲突。
容易踩的坑：
- 首次运行
install时若无composer.lock，它会自动执行一次update并生成锁文件——这看似方便，实则隐含风险，建议团队统一先git commit composer.lock -
update默认升级所有包，想只升某一个？用composer update vendor/package，比如composer update monolog/monolog - 升级后发现异常？立刻
git checkout composer.lock && composer install回滚，比查版本日志快得多
增删依赖：用 require 和 remove 自动同步配置
composer require vendor/package 不只是下载包，它会自动写入 composer.json 的 require 字段、执行安装、更新 composer.lock——三步合一。同理，composer remove vendor/package 会反向清理全部环节。
关键细节：
- 指定版本不能只写
1.2，得带约束符：composer require guzzlehttp/guzzle:^7.5（推荐）或~7.5.0；写成7.5会被解释为==7.5.0，极难匹配 - 开发专用包（如 PHPStan、Laravel Pint）必须加
--dev，否则会进require，上线时也会被加载，徒增开销 -
remove后记得检查vendor/是否真删干净，某些包含脚本钩子（如post-install-cmd），残留可能影响后续命令
排查与维护：几个高频救命命令
依赖出问题，别急着删 vendor 重来。先用 composer validate 确认 composer.json 语法合法；再用 composer show 查已装包列表，加包名如 composer show symfony/http-kernel 看具体版本和依赖树；遇到冲突报错（如 “Your requirements could not be resolved”），立刻 composer prohibits vendor/package:version 定位谁在拦路。
性能与稳定性提示：
-
composer dump-autoload --optimize可加速类加载，但仅当项目类数超千、且无动态路径映射时才显著有效；现代 PHP 8+ + PSR-4 已很高效，不必每次构建都加 - 国内用户必配镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，否则install卡在 “Downloading xxx” 是常态 -
composer status能发现你悄悄改过的包源码（比如 debug 时 patch 了某个 vendor 类），上线前务必检查，避免把临时修改带进生产
真正麻烦的从来不是记不住命令，而是搞不清 install 和 update 的语义边界、忽略 composer.lock 的作用、或者把开发依赖混进生产环境——这些地方一错，排查时间远超敲十遍命令。
