Composer Composer是PHP的依赖管理工具。它允许您声明您的项目所依赖的库, 并且它将为您管理 (安装/更新) 它们。它以每个项目为基础管理它们, 并将它们安装在项目内的目录 (如 vendor) 中. 默认情况下, 它不会在全局范围内安装任何内容。因此, 它是一个依赖关系管理器。

  1. composer安装 下载composer.phar文件，即可在任意操作系统上通过PHP运行软件包工具，更新时可直接重新下载文件；

https://docs.phpcomposer.com/，中文文档。修改环境变量后要重启软件、重启CMD才会重新加载

  1. 修改composer仓库镜像地址 2.1 全局配置

    修改镜像地址

    $ php composer.phar config -g repo.packagist composer https://packagist.phpcomposer.com

    重置镜像地址

    $ composer config -g –unset repos.packagist 2.2 单个项目配置 在项目目录下的composer.json文件内加入以下配置信息

“repositories”: {

"packagist": {
    "type": "composer",
    "url": "https://packagist.phpcomposer.com"
}

}

  1. composer命令 comoesr 的require/update都可以更新指定的依赖包（升级/降级）。

require更为灵活些，未安装则进行安装，已安装则根据传入的版本号进行升级或降级。 update则无法在命令行传入指定的版本号，需要先手动编辑composer.json，指定新的版本号，然后执行更新命令。 install可以用于项目初始化后，初次安装依赖，且会优先读取composer.lock中的版本号，以尽可能的保证协作开发中包版本的一致性。

composer list：获取帮助信息； composer init：以交互方式填写composer.json文件信息 composer install：从当前目录读取composer.json文件，处理依赖关系，并安装到vendor目录下； composer update：获取依赖的最新版本，升级composer.lock文件； composer require：添加新的依赖包到composer.json文件中并执行更新； composer remove twbs/bootstrap; 卸载依赖包 composer search：搜索依赖包； composer show：列举所有可用的资源包； composer validate：检测composer.json文件是否有效； composer self-update：将composer工具更新到最新版本； composer self-update -r ：回滚到安装的上一个版本 composer diagnose：执行诊断命令 composer clear：清除缓存 create-project：基于composer创建一个新的项目； composer dump-autoload：在添加新的类和目录映射是更新autoloader

composer.lock 当我们协同开发时，A 在本地安装了新的依赖包，或者更新了依赖包，会写入 composer.lock/composer.json,A 上传至仓库，B 拉取至本地后，应执行一次 composer install来同步团队的版本变更。

  1. aotuload加载优化 composer autoload 慢的主要原因在于来自对 PSR-0 和 PSR-4 的支持，加载器得到一个类名时需要到文件系统里查找对应的类文件位置，这导致了很大的性能损耗，当然这在我们开发时还是有用的，这样我们添加的新的类文件就能即时生效。 但是在生产模式下，我们想要最快的找到这些类文件，并加载他们。

composer dump-autoload -o （-o 等同于 –optimize）

这个命令的本质是将 PSR-4/PSR-0 的规则转化为了 classmap 的规则， 因为 classmap 中包含了所有类名与类文件路径的对应关系，所以加载器不再需要到文件系统中查找文件了。可以从 classmap 中直接找到类文件的路径。

这个命令并没有考虑到当在 classmap 中找不到目标类时的情况，当加载器找不到目标类时，仍旧会根据PSR-4/PSR-0 的规则去文件系统中查找；

composer dump-autoload -a （-a 等同于 –classmap-authoritative）

执行这个命令隐含的也执行了 Level-1 的命令， 即同样也是生成了 classmap，区别在于当加载器在 classmap 中找不到目标类时，不会再去文件系统中查找（即隐含的认为 classmap 中就是所有合法的类，不会有其他的类了，除非法调用）；如果项目在运行时会生成类，使用这个优化策略会找不到这些新生成的类。

composer dump-autoload –apcu

apcu 可以理解为一块内存，并且可以在多进程中共享。 这种策略是为了在 Level-1 中 classmap 中找不到目标类时，将在文件系统中找到的结果存储到共享内存中， 当下次再查找时就可以从内存中直接返回，不用再去文件系统中再次查找。

在生产环境下，这个策略一般也会与 Level-1 一起使用， 执行composer dump-autoload -o –apcu, 这样，即使生产环境下生成了新的类，只需要文件系统中查找一次即可被缓存 ， 弥补了Level-2/A 的缺陷。

