Composer如何创建新项目_从零开始初始化PHP工程

尼克

发布时间：2025-09-22 17:19:01

236人浏览过

来源于php中文网

原创

使用composer create-project可快速创建PHP项目，它会下载项目骨架并自动安装依赖，适合启动框架类项目；而composer init适用于从空目录逐步构建项目，通过交互式提问生成composer.json文件，适合自定义或库开发。前者用于快速搭建如Laravel等框架应用，后者用于轻量级或独立工具开发。最佳实践中建议指定版本约束、了解骨架结构、优先使用--prefer-dist、确保来源可信，并在项目初期完成定制。对于依赖管理，composer.json定义依赖范围和项目元数据，是项目的“蓝图”；composer.lock记录依赖精确版本，保证环境一致性。应用项目应提交composer.lock以确保各环境一致，库项目则不应提交。两者协同工作，确保依赖可复现与稳定。

composer如何创建新项目_从零开始初始化php工程

从零开始初始化PHP工程，Composer提供了两种主要途径：一种是利用

create-project

命令直接拉取一个预设的项目骨架（比如一个框架），另一种则是通过

composer init

命令在一个空目录中逐步构建

composer.json

文件，然后手动添加和安装依赖。前者适用于快速启动一个特定框架项目，后者则更适合那些需要完全自定义、从最基础开始搭建的场景。

解决方案

要使用Composer创建新项目，最常见且高效的方式是利用

composer create-project

命令。这个命令的强大之处在于它不仅仅是下载一个包，它会下载一个完整的项目骨架，并且会自动运行

composer install

来安装所有必要的依赖。

例如，如果你想创建一个新的Laravel项目，命令会是这样：

composer create-project laravel/laravel my-new-project

这行命令会做几件事：

立即学习“PHP免费学习笔记（深入）”；

从Packagist（Composer的默认包仓库）找到
```
laravel/laravel
```
这个包。
将这个包（实际上是一个项目骨架）下载到当前目录下的
```
my-new-project
```
文件夹中。
进入
```
my-new-project
```
文件夹。
根据
```
laravel/laravel
```
项目骨架中的
```
composer.json
```
文件，自动执行
```
composer install
```
，下载并安装Laravel框架及其所有依赖。

整个过程下来，你就拥有了一个可以直接运行的Laravel项目。这种方式极大地简化了新项目的启动流程，避免了手动下载、配置依赖的繁琐。

当然，如果你追求的是一个“完全从零开始”的空项目，甚至不依赖任何框架骨架，那么你可以在一个空目录中，先手动创建

composer.json

文件，或者使用

composer init

命令来交互式地生成它，然后逐步添加你需要的依赖，再运行

composer install

。但这通常是当你需要构建一个库，或者一个非常轻量级的、没有预设结构的独立应用时才会考虑。

composer create-project

的真实场景与最佳实践是什么？

composer create-project

这个命令，在我看来，它就是为“快速启动”而生的。想象一下，每次开始一个新项目都要手动下载框架、配置环境，那得多累人？它最大的价值就在于，你直接指定一个“项目模板”或者“骨架”，Composer帮你把所有基础的东西都搭好。

最典型的应用场景，就是启动各种PHP框架项目。无论是Laravel、Symfony、Lumen、Yii，还是CodeIgniter（虽然CodeIgniter用Composer不是那么普遍，但也有其方式），它们都有官方或社区提供的项目骨架包。用

create-project

，你得到的不仅仅是框架代码，而是一个完整的、可以立即运行的应用程序结构，包含了必要的配置、目录布局以及所有依赖。这省去了大量的初始化工作，让你能直接跳到业务逻辑的开发。

最佳实践方面，有几点我觉得挺重要的：

