使用composer create-project可快速创建PHP项目，它会下载项目骨架并自动安装依赖，适合启动框架类项目；而composer init适用于从空目录逐步构建项目，通过交互式提问生成composer.json文件，适合自定义或库开发。前者用于快速搭建如Laravel等框架应用，后者用于轻量级或独立工具开发。最佳实践中建议指定版本约束、了解骨架结构、优先使用–prefer-dist、确保来源可信，并在项目初期完成定制。对于依赖管理，composer.json定义依赖范围和项目元数据，是项目的“蓝图”；composer.lock记录依赖精确版本，保证环境一致性。应用项目应提交composer.lock以确保各环境一致，库项目则不应提交。两者协同工作，确保依赖可复现与稳定。
从零开始初始化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
文件，内容大概会是这样：
天工AI
昆仑万维推出的国内首款融入大语言模型的AI对话问答、AI搜索引擎，知识从这里开始。
244 查看详情
{ "name": "my-company/my-awesome-tool", "description": "A simple PHP tool for awesome stuff.", "type": "project", "license": "MIT", "autoload": { "psr-4": { "MyCompanyMyAwesomeTool": "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/
目录下的
MyCompanyMyAwesomeTool
命名空间下的类，都可以被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
通常不应该被提交到版本控制系统。因为库的消费者有权决定他们想要使用哪个版本的依赖，库只需要声明它兼容的版本范围即可。
理解这两个文件的作用，并正确地将它们纳入你的版本控制策略，是使用Composer进行高效、稳定项目管理的关键。当你需要更新依赖时，运行
composer update
会更新
composer.json
允许范围内的最新版本，并同时更新
composer.lock
文件。而当你只想安装现有依赖时，
composer install
会利用
composer.lock
来保证安装的精确性。
以上就是Composer如何创建新项目_从零开始初始化PHP工程的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/541470.html
微信扫一扫 
支付宝扫一扫 
