Composer 安装与基本使用

PHP 项目里那些散落的手动下载，到底该由谁来管？

很多同学在做 PHP 开发时，都会遇到这样一个痛点：项目引用了第三方库，比如日志处理需要 Monolog，或者想快速搭建一个 ThinkPHP 应用，于是开始手动去官网下载 Zip 包，解压后丢进 vendor 目录。刚开始觉得麻烦，但很快就会发现灾难：版本依赖冲突、找不到对应类的入口、自动加载失效，甚至两个包引用了相同函数导致崩溃。这门课专门解决的就是这个问题——它不教你怎么写业务逻辑，而是教你让 Composer 成为你项目依赖的“唯一上帝”。

我们将重点厘清 Composer 的三大核心组成部分：它是如何通过 composer.json 声明依赖、如何利用自动加载机制让你忘掉 include 语句、以及版本约束字符串（如 ~1.2 和 ^1.0）背后隐藏的更新策略差异。你会发现，原来手动维护依赖库是一种极其低效且容易出错的方式，而 Composer 正是为了消灭这种不确定性而生的工具。

基础薄弱也没关系，从安装到跑通第一个包

这门课适合没有任何包管理工具经验的同学，哪怕你之前连命令行都很少用。课程从最底层的 Composer 安装讲起，详细拆解了使用命令行 setup 脚本的步骤，这是很多新手容易卡壳的地方。接着，我们不搞高深的大项目，而是先用 Composer 下载并运行一个 Think 应用，再用它安装最经典的 Monolog 日志库。通过这两个具体的实操案例，你会直观感受到下载配置与手动引入代码的巨大效率差。

特别建议你先看概述、简介、三大组成部分这几个章节，建立整体概念后再去动手操作命令行安装。不要跳过“版本范围指定”那一节，那里详细讲解了波浪线和脱字符号的微妙区别，这是未来你升级框架时避免破坏性更新的必修课。只有理解了版本语义，你才能放心地告诉团队：“我们的依赖版本是锁定的，不会乱变。”

学完后，你将独立掌控项目依赖的生命周期

完成这门课后，你应当能够独立回答：如何在项目中声明对特定版本第三方库的依赖？如何编写 composer.json 以精确控制自动加载的行为？当需要更新某个包时，如何确保不破坏现有功能？你将不再依赖手动上传文件，而是能通过一条命令完成从依赖解析到自动加载配置的全部流程。

配套的练习资料鼓励你亲手在本地创建一个干净的文件夹，先尝试用 Composer 初始化，再尝试安装并调用一个类库。请重点关注自动加载生成的 autoload.php 是如何工作的，这是 PHP 现代化的基石。不要只看视频，一定要亲手敲一遍那些版本约束字符串，观察它们在不同场景下的解析结果，这才是把知识点转化为肌肉记忆的唯一途径。