文章目录

• Composer简介
• • 1. 核心文件 composer.json
  • • composer.json 常用属性解析：
    • • • name
        • description
        • type
        • keywords
        • homepage
        • license
        • authors
        • require
        • require-dev
        • repositories
  • 2. 锁文件 composer.lock
  • 3. 自动加载 autoload
  • 4. 引入自己的项目包

Composer简介

正所谓年少不识composer，老来看码全是泪。虽然composer已经出来很久，但是由于之前一直没有机会真正深入了解学习，每次写代码需要使用代码库时，都是Ctrl + C然后Ctrl + V，后来渐渐开始学习了解后，发现是真的好用。初入Composer的世界，望大神们多多指点。
有兴趣的同学，可以下载composer.phar来看看里面的源码。简单来说，composer其实就是使用composer.json来对项目包进行管理（括包内容和版本号的统一），除了可以引入线上包以外，可以引入自己开发的包。

1. 核心文件 composer.json

composer.json 常用属性解析：

name

包的名称，它包括供应商名称和项目名称，使用 / 分隔。

description

包描述。

type

包的安装类型，默认为 library。
composer原生支持4种类型：library、project、metapackage、composer-plugin，也可以自定义类型，用得偏多的是library以及project两种：

• library：这是默认类型，它会简单的将文件复制到 vendor 目录。
• project：这表示当前包是一个项目，而不是一个库。可以配合 extra 属性使用，定义一些框架中的参数，对项目进行初始化，例如 Thinkphp 中， ThinkFramework.php 文件使用到 $extra['think-path'] ，则可以在 extra 中设置 think-path 属性。

keywords

该包相关的关键词的数组。这些可用于搜索和过滤。

homepage

项目主页。

license

包的许可协议，它可以是一个字符串或者字符串数组。
具体每个协议，可以参照阮一峰大神画的：

authors

作者信息。

require

整个 composer.json 的核心属性，通过该属性引入所需要依赖的包，需要 包名称 （例如 topthink/framework） 映射到 包版本 （例如 5.1.*） 的对象。【具体包版本使用方法】

require-dev

这个列表是为开发或测试等目的，额外列出的依赖。例如PHPUnit（单元测试）、Mockery（用得较少，也是一种测试框架），一般正式环境会使用 composer 的 --no-dev 参数来跳过这些包。

repositories

也是 composer.json 的核心属性之一，该属性用于使用自定义的包资源库。一般企业开发存在不允许外泄的内部包，通过发布到为git的私有项目后，可以使用该属性配置后，拉取到各个项目中去使用。
支持以下类型的包资源库（更多请查看【资源库】）：

• composer： 一个 composer 类型的资源库，是一个简单的网络服务器（HTTP、FTP、SSH）上的 packages.json 文件，它包含一个 composer.json 对象的列表，有额外的 dist 和/或 source 信息。这个 packages.json 文件是用一个 PHP 流加载的。你可以使用 options 参数来设定额外的流信息。
• vcs：从 git、svn 和 hg 取得资源。
• pear：从 pear 获取资源。
• package：如果你依赖于一个项目，它不提供任何对 composer 的支持，你就可以使用这种类型。你基本上就只需要内联一个 composer.json 对象。

2. 锁文件 composer.lock

此文件中的代码，各位没必要深究，也是一些 Json ，而这个文件的主要作用，用于锁定项目当前使用的包版本，对于线上项目来说，是非常重要的。由于在 composer.json 中，有部分 require 进来的包是使用范围的方式引入，执行 composer update 后，所有包当前引入的具体版本号会在 composer.lock 文件中显示具体的版本号，此时我们可以将这些固定版本号回写到 composer.json 中去，这样做可以避免某些包更新后，导致线上正式版本发生未知错误，而且会非常难定位错误的情况。

3. 自动加载 autoload

对于库的自动加载信息，Composer 生成了一个 vendor/autoload.php 文件。在这个文件中，会引用 autoload_real.php文件，在 composer install/update 过程中，符合要求的引入会被以键值对的形式写入对应文件中，其部分核心代码：

/* 该文件用于自定义加载遵循 PSR-0 规范的类库 */
$map = require __DIR__ . '/autoload_namespaces.php';
foreach ($map as $namespace => $path) {$loader->set($namespace, $path);
}/* 该文件用于自定义加载遵循 PSR-4 规范的类库 */
$map = require __DIR__ . '/autoload_psr4.php';
foreach ($map as $namespace => $path) {$loader->setPsr4($namespace, $path);
}/* 该文件用于自定义加载不遵循 PSR-0/4 规范的类库 */
$classMap = require __DIR__ . '/autoload_classmap.php';
if ($classMap) {$loader->addClassMap($classMap);
}

除此之外，还有 autoload_files 以及 autoload_static 引入方式。

4. 引入自己的项目包

GIt除了可以通过将代码发布到 Packagist 后再下载，也可以直接通过自己私有的GIt目录去下载项目。以前可能大部分项目，都会通过接口的方式去处理两个模块之前的数据对接，其实很多情况下，可以通过Composer去拉取关联两个项目，可以减少很多网络传输以及减少人员对接接口的成本，是个不错的方案。打个比方：商城项目需要一个登录操作，这个登录操作可能支持Pc端、微信端、小程序端，以前的做法就是将登录操作剥离成为一个单独的项目，在这个项目中处理这些登录（包括Session、Cookie、Cache等）的逻辑以及一些业务上的处理，并且需要加上大量的防攻击、验证、加密等操作，而Pc端、微信端、小程序端也需要专门有一个对登录的操作模块去处理相同的东西。然而现在可以通过Composer，将登录模块作为项目中的一个模块拉取，可以减少很多重复性的工作。拉取方式如官网：

{"name": "xxx/login","repositories": [{"type": "vcs","url": "https://github.com/username/login"}],"require": {"xxx//login": "dev-master"}
}

将登录模块的各种校验和逻辑直接作为一个函数方法去封装，直接在程序内部调用即可。

本文链接：https://my.lmcjl.com/post/12354.html