明确版本： 很多时候，我们不希望总是拉取最新版本，特别是当团队有特定版本要求时。你可以这样指定版本：
```
composer create-project laravel/laravel my-new-project "9.*"
```
这样就能确保你拿到的是Laravel 9系列的最新稳定版。版本约束的写法和
```
composer.json
```
里是一样的。
理解骨架： 在使用任何
```
create-project
```
命令之前，最好对你正在创建的骨架有所了解。它会创建哪些目录？包含哪些默认配置？有没有一些特殊的初始化脚本会运行？比如Laravel的骨架会生成
```
.env
```
文件，并运行
```
key:generate
```
。了解这些能避免一些不必要的疑惑。
--prefer-dist
vs
--prefer-source
：默认情况下，Composer会尝试下载打包好的发行版（
```
--prefer-dist
```
），这通常更快，也更节省空间。如果你需要修改框架核心代码，或者想调试框架内部，才应该考虑
```
--prefer-source
```
，它会通过Git克隆完整的仓库，这会带来
```
.git
```
目录，也更慢一些。一般项目开发，用默认的
```
--prefer-dist
```
就足够了。
安全性考量： 既然是拉取一个完整的项目，你就得信任这个骨架的来源。确保你使用的包是来自官方或信誉良好的开发者。避免使用不明来源的
```
create-project
```
模板，以防引入恶意代码。
后期定制： 即使是从骨架开始，项目初期也可能需要进行一些定制化。例如，修改默认的命名空间、调整目录结构（虽然不推荐大改框架默认结构），或者集成一些公司内部的基础库。这些都应该在项目创建后，尽早进行。

总的来说，

create-project

是PHP开发者启动新项目的一大利器，它把“从零开始”的门槛降低了不止一个数量级，让我们能更快地投入到真正的开发工作中。

如果我想从一个完全空的PHP目录开始，Composer要怎么初始化？

嗯，有时候我们确实不需要一个大而全的框架骨架，可能只是想写个小工具，或者构建一个纯粹的库，甚至只是想在一个现有但没有Composer的项目里引入依赖。这时候，

composer init

就派上用场了。它不会像

create-project

那样直接拉取一个完整的项目，而是以一种交互式的方式，帮助你在当前目录生成一个

composer.json

文件。这个文件就是Composer管理项目依赖的“宪法”。

你在一个空的目录里运行：

composer init

然后，Composer会像一个友好的向导一样，问你一系列问题：

Package name (
vendor/package
): 这是你项目的唯一标识，比如
```
my-company/my-awesome-tool
```
。如果你是开发一个库，这很重要；如果是应用，可以随意一些，但最好保持规范。
Description: 简短描述你的项目是做什么的。
Author: 你的名字和邮箱。
Minimum Stability:
```
dev
```
、
```
alpha
```
、
```
beta
```
、
```
RC
```
、
```
stable
```
。如果你不确定，
```
stable
```
通常是最好的选择，它会阻止安装不稳定的包。
License: 你的项目使用的开源许可证，比如
```
MIT
```
、
```
GPL-3.0-only
```
。
Define your dependencies (require)?: 这里你可以开始添加你的项目依赖。Composer会提示你输入包名（例如
```
monolog/monolog
```
）和版本约束（例如
```
^2.0
```
）。你可以添加多个。
Define your dev dependencies (require-dev)?: 同样，你可以添加开发环境才需要的依赖，比如测试框架（
```
phpunit/phpunit
```
）。

当你回答完所有问题，Composer就会在当前目录生成一个

composer.json

文件，内容大概会是这样：

Manus

全球首款通用型AI Agent，可以将你的想法转化为行动。

下载

{
    "name": "my-company/my-awesome-tool",
    "description": "A simple PHP tool for awesome stuff.",
    "type": "project",
    "license": "MIT",
    "autoload": {
        "psr-4": {
            "MyCompany\\MyAwesomeTool\\": "src/"
        }
    },
    "authors": [
        {
            "name": "Your Name",
            "email": "your.email@example.com"
        }
    ],
    "require": {
        "php": ">=8.0",
        "monolog/monolog": "^2.0"
    },
    "require-dev": {
        "phpunit/phpunit": "^9.5"
    }
}