要根据自己项目的实际情况来选择策略，如果你的项目在运行时不会生成类文件并且需要 composer 的 autoload 去加载，那么使用 Level-2/A 即可，否则使用 Level-1 及 Level-2/B是比较好的选择。

Level-2的优化基本都是 Level-1 优化的补充，Level-2/A 主要是决定在 classmap 中找不到目标类时是否继续找下去的问题，Level-2/B 主要是在提供了一个缓存机制，将在 classmap 中找不到时，将从文件系统中找到的文件路径缓存起来，加速后续查找的速度。 在执行了 Level-2/A 时，表示在 classmap 中找不到不会继续找，此时 Level-2/B 是不会生效的。 不论那种情况都建议要开启 opcache， 这会极大的提高类的加载速度，性能提升至少 10倍。

  1. composer.json详解 Apache-2.0 BSD-2-Clause BSD-3-Clause BSD-4-Clause GPL-2.0-only / GPL-2.0-or-later GPL-3.0-only / GPL-3.0-or-later LGPL-2.1-only / LGPL-2.1-or-later LGPL-3.0-only / LGPL-3.0-or-later MIT “authors”: [

    {
    "name": "huaweichenai",
    "email": "243681093@qq.com",
    "homepage": "https://www.wj0511.com/",
    "role": "Developer"
}

    ] “support”: { “issues”: “https://github.com/yiisoft/yii2/issues?state=open", ”forum“: ”http://www.yiiframework.com/forum/", “wiki”: “http://www.yiiframework.com/wiki/", ”irc“: ”irc://irc.freenode.net/yii“, ”source“: ”https://github.com/yiisoft/yii2" } } “require”: { “yiisoft/yii2”: “*” } { “autoload”: {

    "files":[],

    “psr-4”:{ “Test" :”core/“ } } }

  2. composer自动加载的过程

vendor/autoload.php 自动加载入口文件 vendor/composer/autoload_real.php 自动加载核心文件 vendor/composer/ClassLoader.php 自动加载类具体实现文件 vendor/composer/autoload_static.php 所有的自动加载配置 vendor/composer/autoload_classmap.php classmap自动加载配置 vendor/composer/autoload_namespaces.php PSR0自动加载配置 vendor/composer/autoload_psr4.php PSR4自动加载配置 vendor/composer/autoload_files.php files自动加载配置

5.创建自己的composer包

composer init

创建并配置好自己包之后，到https://packagist.org/上传即可。

prs-4规范 在PSR-4里边需要定义一个命名空间前缀到路径的映射（相对于包的根目录），如果命名空间前缀Foo\指向一个文件目录src/，当自动加载一个类时，比如Foo\Bar\Baz类，那么这个类的路径为 src/Bar/Baz.php，命名空间前缀可以不在路径之中。在composer.json中的命名空间必须以\结尾，以避免名字冲突

如果想要明确的指定，在每次请求时都要载入某些文件，那么你可以使用 files autoloading，通常作为函数库的载入方式（而非类库）。files引用的所有集合都会在install/update过程中生成，并存储到vendor/composer/autoload_files.php文件中。

”autoload“: {

 "psr-4": {
      "Nicen\\LocalImage\\": "src/"
 },
 "psr-0": {
        "Tutsplus\\Library": "src"
 },     
"files": [
     "src/auto.php"
 ]

},

每次修改composer.json之后，都需要update一次；（composer dump-autoload 命令可创建必要的自动加载器文件）

PSR-0 是 PHP-FIG 组推荐的自动加载标准。在 PSR-0 标准中，您必须使用命名空间来定义您的库。完全限定的类名必须反映\()*结构。此外，您的类必须保存在遵循与命名空间相同的目录结构的文件中。

在 PSR-0 自动加载中，您需要将命名空间映射到目录。在上面的例子中，我们告诉 Composer 任何以Tutsplus\Library命名空间开头的东西都应该在src\Tutsplus\Library目录中可用。

阅读剩余 0%
本站所有文章资讯、展示的图片素材等内容均为注册用户上传(部分报媒/平媒内容转载自网络合作媒体)，仅供学习参考。 用户通过本站上传、发布的任何内容的知识产权归属用户或原始著作权人所有。如有侵犯您的版权，请联系我们反馈本站将在三个工作日内改正。