Composer 详细学习步骤

1 学习条件: 使用php框架lumen  安装composer

composer地址： ​​​​https://getcomposer.org/download/​​

composer包地址：​​https://packagist.org/​​

按照lumen框架
composer global require "laravel/lumen-installer=~1.0"
composer create-project laravel/lumen --prefer-dist
cd ./lumen
composer update

执行结果如图:

2 compose组成

仓库，公共库，私有库，

命令行下载器，

自动加载代码，包依赖管理，使用自动加载，psr-4自动加载规则

3 基本功能

修改国内镜像仓库：

composer config -g repos.packagist composer https://mirrors.cloud.tencent.com/composer/

阿里云镜像  https://mirrors.aliyun.com/composer/
腾讯云镜像 https://mirrors.cloud.tencent.com/composer/
华为云镜像  https://repo.huaweicloud.com/repository/php/
使用命令查看修改结果
composer config -g -l

3 安装monolog日志库事例

1 运行 命令 composer require monolog/monolog

2 将 monolog/monolog 写入到composer.json 中运行composer update

4 包的版本 参数说明

空版本号  ：默认最高稳定版

确切版本：1.0.2

范围： > < != ||或 -连接符            逻辑处理

通配符：*      1.*  表示[1.0,2.0)

赋值运算符：~1.2  相当于[1.2,2.0)

脱字号版本^    ^1.2.3 相当于[1.2.3 2.0.0)

默认为:stable 版本

5 全局选项

--verbose (-v) 增加提示信息

--help (-h) 查看帮助信息

--working-dir (-d) 指定工作目录,默认当前目录

--profile 查看耗时和内存情况

--version(-V) 查看版本号

6 composer 命令

6.1 初始化 init 命令

初始化composer包 

php composer.phar init

初始化-参数

• --name: 包的名称。
• --description: 包的描述。
• --author: 包的作者。
• --homepage: 包的主页。
• --require: 需要依赖的其它包，必须要有一个版本约束。并且应该遵循 ​​foo/bar:1.0.0​​ 这样的格式。
• --require-dev: 开发版的依赖包，内容格式与 --require 相同。
• --stability (-s): ​​minimum-stability​​ 字段的值。

6.2 安装 ​​install​​

​​install​​​ 命令从当前目录读取 ​​composer.json​​​ 文件，处理了依赖关系，并把其安装到 ​​vendor​​ 目录下。

php composer.phar install

安装-参数

• --prefer-source: 下载包的方式有两种： ​​source​​​ 和 ​​dist​​​。对于稳定版本 composer 将默认使用 ​​dist​​​ 方式。而 ​​source​​​ 表示版本控制源 。如果 ​​--prefer-source​​​ 是被启用的，composer 将从 ​​source​​ 安装（如果有的话）。如果想要使用一个 bugfix 到你的项目，这是非常有用的。并且可以直接从本地的版本库直接获取依赖关系。
• --prefer-dist: 与 ​​--prefer-source​​​ 相反，composer 将尽可能的从 ​​dist​​ 获取，这将大幅度的加快在 build servers 上的安装。这也是一个回避 git 问题的途径，如果你不清楚如何正确的设置。
• --dry-run: 如果你只是想演示而并非实际安装一个包，你可以运行 ​​--dry-run​​ 命令，它将模拟安装并显示将会发生什么。
• --dev: 安装 ​​require-dev​​ 字段中列出的包（这是一个默认值）。
• --no-dev: 跳过 ​​require-dev​​ 字段中列出的包。
• --no-scripts: 跳过 ​​composer.json​​ 文件中定义的脚本。
• --no-plugins: 关闭 plugins。
• --no-progress: 移除进度信息，这可以避免一些不处理换行的终端或脚本出现混乱的显示。
• --optimize-autoloader (-o): 转换 PSR-0/4 autoloading 到 classmap 可以获得更快的加载支持。特别是在生产环境下建议这么做，但由于运行需要一些时间，因此并没有作为默认值。

6.3 更新 ​​update​​

为了获取依赖的最新版本，并且升级 ​​composer.lock​​​ 文件，你应该使用 ​​update​​ 命令。

php composer.phar update

这将解决项目的所有依赖，并将确切的版本号写入 ​​composer.lock​​。

如果你只是想更新几个包，你可以像这样分别列出它们：

