composer.json
用法和package.json基本相似，区别在require的key由供应商和项目名两部分组成（允许两者命名相同），从而允许有两个同名的包，同时，用~符号表示大于当前版本小于下一个大版本。
Composer初次安装依赖后会生成composer.lock锁文件，在下次composer install时忽略compsoer.json的定义。如果你的依赖更新了版本，需要通过update命令更新进锁文件。
Root包
root包指由composer.json定义在项目根目录的包，简单来说就是自己的项目。root包的依赖关系由composer.json文件定义。
某些字段仅适用于root包上下文，如config字段。root包上下文会在工作环境改变时发生改变，如克隆一个依赖包，在其上开始工作。
属性
name：包名，它包括供应商名称和项目名称，使用 / 分隔，必须填写。
description：描述，通常只有一行，对于发布的包，必须填写。
version：版本号，version不是必须的，并且建议忽略，因为通常可以从VCS(git, svn, hg等)的信息推断出包的版本号。版本号的写法同package.json中的版本号。
type：安装类型，默认为library。它用来定义安装逻辑。composer原生支持4种类型。
library: 默认类型，它会简单的将文件复制到vendor目录。
project: 这表示当前包是一个项目，而不是一个库。例：框架应用程序 Symfony standard edition，内容管理系统 SilverStripe installer 或者完全成熟的分布式应用程序。使用 IDE 创建一个新的工作区时，这可以为其提供项目列表的初始化。
metapackage: 一个包含依赖信息并且触发依赖安装的空包，这将不会向系统写入文件。因此这种安装类型并不需要一个可安装的dist或source。
composer-plugin: 这种安装类型的包为其它包提供一个installler。详细请查看自定义安装类型。
建议在清楚自己做什么的时候使用这个域，否则最好忽略它。
keywords：关键词，用于搜索和过滤，如logging，database，redis等，可选。
homepage：项目主页，可选。
time：版本发布时间，必须符合YYYY-MM-DD或YYYY-M-DD HH:MM:SS的格式，可选。
license：许可协议，一个包允许多许可协议选择。可选，强烈建议提供。
authors：作者，每位作者提供name, email, homepage, role几个属性选择填写。可选，强烈建议提供。
support：获取项目支持的信息对象，包含email, issues, forum, wiki, irc, source几个属性，可选。
package links：依赖声明，接受多个包名到版本号的映射对象，可选。可以使用require, require-dev, conflict, replace, provide, suggest几个键名。require和require-dev还支持稳定性标签（@，仅针对“root 包”）和对dev（开发）版本的明确引用（即：版本控制系统中的提交编号 commit）。
require，必须的软件包列表，除非这些依赖被满足，否则不会完成安装。
require-dev，为开发或测试等目的额外列出的依赖列表。root包的require-dev默认是会被安装的。然而install或update支持使用--no-dev参数来跳过require-dev字段中列出的包
conflict，与当前包版本冲突的包列表。它们将不允许同时被安装。
replace，被当前包取代的包列表，这个列表常用在用主包取代主包下的各子包。
provide，被当前包提供的包列表，如实现了logger接口的包可以将依赖logger接口的包列在其中。
suggest：建议安装的包列表，它们可以增强当前包的性能或是能与之良好地配合工作。这些只是信息（版本号变成描述信息），显示在包安装完成后，给用户一个建议。
autoload：PHP的自动加载映射，目前支持PSR-0, PSR-4, classmap, files几种方式，推荐使用PSR-4。下面有一个autoload的填写例子。
PSR-4，在键名下定义命名空间到路径（相对于root包）的映射，注意用\转义\。命名空间以\结尾。在自动加载名为Foo\Bar\Baz这样的类时，如果Foo\已经映射到了src/，自动加载器就会去src/Bar/Baz.php（如果这个路径存在的话）中寻找。自动加载支持命名空间指定多个路径或是空命名空间映射作为default选项。
PSR-0，类似PSR-4，它也支持PEAR风格的约定（与命名空间不同，PEAR 类库在类名上采用了下划线分隔）。PSR-0方式也可以是精确到类级别的指定。这对于只有一个类在全局命名空间的类库是非常有用的（如果 php 源文件也位于包的根目录）
classmap，可以用 classmap 生成支持自定义加载的不遵循 PSR-0/4 规范的类库。要配置它指向需要的目录，以便能够准确搜索到类文件。
file，若想要明确的指定，在每次请求时都要载入某些文件，那么你可以使用 'files' autoloading。通常作为函数库的载入方式
{
"autoload": {
"psr-0": {
"Monolog\": ["src/", "lib/"],
"UniqueGlobalClass": ""
},
"psr-4": { "": "src/" },
"classmap": ["src/", "lib/", "Something.php"],
"files": ["src/MyLibrary/functions.php"]
}
}
autoload-dev：与autoload的关系类似require和require-dev。
minimum-stability：通过稳定性过滤依赖包，默认为stable，初次以外还有dev, alpha, beta, RC可用。可选。
prefer-stable：此选项被激活时，Composer 将优先使用更稳定的包版本，和minimum-stability配合使用，设定为true来激活，可选。
repositories：使用自定义的包资源库，默认使用packagist，支持以下类型的包资源库
composer：一个网络服务器（HTTP、FTP、SSH）上的packages.json文件，它包含有一个composer.json对象的列表和额外的dist 和/或source信息。这个packages.json 文件用一个PHP流加载。可以使用options参数来设定额外的流信息。
vcs：从git/svn/fossil/hg获取资源
pear：从PEAR获取资源
package：除了上面的类型，就需要内联一个composer.json对象
{
"repositories": [
{
"type": "composer",
"url": "http://packages.example.com"
},
{
"type": "composer",
"url": "https://packages.example.com",
"options": {
"ssl": {
"verify_peer": "true"
}
}
},
{
"type": "vcs",
"url": "https://github.com/Seldaek/monolog"
},
{
"type": "pear",
"url": "http://pear2.php.net"
},
{
"type": "package",
"package": {
"name": "smarty/smarty",
"version": "3.1.7",
"dist": {
"url": "http://www.smarty.net/files/Smarty-3.1.7.zip",
"type": "zip"
},
"source": {
"url": "http://smarty-php.googlecode.com/svn/",
"type": "svn",
"reference": "tags/Smarty_3_1_7/distribution/"
}
}
}
]
}
config：支持一组用于项目的配置选项，可选。
scripts：允许在安装过程挂载脚本。
extra：供scripts使用的额外任意数据，可选。
bin：标注一组应被视为二进制脚本的文件，他们会被软链接到（config对象中的）bin-dir 属性所标注的目录，以供其他依赖包调用.
archive：在创建包存档时使用，支持exclude选项，使用.gitignore的语法设置一个需要排除出去的路径列表。
include-path：一个追加到PHP include_path中的列表，不建议
target-dir：定义当前包安装的目标文件夹，在使用PSR-4自动加载后不建议使用。
Composer贴心地定义了一个composer-scheme.json来验证用户定义的composer.json的合法性，使用composer validate即可。