本期视频登录后即可观看
Composer 入门简介
Composer 是 PHP 最知名的包管理工具，它把文件的自动加载，文件的依赖关系以及包之间的依赖关系实现的非常出色，并且提供了简单合理而又不过分严苛的规则组织代码和搭建项目。开发者使用 Composer 可以大大加快开发的进度，因为通过composer 我们可以使用的成熟的轮子太多了，这些轮子都是经过验证过的，目前主流的开发框架以及drupal都使用composer组织项目，我们可以比较放心的使用和学习。
微信扫码登录
Composer 还是要好好掌握一下的，未必需要多精通，但是必备的基础还是要打牢一点，不然很多问题遇到后会毫无头绪。
老哥，讨论个问题，
composer
打个比方，项目之前安装了一个包a, 这个包依赖包b, 且限制了版本
后面，我们想安装包c ,这个包c 也 依赖包b, 但是 要求 版本 是 最新的，
包a，限制了包b的版本，
这个时候 包c ，安装不上，包b 更新 也只能小版本更新，不能升到最新，这个问题，如何处理好些？
这种情况出现的概率是有的，Laravel 框架版本推进的时候就遇到了这样的问题，最后解决方案就是更为严格的语义化的版本控制，核心原则就是包的质量首先要保证，所依赖的开发包必须严格按照语义化的版本控制规范进行版本的演进，不然依赖陷阱的问题早晚会出现，而且一旦出现，很多工作完全无法推进。Laravel 演进到现在，咱们就会发现，它越来越多得依赖自己的开发包，而逐步摆脱其他的开发包，核心原因就是第三方包的不确定性。
那请问现在这个问题，有什么好的解决方案么？
可以强行更新B包把，但是 对 a包 的 使用 可能 会有影响
如果指定版本和最新版本的接口已经发生较大变化，那基本就没法解决了，或者纯靠运气。保险的方式就是用最新版的，而a包的话，自己在项目中创建一个Service 目录，在Service目录中把a包的核心代码拷贝过来，封装一个只供自己项目使用的项目内部包，让这个包调用最新的b包提供的接口，保证项目能运行起来。这种方案用的还是比较多的，尤其老项目升级的时候，过去的很多包都用不了了，就自己封装内部的包（这种也算不上是包，因为只供自己使用）
如果强制更新B包呢，因为 是 由a依赖 安装的， json中 并没有 包B , 执行 composer update B ,也会被限制版本， 是要 修改 lock 文件么？
如果大版本没有发生改变的话或许可行，因为核心的接口并没有发生变化，你可以先安装C包，然后再安装A包，改变顺序之后，有可能安装成功，也是碰运气。最早valet出过这种问题，改变安装顺序就安装上了
只能这样啊，我还以为可以 强制 把 包B 升到最新， 然后 a有问题的话，在解决a包的问题
“保险的方式就是用最新版的，而a包的话，自己在项目中创建一个Service 目录，在Service目录中把a包的核心代码拷贝过来，封装一个只供自己项目使用的项目内部包，让这个包调用最新的b包提供的接口，保证项目能运行起来。“ 这种就是解决a包问题的方式，自己在内部封装一下，不使用a包了，而是使用自己改装后的a包
噢噢，也就是说，操作的话
先将a包拿出来，composer 中 卸载A , 之后安装C , 更新B,
对，自己去改装A包，然后植入系统中。
了解，您的想法了，
但是 a包 是阿里的，包含支付 oss 等，风险会有点大把
阿里啥时候出过这么全的包了？？？？
不是不是，是阿里的一个包，忘记了 是 那个 的 依赖的，不过 怕对 其他的 阿里组件的 一些有影响