php composer.phar update vendor/package vendor/package2

你还可以使用通配符进行批量更新：

php composer.phar update vendor/*

更新-参数

• --prefer-source: 当有可用的包时，从 ​​source​​ 安装。
• --prefer-dist: 当有可用的包时，从 ​​dist​​ 安装。
• --dry-run: 模拟命令，并没有做实际的操作。
• --dev: 安装 ​​require-dev​​ 字段中列出的包（这是一个默认值）。
• --no-dev: 跳过 ​​require-dev​​ 字段中列出的包。
• --no-scripts: 跳过 ​​composer.json​​ 文件中定义的脚本。
• --no-plugins: 关闭 plugins。
• --no-progress: 移除进度信息，这可以避免一些不处理换行的终端或脚本出现混乱的显示。
• --optimize-autoloader (-o): 转换 PSR-0/4 autoloading 到 classmap 可以获得更快的加载支持。特别是在生产环境下建议这么做，但由于运行需要一些时间，因此并没有作为默认值。
• --lock: 仅更新 lock 文件的 hash，取消有关 lock 文件过时的警告。
• --with-dependencies 同时更新白名单内包的依赖关系，这将进行递归更新。

6.4 添加依赖 ​​require​​

​​require​​​ 命令增加新的依赖包到当前目录的 ​​composer.json​​ 文件中。

php composer.phar require

在添加或改变依赖时， 修改后的依赖关系将被安装或者更新。

如果你不希望通过交互来指定依赖包，你可以在这条令中直接指明依赖包。

php composer.phar require vendor/package:2.* vendor/package2:dev-master

申明依赖-参数

• --prefer-source: 当有可用的包时，从 ​​source​​ 安装。
• --prefer-dist: 当有可用的包时，从 ​​dist​​ 安装。
• --dev: 安装 ​​require-dev​​ 字段中列出的包。
• --no-update: 禁用依赖关系的自动更新。
• --no-progress: 移除进度信息，这可以避免一些不处理换行的终端或脚本出现混乱的显示。
• --update-with-dependencies 一并更新新装包的依赖。

6.5 搜索 ​​search​​

​​search​​ 命令允许你为当前项目搜索依赖包，通常它只搜索 packagist.org 上的包，你可以简单的输入你的搜索条件。

php composer.phar search monolog

您也可以通过传递多个参数来进行多条件搜索。

搜索-参数

• --only-name (-N): 仅针对指定的名称搜索（完全匹配）。

6.6 依赖性检测 ​​depends​​

​​depends​​ 命令可以查出已安装在你项目中的某个包，是否正在被其它的包所依赖，并列出他们。

php composer.phar depends --link-type=require monolog/monolog

nrk/monolog-fluent
poc/poc
propel/propel
symfony/monolog-bridge
symfony/symfony

依赖性检测-参数

• --link-type: 检测的类型，默认为 ​​require​​​ 也可以是 ​​require-dev​​。

6.7 更改配置 ​​config​​

​​config​​​ 命令允许你编辑 Composer 的一些基本设置，无论是本地的 ​​composer.json​​​ 或者全局的 ​​config.json​​ 文件。

php composer.phar config --list

更改配置-使用方法

​​config [options] [setting-key] [setting-value1] ... [setting-valueN]​​

​​setting-key​​​ 是一个配置选项的名称，​​setting-value1​​​ 是一个配置的值。可以使用数组作为配置的值（像 ​​github-protocols​​​），多个 ​​setting-value​​ 是允许的。

有效的配置选项，请查看“架构”章节的 ​​config​​ 。

更改配置-参数

• --global (-g): 操作位于 ​​$COMPOSER_HOME/config.json​​​ 的全局配置文件。如果不指定该参数，此命令将影响当前项目的 composer.json 文件，或 ​​--file​​ 参数所指向的文件。
• --editor (-e): 使用文本编辑器打开 composer.json 文件。默认情况下始终是打开当前项目的文件。当存在 ​​--global​​ 参数时，将会打开全局 composer.json 文件。
• --unset: 移除由 ​​setting-key​​ 指定名称的配置选项。
• --list (-l): 显示当前配置选项的列表。当存在 ​​--global​​ 参数时，将会显示全局配置选项的列表。
• --file="..." (-f): 在一个指定的文件上操作，而不是 composer.json。注意：不能与 ​​--global​​ 参数一起使用。

6.8 创建项目 ​​create-project​​

你可以使用 Composer 从现有的包中创建一个新的项目。这相当于执行了一个 ​​git clone​​​ 或 ​​svn checkout​​ 命令后将这个包的依赖安装到它自己的 vendor 目录。

此命令有几个常见的用途：

1. 你可以快速的部署你的应用。
2. 你可以检出任何资源包，并开发它的补丁。
3. 多人开发项目，可以用它来加快应用的初始化。

要创建基于 Composer 的新项目，你可以使用 "create-project" 命令。传递一个包名，它会为你创建项目的目录。你也可以在第三个参数中指定版本号，否则将获取最新的版本。

如果该目录目前不存在，则会在安装过程中自动创建。

php composer.phar create-project doctrine/orm path 2.2.*

此外，你也可以无需使用这个命令，而是通过现有的 ​​composer.json​​ 文件来启动这个项目。

默认情况下，这个命令会在 packagist.org 上查找你指定的包。

创建项目-参数

• --repository-url: 提供一个自定义的储存库来搜索包，这将被用来代替 packagist.org。可以是一个指向 ​​composer​​​ 资源库的 HTTP URL，或者是指向某个 ​​packages.json​​ 文件的本地路径。
• --stability (-s): 资源包的最低稳定版本，默认为 ​​stable​​。
• --prefer-source: 当有可用的包时，从 ​​source​​ 安装。
• --prefer-dist: 当有可用的包时，从 ​​dist​​ 安装。
• --dev: 安装 ​​require-dev​​ 字段中列出的包。
• --no-install: 禁止安装包的依赖。
• --no-plugins: 禁用 plugins。
• --no-scripts: 禁止在根资源包中定义的脚本执行。
• --no-progress: 移除进度信息，这可以避免一些不处理换行的终端或脚本出现混乱的显示。
• --keep-vcs: 创建时跳过缺失的 VCS 。如果你在非交互模式下运行创建命令，这将是非常有用的。

6.9 打印自动加载索引 ​​dump-autoload​​

某些情况下你需要更新 autoloader，例如在你的包中加入了一个新的类。你可以使用 ​​dump-autoload​​​ 来完成，而不必执行 ​​install​​​ 或 ​​update​​ 命令。

此外，它可以打印一个优化过的，符合 PSR-0/4 规范的类的索引，这也是出于对性能的可考虑。在大型的应用中会有许多类文件，而 autoloader 会占用每个请求的很大一部分时间，使用 classmaps 或许在开发时不太方便，但它在保证性能的前提下，仍然可以获得 PSR-0/4 规范带来的便利。

打印自动加载索引-参数

• --optimize (-o): 转换 PSR-0/4 autoloading 到 classmap 获得更快的载入速度。这特别适用于生产环境，但可能需要一些时间来运行，因此它目前不是默认设置。
• --no-dev: 禁用 autoload-dev 规则。

实例:

以上形式是将app命名空间以psr4形式加载到autoload

如果想以更快的形式加载则将classmap形式加载到autoload中

如果想再改回以psr4形式 则再执行一次 composer dump-autoload 

6.10查看许可协议 ​​licenses​​

列出已安装的每个包的名称、版本、许可协议。可以使用 ​​--format=json​​ 参数来获取 JSON 格式的输出。

7 composer.json 架构-属性

7.1 包名 ​​name​​

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

例：

• monolog/monolog
• igorw/event-source

对于需要发布的包（库），这是必须填写的。不区分大小写

7.2 描述 ​​description​​

一个包的简短描述。通常这个最长只有一行。

对于需要发布的包（库），这是必须填写的。

{
    "name": "wk/laravel",
    "description": "this is a laravel8",
    "require": {
        "laravel/laravel": "^9.5"
    },
    "autoload": {
        "psr-4": {
            "wk\\Laravel\\": "src/"
        }
    },
    "authors": [
        {
            "name": "everup",
            "email": "everup@163.com"
        }
    ]
}

7.3 版本 ​​version​​

​​version​​ 不是必须的，并且建议忽略（见下文）。

它应该符合 'X.Y.Z' 或者 'vX.Y.Z' 的形式， ​​-dev​​​、​​-patch​​​、​​-alpha​​​、​​-beta​​​ 或 ​​-RC​​ 这些后缀是可选的。在后缀之后也可以再跟上一个数字。

例：

• 1.0.0
• 0.2.5
• 1.0.0-dev
• 1.0.0-alpha3
• 1.0.0-beta2
• 1.0.0-RC5

通常，我们能够从 VCS (git, svn, hg) 的信息推断出包的版本号，在这种情况下，我们建议忽略 ​​version​​。

注意： Packagist 使用 VCS 仓库， 因此 ​​version​​​ 定义的版本号必须是真实准确的。 自己手动指定的 ​​version​​，最终有可能在某个时候因为人为错误造成问题。

7.4 安装类型 ​​type​​

包的安装类型，默认为 ​​library​​。

包的安装类型，用来定义安装逻辑。如果你有一个包需要一个特殊的逻辑，你可以设定一个自定义的类型。这可以是一个 ​​symfony-bundle​​​，一个 ​​wordpress-plugin​​​ 或者一个 ​​typo3-module​​。这些类型都将是具体到某一个项目，而对应的项目将要提供一种能够安装该类型包的安装程序。

composer 原生支持以下4种类型：

• library: 这是默认类型，它会简单的将文件复制到 ​​vendor​​ 目录。
• project: 这表示当前包是一个项目，而不是一个库。例：框架应用程序 ​​Symfony standard edition​​​，内容管理系统 ​​SilverStripe installer​​ 或者完全成熟的分布式应用程序。使用 IDE 创建一个新的工作区时，这可以为其提供项目列表的初始化。
• metapackage: 当一个空的包，包含依赖并且需要触发依赖的安装，这将不会对系统写入额外的文件。因此这种安装类型并不需要一个 dist 或 source。
• composer-plugin: 一个安装类型为 ​​composer-plugin​​​ 的包，它有一个自定义安装类型，可以为其它包提供一个 installler。详细请查看 ​​自定义安装类型​​。

仅在你需要一个自定义的安装逻辑时才使用它。建议忽略这个属性，采用默认的 ​​library​​。

7.5 关键字 ​​keywords​​

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

用数组标识["关键字","测试"]

7.6 项目主页 ​​homepage​​

该项目网站的 URL 地址。

可选。

7.7 版本发布时间 ​​time​​

版本发布时间。

必须符合 ​​YYYY-MM-DD​​​ 或 ​​YYYY-MM-DD HH:MM:SS​​ 格式。

可选。

7.8 许可协议 ​​license​​

包的许可协议，它可以是一个字符串或者字符串数组。

最常见的许可协议的推荐写法（按字母排序）：

• Apache-2.0
• BSD-2-Clause
• BSD-3-Clause
• BSD-4-Clause
• GPL-2.0
• GPL-2.0+
• GPL-3.0
• GPL-3.0+
• LGPL-2.1
• LGPL-2.1+
• LGPL-3.0
• LGPL-3.0+
• MIT

可选，但强烈建议提供此内容。更多许可协议的标识符请参见 ​​SPDX Open Source License Registry​​。

对于闭源软件，你必须使用 ​​"proprietary"​​ 协议标识符。

一个例：

{
    "license": "MIT"
}

对于一个包，当允许在多个许可协议间进行选择时（"disjunctive license"），这些协议标识符可以被指定为数组。

多协议的一个例：

{
    "license": [
       "LGPL-2.1",
       "GPL-3.0+"
    ]
}

另外它们也可以由 "or" 分隔，并写在括号中：

{
    "license": "(LGPL-2.1 or GPL-3.0+)"
}

同样，当有多个许可协议需要结合使用时（"conjunctive license"），它们应该被 "and" 分隔，并写在括号中。

7.9 作者 ​​authors​​

包的作者。这是一个对象数组。

这个对象必须包含以下属性：

• name: 作者的姓名，通常使用真名。
• email: 作者的 email 地址。
• homepage: 作者主页的 URL 地址。
• role: 该作者在此项目中担任的角色（例：开发人员 或 翻译）。

一个实例：

{
    "authors": [
        {
            "name": "Nils Adermann",
            "email": "naderman@naderman.de",
            "homepage": "http://www.naderman.de",
            "role": "Developer"
        },
        {
            "name": "Jordi Boggiano",
            "email": "j.boggiano@seld.be",
            "homepage": "http://seld.be",
            "role": "Developer"
        }
    ]
}

可选，但强烈建议提供此内容。

7.10 支持 ​​support​​

获取项目支持的向相关信息对象。

这个对象必须包含以下属性：

• email: 项目支持 email 地址。
• issues: 跟踪问题的 URL 地址。
• forum: 论坛地址。
• wiki: Wiki 地址。
• irc: IRC 聊天频道地址，类似于 irc://server/channel。
• source: 网址浏览或下载源。

一个实例：

{
    "support": {
        "email": "support@example.org",
        "irc": "irc://irc.freenode.org/composer"
    }
}

可选。

7.11 Package links 包的导入配置

下面提到的所有对象，都应该是 包名 到 ​​版本​​ 的映射对象。

实例：一般需要指定php版本

{
    "require": {
        "php": ">=7.2",
        "monolog/monolog": "1.*"
        "psr/log": "^1.0.1 || ^2.0 || ^3.0"
    },

所有的这些都是可选的。

​​require​​​ 和 ​​require-dev​​​ 还支持稳定性标签（@，仅针对“root 包”）。这允许你在 ​​minimum-stability​​ 设定的范围外做进一步的限制或扩展。例：如果你想允许依赖一个不稳定的包，你可以在一个包的版本约束后使用它，或者是一个空的版本约束内使用它。

实例：

{
    "require": {
        "monolog/monolog": "1.0.*@beta",
        "acme/foo": "@dev"
    }
}

如果你的依赖之一，有对另一个不稳定包的依赖，你最好在 require 中显示的定义它，并带上足够详细的稳定性标识。

实例：

{
    "require": {
        "doctrine/doctrine-fixtures-bundle": "dev-master",
        "doctrine/data-fixtures": "@dev"
    }
}

​​require​​​ 和 ​​require-dev​​​ 还支持对 dev（开发）版本的明确引用（即：版本控制系统中的提交编号 commit），以确保它们被锁定到一个给定的状态，即使你运行了更新命令。你只需要明确一个开发版本号，并带上诸如 ​​#<ref>​​ 的标识。

实例：

{
    "require": {
        "monolog/monolog": "dev-master#2eb0c0978d290a1c45346a1955188929cb4e5db7",
        "acme/foo": "1.0.x-dev#abc123"
    }
}

注意： 虽然这有时很方便，但不应该长期在你的包中使用，因为它有一个技术上的限制。 composer.json 将仍然在哈希值之前指定的分支名称读取元数据， 正因为如此，在某些情况下，它不会是一个实用的解决方法， 如果可能，你应该总是尝试切换到拥有标签的版本。

它也可以应用于行内别名，这样它将匹配一个约束，否则不会。更多信息请参考 ​​别名​​。

require

必须的软件包列表，除非这些依赖被满足，否则不会完成安装。

require-dev (root-only)

这个列表是为开发或测试等目的，额外列出的依赖。“root 包”的 require-dev 默认是会被安装的。然而 ​​install​​​ 或 ​​update​​​ 支持使用 ​​--no-dev​​​ 参数来跳过 ​​require-dev​​ 字段中列出的包。

7.12 conflict

此列表中的包与当前包的这个版本冲突。它们将不允许同时被安装。

请注意，在 ​​conflict​​​ 中指定类似于 ​​<1.0, >= 1.1​​ 的版本范围时，这表示它与小于1.0 并且 同时大等于1.1的版本冲突，这很可能不是你想要的。在这种情况下你可能想要表达的是 ​​<1.0 | >= 1.1​​ 。

比如你需要一个2.0的版本 但是系统有其他包必须版本要低于2.0版本的时候则不允许安装,下面是冲突的提示信息,提示monolog 小于1.5.0 是不允许的

7.13 replace

这个列表中的包将被当前包取代。这使你可以 fork 一个包，以不同的名称和版本号发布，同时要求依赖于原包的其它包，在这之后依赖于你 fork 的这个包，因为它取代了原来的包。

这对于创建一个内部包含子包的主包也非常的有用。例如 symfony/symfony 这个主包，包含了所有 Symfony 的组件，而这些组件又可以作为单独的包进行发布。如果你 require 了主包，那么它就会自动完成其下各个组件的任务，因为主包取代了子包。

注意，在使用上述方法取代子包时，通常你应该只对子包使用 ​​self.version​​ 这一个版本约束，以确保主包仅替换掉子包的准确版本，而不是任何其他版本。

7.14 provide 登记一个包可能依赖一些虚拟的包

List of other packages that are provided by this package. This is mostly useful for common interfaces. A package could depend on some virtual ​​logger​​​ package, any library that implements this logger interface would simply list it in ​​provide​​.

7.15 suggest 建议的软件包和扩展,包安装后会显示出来,值是文本信息

建议安装的包，它们增强或能够与当前包良好的工作。这些只是信息，并显示在依赖包安装完成之后，给你的用户一个建议，他们可以添加更多的包。

格式如下，版本约束变成了描述信息。 安装时这块的并没有安装,只是提示信息提供建议

实例：

{
    "suggest": {
        "monolog/monolog": "Allows more advanced logging of the application flow"
    }
}

7.16 autoload

PHP autoloader 的自动加载映射。

现在​​PSR-0​​​自动加载，​​PSR-4​​​支持自动加载、生成和包含。PSR-4是推荐的方式，因为它提供 更易于使用（添加类时无需重新生成自动加载器）。​​classmap​​​​files​​

PSR-4

在键下，您可以定义从命名空间到路径的映射，相对于 包根目录。当自动加载类（如指向目录的命名空间前缀）时，意味着自动加载器将查找 文件名并包含它（如果存在）。请注意，与 较旧的 PSR-0 样式，前缀 （） 不存在于文件路径中。​​psr-4​​​​Foo\\Bar\\Baz​​​​Foo\\​​​​src/​​​​src/Bar/Baz.php​​​​Foo\\​​

命名空间前缀必须以 结尾，以避免类似前缀之间的冲突。 例如，将匹配命名空间中的类，因此尾随 反斜杠解决了问题：并且是不同的。​​\\​​​​Foo​​​​FooBar​​​​Foo\\​​​​FooBar\\​​

在安装/更新期间，PSR-4 引用全部合并为一个 key => 可以在生成的文件中找到的值数组。​​vendor/composer/autoload_psr4.php​​

例：

{
    "autoload": {
        "psr-4": {
            "Monolog\\": "src/",
            "Vendor\\Namespace\\": ""
        }
    }
}

如果需要在多个目录中搜索相同的前缀， 您可以将它们指定为数组，如下所示：

{
    "autoload": {
        "psr-4": { "Monolog\\": ["src/", "lib/"] }
    }
}

如果要有一个回退目录来查找任何命名空间， 您可以使用空前缀，例如：

{
    "autoload": {
        "psr-4": { "": "src/" }
    }
}

PSR-0

在 key 下你定义了一个命名空间到实际路径的映射（相对于包的根目录）。 注意，这里同样支持 PEAR-style 方式的约定（与命名空间不同，PEAR 类库在类名上采用了下划线分隔）。​​psr-0​​

请注意，命名空间的申明应该以 结束，以确保 autoloader 能够准确响应。 例： 将会与 匹配，然而以反斜杠结束就可以解决这样的问题， 和 将会被区分开来。​​\\​​​​Foo​​​​FooBar​​​​Foo\\​​​​FooBar\\​​

在 install/update 过程中，PSR-0 引用都将被结合为一个单一的键值对数组，存储至 文件中。​​vendor/composer/autoload_namespaces.php​​

实例：

{
    "autoload": {
        "psr-0": {
            "Monolog\\": "src/",
            "Vendor\\Namespace\\": "src/",
            "Vendor_Namespace_": "src/"
        }
    }
}

如果你需要搜索多个目录中一个相同的前缀，你可以将它们指定为一个数组，例：

{
    "autoload": {
        "psr-0": { "Monolog\\": ["src/", "lib/"] }
    }
}

PSR-0 方式并不仅限于申明命名空间，也可以是精确到类级别的指定。 这对于只有一个类在全局命名空间的类库是非常有用的（如果 php 源文件也位于包的根目录）。 例如，可以这样申明：

{
    "autoload": {
        "psr-0": { "UniqueGlobalClass": "" }
    }
}

如果你想设置一个目录作为任何命名空间的备用目录，你可以使用空的前缀，像这样：

{
    "autoload": {
        "psr-0": { "": "src/" }
    }
}