cmposer避坑指南，区分json与lock,install与update及如何解决冲突

要避免采composer坑， 我们首先要知道composer是什么，是干什么用的，本文主要分以下几个部分

• 自动加载与composer
• composer.json VS composer.lock
• composer install VS composer update
• composer VS git

为什么要自动加载？

换句话说就是，如果不自动加载一直用include/require来包含类库文件会引起什么问题：

1. 目录名和文件名变化引起程序不稳定的问题
2. 造成遗漏 或者 包含进不必要的类文件
3. 相对路径的性能问题
4. 类库文件间相互依赖的问题

尽管PHP有autoload和spl_autoload也不能很好的解决这些问题，后来composer就出现了为我们解决了这些问题：
Composer 将这样为你解决问题：

a) 你有一个项目依赖于若干个库。

b) 其中一些库依赖于其他库。

c) 你声明所依赖的东西。

d) Composer 会找出哪个版本的包需要安装，并安装它们。

composer加载核心思想：通过composer的配置文件在引用入口文件(autoload.php)时,将类和路径的对应关系加载到内存中,最后将具体加载的实现注册到spl_autoload_register函数中.最后将需要的文件包含进来。

Composer 不是一个包管理器。它涉及 “packages” 和 “libraries”，它在每个项目的基础上进行管理，在你项目的某个目录中（例如 vendor）进行安装。默认情况下它不会在全局安装任何东西。因此，这仅仅是一个依赖管理。就是这个依赖管理解决了项目的依赖关系，且实现了自动加载。

安装完毕后，vendor目录下会生成autoload.php文件。在我们开发项目的入口文件中包含此文件： require DIR . “/vendor/autoload.php”;，接下来便可在项目的任何地方引用依赖包中的接口和类。

composer.josn VS composer.lock

composer.json:用来声明包之间的相互关系和其他的一些元素标签

主要结构如下：

Name:包名
Description：描述
Version：版本
Type：安装类型
Keyword：关键字
License：许可协议
Autoload:自动加载映射
Minimum-stability:是否稳定
Require：必须的安装包
Require-dev:开发测试包
Conflict：版本冲突
Config:项目配置
Repositories:自定义的包资源库

Composer.lock-锁文件

在安装依赖后，Composer 将创建composer.lock文件把安装时确切的版本号写入其中， 并把依赖安装到 vendor 目录下。这将锁定改项目的特定版本。

作用:composer.lock这个文件主要是解决在协同开发中组件及其依赖的版本记录，防止不同人使用的组件及依赖版本不同

小结：composer.lock 相当于composer依赖关系的缓存文件，有它从它处获取依赖，没它从composer.json并生成缓存。

composer install VS composer update

Install 命令：将会检查锁文件lock是否存在，如果存在，它将下载指定的版本（忽略 composer.json 文件中的定义）。所以，使用composer install的时候是不会修改composer.lock这个文件。如果不存在才会根据json生成对应的lock文件。

Update命令：将会根据composer.json文件读取最新的依赖版本关系，然后更新lock文件。

但是！当你修改了你的json依赖关系，不管是新增了依赖，还是修改了依赖的版本，又或者是删除了依赖，这时候如果你执行composer install的时候，是不会有任何变更的，但你会得到一个警告信息.

Warning: The lock file is not up to date with the latest changes in composer.json. You may be getting outdated dependencies. Run update to update them

这个时候需要update

如果只想安装或更新一个依赖，你可以白名单它们：
composer update panshi/cities […]

composer VS Git

区分库和项目
创建了 一个项目，一定要把 composer.lock 文件提交到 git 中。 这会确保每一个人——你、你的合作伙伴、你的 CI 服务器以及你的产品服务器——所运行的应用程序拥有相同依赖的版本。

创建 一个库 （比如说叫 acme/my-library）， 这就不应该把 composer.lock 文件提交到 git 库中了。开发库要把 composer.lock 文件添加到 .gitignore 文件中。

千万别试图手动解决冲突，这是因为 composer.lock 文件包含了定义 composer.json 中依赖项的哈希值。所以即使你解决了冲突，这个最终合并结果的lock文件仍是错误的。

最佳方案：用下面一行代码在项目根目录创建一个 .gitattributes 文件，它会告诉 git 不要试图对 composer.lock 文件进行合并操作：

/composer.lock -merge 

推荐 Trunk Based Development 方式（常用佳品，不会有错），使用临时的特性分支纠正这种问题。当你有个临时分支需要即时合并时，因此导致的 composer.lock 文件合并冲突的风险极小。你甚至可以仅仅为添加一个依赖项而创建分支，然后马上进行合并。

假如在衍合过程中 composer.lock 遇到合并冲突又当如何呢？ 使用主分支版本解决，这样仅仅修改 composer.json 文件即可（新增一个包）。然后运行 composer update --lock ，就会把 composer.json 文件的修改更新到 composer.lock 文件中。现在把已经更新的 composer.lock 文件提交到版本暂存区，然后继续衍合操作。

composer指令总结

composer install - 如有 composer.lock 文件，直接安装，否则从 composer.json 安装最新扩展包和依赖；

composer update - 从 composer.json 安装最新扩展包和依赖；

composer update vendor/package - 从 composer.json 或者对应包的配置，并更新到最新；

composer require new/package - 添加安装 new/package, 可以指定版本，如： composer require new/package ~2.5.

避坑总结

• 区分require和require-dev
• 按名称对 require 和 require-dev 中的包排序，sort-packages: true
• 开发项目要提交 composer.lock 文件到 git 版本库中
• 开发库要把 composer.lock 文件添加到 .gitignore 文件中
• 冲突解决时尽量不要手动解决
• 安全地升级依赖项
• 修改json后不要install
• 安装composer.json support插件