composer.json 是 PHP 项目依赖管理的核心配置文件，定义项目元数据、生产依赖（require）、开发依赖（require-dev）、自动加载（autoload）、脚本（scripts）等。require 列出运行时必需的包，如框架或日志库；require-dev 包含测试、调试等开发工具，部署时可排除以减小体积。通过 autoload 配置 PSR-4 规则，可将命名空间映射到目录，实现类的自动加载，提升开发效率。scripts 支持在安装、更新等生命周期执行自定义命令，也可定义 composer run 调用的快捷脚本，用于自动化测试、启动服务等任务，增强项目可维护性与一致性。答案：composer.json 是 PHP 项目依赖管理的核心配置文件，定义项目元数据、生产依赖（require）、开发依赖（require-dev）、自动加载（autoload）、脚本（scripts）等。require 列出运行时必需的包，如框架或日志库；require-dev 包含测试、调试等开发工具，部署时可排除以减小体积。通过 autoload 配置 PSR-4 规则，可将命名空间映射到目录，实现类的自动加载，提升开发效率。scripts 支持在安装、更新等生命周期执行自定义命令，也可定义 composer run 调用的快捷脚本，用于自动化测试、
composer.json 文件是 Composer 这个 PHP 依赖管理工具的核心，它基本上就是你 PHP 项目的“身份证”和“行动指南”。它定义了你的项目需要哪些外部库（依赖），以及这些库应该如何被加载，甚至还能指定一些在特定生命周期执行的脚本。说白了，它就是告诉 Composer：“嘿，这是我的项目，这是我需要的东西，你帮我搞定！”
配置 composer.json 文件，本质上就是用 JSON 格式描述你的项目元数据和依赖关系。一个基础的 composer.json 结构通常包含以下几个关键部分，但实际使用中，你可以根据项目需求灵活增减：
{
"name": "your-vendor/your-project",
"description": "一个关于你的项目的简短描述。",
"type": "project",
"license": "MIT",
"authors": [
{
"name": "你的名字",
"email": "你的邮箱",
"homepage": "你的个人主页 (可选)"
}
],
"require": {
"php": ">=8.1",
"monolog/monolog": "^2.0",
"guzzlehttp/guzzle": "^7.0"
},
"require-dev": {
"phpunit/phpunit": "^9.5",
"symfony/var-dumper": "^6.0"
},
"autoload": {
"psr-4": {
"App\": "src/"
},
"files": [
"src/helpers.php"
]
},
"scripts": {
"post-install-cmd": [
"@php -r "file_exists('.env') || copy('.env.example', '.env');""
],
"test": "phpunit",
"start-server": "php -S 0.0.0.0:8000 -t public/"
},
"config": {
"optimize-autoloader": true,
"preferred-install": "dist",
"sort-packages": true
},
"minimum-stability": "dev",
"prefer-stable": true
}name: 项目的唯一标识符，格式通常是 vendor/project-name。这是你项目在 Packagist（Composer 的主要包仓库）上的名称。description: 项目的简短描述，帮助别人快速了解你的项目是做什么的。type: 项目类型，比如 library (库)、project (项目)、metapackage (元包) 或 composer-plugin (Composer 插件)。license: 项目的许可证，例如 MIT、GPL-3.0-or-later。这很重要，因为它定义了别人如何使用你的代码。authors: 一个作者数组，包含姓名、邮箱等信息。require: 定义了项目在生产环境运行时所必需的依赖包。require-dev: 定义了项目在开发或测试环境中才需要的依赖包，例如测试框架、调试工具。autoload: 配置了类的自动加载规则，这是 Composer 最强大的功能之一，通常使用 PSR-4 规范。scripts: 定义了在 Composer 运行特定事件（如安装、更新）时或通过 composer run <script-name> 命令执行的自定义脚本。config: 包含 Composer 运行时的一些配置选项，比如是否优化自动加载器、优先安装方式等。minimum-stability: 定义了允许安装的依赖包的最低稳定版本。常见值有 dev (开发版)、alpha、beta、RC (发布候选版) 和 stable (稳定版)。prefer-stable: 如果设置为 true，即使 minimum-stability 允许安装不稳定版本，Composer 也会优先选择稳定版本。require 和 require-dev 有何区别，何时使用它们？require 和 require-dev 是 composer.json 里两个非常核心的配置项，它们之间的区别在于依赖包的“生命周期”和“环境”。理解这一点，对于构建一个清晰、高效且资源利用合理的项目至关重要。
require 顾名思义，是你的项目在“生产环境”下运行所绝对依赖的包。没有它们，你的应用可能根本无法启动，或者核心功能会失效。比如，如果你用 Laravel 框架，那么 laravel/framework 肯定在 require 里；如果你需要处理日志，monolog/monolog 也属于这一类。这些是你的产品交付给用户时，必须存在的组件。当你在服务器上部署项目时，通常会运行 composer install --no-dev，这样 Composer 就只会安装 require 中列出的依赖，从而减少部署包的大小，避免不必要的代码和潜在的安全风险。
而 require-dev 则完全不同。这些依赖包只在“开发”或“测试”阶段才需要。它们可能是你的测试框架（如 phpunit/phpunit）、代码质量检查工具（如 squizlabs/php_codesniffer）、调试工具（如 symfony/var-dumper）或者一些开发辅助工具。这些工具在项目上线后，对于最终用户来说是完全没有用处的，甚至可能带来额外的负担。我个人觉得，把开发工具和生产依赖严格区分开来，是一种很好的实践。它让你的生产环境保持“精简”，只包含真正需要运行的代码，同时也让开发环境变得“强大”，拥有所有必要的工具来确保代码质量和开发效率。
所以，什么时候用哪个？很简单：如果一个依赖是你的应用核心功能在生产环境运行所必需的，就放到 require。如果它只是为了帮助你开发、测试、调试代码，或者只是在构建过程中用到，那就放到 require-dev。这是一个非常实用的区分，能让你的项目依赖管理更加清晰和高效。
autoload 配置实现 PSR-4 自动加载？autoload 配置是 Composer 魔法的核心之一，它解决了 PHP 项目中类文件加载的繁琐问题。手动 require 每个类文件简直是噩梦，而 autoload 让我们只需定义好规则，Composer 就能在运行时自动找到并加载所需的类。其中，PSR-4 是目前最推荐也是最流行的自动加载标准。
PSR-4 的核心思想是将命名空间前缀映射到文件系统中的一个目录。比如，如果你的 composer.json 中有这样的配置：
"autoload": {
"psr-4": {
"App\": "src/",
"MyLibrary\": "lib/"
}
}这意味着：
App 开头的命名空间，Composer 都会去 src/ 目录下查找对应的文件。MyLibrary 开头的命名空间，Composer 都会去 lib/ 目录下查找对应的文件。举个例子，如果你有一个类 AppHttpControllersUserController，Composer 会期望在 src/Http/Controllers/UserController.php 找到它。这里的映射关系是：命名空间中的 对应文件系统中的目录分隔符 /，并且类名与文件名保持一致。
配置完 autoload 后，你需要运行 composer dump-autoload（或者 composer install/composer update 也会自动执行）来生成 vendor/autoload.php 文件。在你的项目入口文件（比如 index.php 或 public/index.php）中，只需简单地引入这个文件：
require __DIR__ . '/vendor/autoload.php'; use AppHttpControllersUserController; $controller = new UserController(); // ... 你的应用代码
一旦引入了 autoload.php，你就可以直接 use 任何在 autoload 配置中定义的命名空间下的类，而无需手动 require 它们。这极大地简化了代码结构，提升了开发效率，也让项目组织更加规范。除了 psr-4，autoload 还支持 psr-0、classmap、files 等其他加载方式，但 psr-4 是现代 PHP 项目的首选。我发现，一旦习惯了 PSR-4，你就再也回不去手动加载的时代了。
scripts 配置有哪些实用场景？scripts 配置在 composer.json 中提供了一个强大的机制，允许你在 Composer 的生命周期事件中，或者通过自定义命令，执行 shell 命令。这简直是自动化项目任务的瑞士军刀，能把很多重复性、机械化的操作变成一条简单的 Composer 命令。
首先，Composer 定义了一些“事件钩子”，你可以在这些钩子上挂载脚本：
post-install-cmd: 在 composer install 命令执行完成后触发。post-update-cmd: 在 composer update 命令执行完成后触发。pre-install-cmd / pre-update-cmd: 在安装/更新开始前触发。post-autoload-dump: 在自动加载文件生成后触发。post-root-package-install / post-create-project-cmd: 在项目首次安装时触发。利用这些钩子，你可以做很多事情。比如，在 post-install-cmd 中，我经常会看到这样的用法：
"scripts": {
"post-install-cmd": [
"php artisan migrate --force",
"php artisan db:seed --force"
]
}这会在依赖安装完成后自动执行 Laravel 的数据库迁移和填充，对于部署新环境或设置开发环境非常方便。另一个常见场景是生成或复制配置文件，就像前面示例中提到的，检查 .env 文件是否存在，不存在就从 .env.example 复制一个。
除了这些事件钩子，你还可以定义完全自定义的脚本。这些脚本可以通过 composer run <script-name> 来执行。这让你可以把一些常用的开发任务封装成简单的命令。
"scripts": {
"test": "phpunit --coverage-html coverage",
"cs-fix": "php-cs-fixer fix",
"start-dev-server": "php -S 0.0.0.0:8000 -t public/"
}现在，我只需要运行 composer run test 就可以执行我的 PHPUnit 测试并生成覆盖率报告，composer run cs-fix 就能自动修复代码风格问题，composer run start-dev-server 就能启动一个 PHP 内置的开发服务器。这种方式把项目相关的命令集中管理，不仅方便团队成员统一执行，也避免了记住一长串命令的麻烦。对我来说，scripts 极大地提升了开发工作流的流畅性和一致性，是 composer.json 中被低估但极其有用的一个部分。
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
619
收藏
