本系列文章主要是方便初学laravel的人入门，帮一些朋友认识到如何入门、如何学习laravel，同时补充一些忽略过的基础知识。
Laravel给了我学习新知识的一个契机，让我更早的接触更多的东西。我现在这个博客就是用laravel编写的。
刚学习laravel其实是一个痛苦的过程，不过痛苦过后，世界大不一样。原因就是造成痛苦的，不是laravel难，而是思想的陈旧带来的。laravel本身也没有运用什么超前的理念，但即使是炒的旧饭，也比馊了的来得美味一些。既然旧饭要炒一下，那就得费点小小的力气。剩饭也香啊，尤其是撒了葱花之后
。
学得越多，就应该记下来，这一系列笔记，也希望能够帮助大家。
由于网络上已经将laravel的安装步骤说的足够详细，本人也是通过这些方式安装的，没有什么特殊之处。关于安装就不在本内容中讨论，但我会在另一篇文章内讲述composer相关的内容的时候，聊一聊这一部分。
好了开始吧。
声明
第一篇文章我不打算将重心直接带到框架的使用上，而是让读者有一个清晰的概念。很多在laravel上的疑惑无非是安装上的问题、功能函数或对象方法上的问题，最后就是纠结框架结构布局和一些php基础知识上的。为了便于展开，我会着重在本文讲述一些与laravel相关的基础内容，这不但对于梳理整个框架体系有着很大的帮助，更多的是为了理解一种思想，这种思想不但适用于laravel，更适合平时项目的开发。由于我个人也在不断学习之中，本篇文章会不断更新。本文除了文字讲述，也尽量带来一些实例。在网络上现有的资源存在的情况下，本人会在文章内简要提出并给出链接，以便各位按需获得想要的。
正文
laravel是一个当下比较流行的框架，其主要特色个人认为包括以下：
- 简洁而清晰地路由定义方式
- 强大的IoC容器
- 合理的框架结构
- 丰富的第三方库
入门很简单
只要理清laravel上述的特色，基本上对laravel了解的差不多了，就算是入门了。这三样特色也恰好是laravel优雅的保证。其实laravel主要要学习的也就这么多。所以，为什么会很难？laravel真的很简单，也许只是没有找对方向，对吗？肯定是的。
我目前所了解的，包括发生在我自己身上的，为什么觉得有时候laravel很难入门：思想太过于陈旧。思想陈旧不算是贬义词，就好比你不可以说一个跟不上时代的人不如别人。但这种旧思想确实不适合laravel这种运用相对于旧思想而言的新框架。那么哪些人容易在laravel上犯难？
- 没有认认真真（再次强调，是认认真真）看文档的（占比至少97%）
- php基础不扎实的
- 不熟悉面向对象编程的
- 不熟悉面向接口编程的
- 不知匿名函数为何物的
- 不熟悉反射的
- 不喜欢命名空间的
- 不喜欢研究设计模式的
- 使用php5.4以前版本的或不喜欢运用新特性的
- 没用过composer
- 不熟悉PSR规范
上述内容不具备绝对代表性。不过确实在laravel学习上犯难的，大都存在上述因素。不幸的是，最开始我基本全部满足上述条件，不幸的成为了学习laravel最艰难的那批人。但幸运的是，我很喜欢php，为了搞懂laravel，照猫画虎，模仿着去实现laravel的功能。就是在这样一个过程里，我慢慢了解了laravel其实并不像想象中的那般高大上，无非只是用了php最为普通的一些东西。但成功必有其高明之处，laravel将php的特性发挥到了极致，使得laravel的某一些境界变得比其他框架更高。虽然其他优秀的框架不在少数，但我认为，laravel虽然整体不能够算是最好，但至少在设计思想上已经将许多（特别注明，不是全部）框架狠狠地踩在了脚底下。
要学好laravel，至少要学会做一件事：看文档。大多数人觉得入门难或不知如何入门，请老老实实看文档吧。
很多人说，laravel文档真的很渣啊，但我很负责的告诉你，你只是要上手使用，用laravel开发一个博客级别的小型应用，这个作为入门的文档算是超级详尽的了。我不是站着说话不腰疼，因为我也吐槽过。但在某一天百般无聊之下通读了整个文档，发现之前我所遇到的问题其实都写在过文档上。
吐槽laravel文档的重心不应该是不详尽，而应该是，太凌乱
laravel的文档凌乱才是大问题，虽然看得出laravel文档的结构安排的初衷是为了减少冗余的文字，但这点却让像我这种被惯坏了的用户犯了大难。往往看似应该在这一部分出现的内容却在另一篇文档内，这种安排不算奇葩也算是坑爹了。我承认，这样子的安排减少了不必要的文字，但却对初学者不友好。
这种情况举个例子：定义控制器是Route::controller()，按照常理这应该和路由部分有个交集，但在控制器介绍部分只字未提，极其容易和原本的路由定义搞混淆，因为他们都用了Route类。这只是一个典型。在数据库一块也常常出现类似问题，甚至更为严重。
但是，即使如此凌乱，也不应该成为不去读文档的理由。学习任何一个框架，都应该仔细阅读其文档。其实到最后才发现，原来laravel文档的安排对于熟悉的开发者而言，反而是很科学的，因为其归类非常明确，省去了不必要的文字感染，让你专注于这一个问题点上。所以，不要认为文档不详细，其实文档做的已经够多了。要知道，文档是为了让你能够上手使用，并不是完完全全让你彻底学透的，如果想要了解更多laravel的细节和功能，我认为应该去读一读Laravel的API文档和一部分的Symfony文档。
PHP的基础也很重要
无论用什么框架，都不要忘了这都是在做php开发，因此php的基础非常重要。框架是让编码更为方便，提高效率的，并不是为了降低某些层面的难度。
很多人在基础方面吃亏，却将其归咎于框架的错，可能这些人和我最初一样，没意识到laravel是一个在php5.4基础上开发的，用到了很多特性。其中有一个重点就是命名空间和trait。命名空间很多人不喜欢，认为这是个很麻烦的事情，别忘了命名空间是从php5.3就有的了，这是为了解决重名冲突的，同时也使代码更为规范，尤其是在自动加载的时候，这一部分参考PSR-4规范。命名空间的不熟悉会给学习laravel和一些新版本的框架带来足够多的麻烦。
想要了解php的命名空间不需要可以寻找教程，php官方文档非常详尽。
除了命名空间，还有trait，这是5.4以来的特性，适用于水平扩展类方法和功能的，通过trait可以更快的组装一个方法，具体依旧参考php官方文档，十分详尽。
其实除了trait和命名空间，作为建立在面向对象编程思想下的框架，尤其应当在整个开发中贯彻这一思想。而php的面向对象和java、C#还有C++中有些地方有着不少的差异。
习惯了php的弱类型，有些人甚至不知道php可以实现类型约束：
class foo
{
public function __construct(Closure $config)
{
//
}
}
上述例子要求初始化时必须提供一个匿名函数作为参数。
重载、魔术方法、后期静态绑定等等面向对象的基础内容，这都是学习laravel之前的必修课。当你遇到困难，很多时候会在这上面出的问题。
composer
很多人有些疑惑，如何在laravel内使用自己的类？ 很多人疑惑，一些文件应当放在laravel的哪个目录下？ 也有很多人疑惑，为什么会提示某一些类无法加载？
问这些问题的主要有两种人。一种是不了解composer的，一种是代码里存在问题的。后者占主要部分，但我想来说说前者，因为一开始我是第一种。
虽然Composer不应当是学习php和laravel的必须的，但既然被laravel所使用且composer被接受和普及已经是大势所趋，那就应当对其至少有些许了解。composer被创造的初衷是用来管理php依赖的。利用composer可以很快的引入第三方库，且这些库可以被直接使用。
Composer自带的自动加载（autoload）机制是基于PSR规范的。因此非常有必要了解PSR规范，对于自动加载，仅需了解PSR-4即可，PSR-0基本被淘汰。
由于利用好composer的自动加载，使得无论你的类库和函数放在哪都能够被加载。因此，如何在laravel中使用自己的类呢？很简单，基本上我所了解的就以下两种。
- 如果你的类库是发布到某个版本控制系统上，可以通过packagist.org发布自己的包，然后通过composer的require引入即可。
- 如果你没有使用vcs且仅仅只是在当前项目中创建的类的话，只需利用好composer的autoload即可。
Composer实现库和依赖的导入有很多种，Composer的中文文档也非常详尽，不再浪费篇幅。但这一切都需要熟悉PSR-4规范（该规范很简单，不要有芥蒂），其次就是一定要熟悉命名空间（namespace）。
同理，一些人疑惑，一些文件该放在laravel下的哪一个目录？或者说，我这个文件可以放这里吗？
这么说吧，理论上，放在哪都可以，只要是可以通过composer和laravel自带的自动加载机制载入即可，且文件是在配置内所设定的命名空间内。如果加载时出现问题，可以通过composer命令dump-autoload来解决，如果还有问题，需要检查是否命名空间和配置出现问题。