注意，这里我手动添加了一个

autoload

配置，因为

composer init

默认不会问你关于自动加载的问题，但对于一个PHP项目来说，

autoload

几乎是必需的。它告诉Composer如何加载你的类文件，

psr-4

是最现代和推荐的方式。这意味着

src/

目录下的

MyCompany\MyAwesomeTool\

命名空间下的类，都可以被Composer自动加载。

生成

composer.json

之后，你需要运行：

composer install

这个命令会根据

composer.json

中定义的依赖，将它们下载到项目的

vendor/

目录中。同时，它还会生成

composer.lock

文件和

vendor/autoload.php

文件。至此，你的“从零开始”的PHP项目就拥有了Composer的依赖管理能力。你可以开始在

src/

目录下编写你的代码，并通过

require __DIR__ . '/vendor/autoload.php';

来使用所有通过Composer安装的库。

管理项目依赖时，

composer.json

和

composer.lock

各有什么作用？

在Composer的世界里，

composer.json

和

composer.lock

是两个核心文件，它们各自扮演着不可或缺的角色，但目的略有不同，理解它们的区别对于稳定地管理项目依赖至关重要。

composer.json

：项目的“意图”和“约束”

composer.json

是你告诉Composer“我想要什么”的地方。它定义了你的项目直接依赖哪些包，以及这些包的版本约束。比如，

"monolog/monolog": "^2.0"

，这表示你希望使用Monolog库的2.0或更高版本，但不能是3.0及以上（即

>=2.0.0 <3.0.0

）。

这个文件是项目的心脏，它包含了：

项目元数据： 项目名称、描述、作者、许可证等。
依赖项（
require
）：生产环境所需的包及其版本约束。
开发依赖项（
require-dev
）：仅在开发或测试环境所需的包。
自动加载规则（
autoload
）：如何自动加载你的项目类文件（PSR-4、PSR-0、classmap等）。
脚本（
scripts
）：定义可以在Composer生命周期事件中运行的自定义命令。

composer.json

更像是一个抽象的“愿望清单”或“蓝图”。它定义的是一个版本范围，而不是一个精确的版本。因此，当你运行

composer update

时，Composer会尝试在这个版本范围内找到最新的兼容版本。

composer.lock

：项目的“快照”和“精确状态”

composer.lock

文件则是一个精确的“快照”，它记录了当你上次运行

composer install

或

composer update

时，所有已安装包（包括直接依赖和它们的间接依赖）的确切版本号和它们的下载源（URL和校验和）。

这个文件的核心作用是确保环境一致性。想象一下，你和你的团队成员在不同的机器上开发同一个项目。如果只依赖

composer.json

，由于版本约束允许一定范围的变动，每个人运行

composer install

时，可能会安装到不同的小版本，这可能导致“在我的机器上能跑，在你的机器上就不行”的问题。

composer.lock

解决了这个问题。当你运行

composer install

时，如果

composer.lock

文件存在，Composer会优先使用
composer.lock
中记录的精确版本来安装依赖，而不是重新解析

composer.json

中的版本范围。这意味着，只要

composer.lock

文件保持不变，无论你在何时何地运行

composer install

，都会得到完全相同的依赖集合。

总结与版本控制策略：

composer.json
应该始终被提交到版本控制系统（如Git）。
composer.lock
对于应用程序（Application）项目，也应该始终被提交到版本控制系统。这确保了所有开发人员、测试环境和生产环境都使用完全相同的依赖版本，保证了环境的一致性和可重复性。
对于库（Library）项目，
```
composer.lock
```
通常不应该被提交到版本控制系统。因为库的消费者有权决定他们想要使用哪个版本的依赖，库只需要声明它兼容的版本范围即可。