推荐优先使用 composer require，它自动解析依赖、实时安装并更新 lock 文件，减少错误；手动修改 composer.json 适合精确控制和批量操作，但易出错且需注意同步更新。
在使用 Composer 管理 PHP 项目依赖时，我们通常有两种方式添加新的包：一种是通过命令行执行 composer require，另一种是手动修改 composer.json 文件后再运行 composer install 或 composer update。这两种方式都能达到目的，但各有优劣，适用于不同场景。
1. 使用 composer require 的优点
composer require 是官方推荐的方式，它不仅修改配置文件，还会自动处理依赖关系和安装操作。
- 自动解析依赖：Composer 会分析新包所依赖的其他库，并确保它们兼容当前项目中的版本。
- 实时安装生效：执行命令后，包立即被下载并写入 vendor 目录，无需额外命令。
- 自动更新 lock 文件：composer.lock 会被正确更新，保证团队成员安装一致的依赖版本。
- 减少人为错误：避免手动编辑 JSON 格式出错（如逗号遗漏、引号不匹配等）。
- 支持开发/生产环境区分：可通过 --dev 参数将包添加到 require-dev，逻辑清晰。
2. 使用 composer require 的缺点
- 网络依赖强：必须联网才能完成安装，无法离线操作。
- 可能触发意外更新：如果不加约束地运行，可能会升级其他已有依赖以满足新包要求。
- 不够透明：初学者可能不清楚背后发生了什么，比如版本选择机制。
3. 手动修改 composer.json 的优点
直接编辑 composer.json 再运行更新命令，适合对依赖管理较熟悉的开发者。
- 精确控制版本：可以提前写好特定版本号或约束规则，避免自动推断带来的不确定性。
- 批量修改方便：需要同时添加多个包时，一次性编辑比多次执行命令更高效。
- 便于版本控制审查：提交前可清楚看到所有变更，适合 Code Review 流程。
- 适合自动化脚本：在 CI/CD 或构建流程中，有时需要程序化生成配置文件。
4. 手动修改 composer.json 的缺点
- 容易格式错误：JSON 对语法严格，手误可能导致解析失败。
- 忘记更新 lock 文件：只改 composer.json 而不运行 update，会导致实际安装版本与预期不符。
- 不自动处理依赖冲突：需自行判断是否与其他包兼容，风险更高。
- 步骤分离，易遗漏：修改配置 + 运行命令两步操作，不如一条命令简洁可靠。
结论：推荐优先使用 composer require
对于大多数日常开发场景，composer require 更安全、高效且符合最佳实践。它集成了声明与安装过程，降低出错概率，特别适合个人开发和协作项目。
手动修改 composer.json 更适合高级用途，比如迁移项目、编写工具脚本、或进行大规模依赖重构。即便如此，修改后也应通过 composer update 显式触发安装，并检查 lock 文件变化。
基本上就这些，关键是理解每种方式背后的机制，按需选择。
