来源： Crontab的格式 – Cocowool – 博客园

基本格式 :
*　　*　　*　　*　　*　　command
分　时　日　月　周　命令

第1列表示分钟1～59 每分钟用*或者 */1表示
第2列表示小时1～23（0表示0点）
第3列表示日期1～31
第4列表示月份1～12
第5列标识号星期0～6（0表示星期天）
第6列要运行的命令

crontab文件的一些例子：

30 21 * * * /usr/local/etc/rc.d/lighttpd restart
上面的例子表示每晚的21:30重启apache。

45 4 1,10,22 * * /usr/local/etc/rc.d/lighttpd restart
上面的例子表示每月1、10、22日的4 : 45重启apache。

10 1 * * 6,0 /usr/local/etc/rc.d/lighttpd restart
上面的例子表示每周六、周日的1 : 10重启apache。

0,30 18-23 * * * /usr/local/etc/rc.d/lighttpd restart
上面的例子表示在每天18 : 00至23 : 00之间每隔30分钟重启apache。

0 23 * * 6 /usr/local/etc/rc.d/lighttpd restart
上面的例子表示每星期六的11 : 00 pm重启apache。

* */1 * * * /usr/local/etc/rc.d/lighttpd restart
每一小时重启apache

* 23-7/1 * * * /usr/local/etc/rc.d/lighttpd restart
晚上11点到早上7点之间，每隔一小时重启apache

0 11 4 * mon-wed /usr/local/etc/rc.d/lighttpd restart
每月的4号与每周一到周三的11点重启apache

0 4 1 jan * /usr/local/etc/rc.d/lighttpd restart
一月一号的4点重启apache

名称 : crontab

使用权限 : 所有使用者

使用方式 :

crontab file [-u user]-用指定的文件替代目前的crontab。

crontab-[-u user]-用标准输入替代目前的crontab.

crontab-1[user]-列出用户目前的crontab.

crontab-e[user]-编辑用户目前的crontab.

crontab-d[user]-删除用户目前的crontab.

crontab-c dir- 指定crontab的目录。

crontab文件的格式：M H D m d cmd.

M: 分钟（0-59）。

H：小时（0-23）。

D：天（1-31）。

m: 月（1-12）。

d: 一星期内的天（0~6，0为星期天）。

cmd要运行的程序，程序被送入sh执行，这个shell只有USER,HOME,SHELL这三个环境变量

说明 :

crontab 是用来让使用者在固定时间或固定间隔执行程序之用，换句话说，也就是类似使用者的时程表。-u user 是指设定指定

user 的时程表，这个前提是你必须要有其权限(比如说是 root)才能够指定他人的时程表。如果不使用 -u user 的话，就是表示设

定自己的时程表。

参数 :

crontab -e : 执行文字编辑器来设定时程表，内定的文字编辑器是 VI，如果你想用别的文字编辑器，则请先设定 VISUAL 环境变数

来指定使用那个文字编辑器(比如说 setenv VISUAL joe)

crontab -r : 删除目前的时程表

crontab -l : 列出目前的时程表

crontab file [-u user]-用指定的文件替代目前的crontab。

时程表的格式如下 :

f1 f2 f3 f4 f5 program

其中 f1 是表示分钟，f2 表示小时，f3 表示一个月份中的第几日，f4 表示月份，f5 表示一个星期中的第几天。program 表示要执

行的程序。

当 f1 为 * 时表示每分钟都要执行 program，f2 为 * 时表示每小时都要执行程序，其馀类推

当 f1 为 a-b 时表示从第 a 分钟到第 b 分钟这段时间内要执行，f2 为 a-b 时表示从第 a 到第 b 小时都要执行，其馀类推

当 f1 为 */n 时表示每 n 分钟个时间间隔执行一次，f2 为 */n 表示每 n 小时个时间间隔执行一次，其馀类推

当 f1 为 a, b, c,… 时表示第 a, b, c,… 分钟要执行，f2 为 a, b, c,… 时表示第 a, b, c…个小时要执行，其馀类推

使用者也可以将所有的设定先存放在档案 file 中，用 crontab file 的方式来设定时程表。

例子 :

#每天早上7点执行一次 /bin/ls :

0 7 * * * /bin/ls

在 12 月内, 每天的早上 6 点到 12 点中，每隔3个小时执行一次 /usr/bin/backup :

0 6-12/3 * 12 * /usr/bin/backup

周一到周五每天下午 5:00 寄一封信给 alex@domain.name :

0 17 * * 1-5 mail -s “hi” alex@domain.name < /tmp/maildata

每月每天的午夜 0 点 20 分, 2 点 20 分, 4 点 20 分….执行 echo “haha”

20 0-23/2 * * * echo “haha”

注意 :

当程序在你所指定的时间执行后，系统会寄一封信给你，显示该程序执行的内容，若是你不希望收到这样的信，请在每一行空一格之

后加上 > /dev/null 2>&1 即可

例子2 :

#每天早上6点10分

10 6 * * * date

#每两个小时

0 */2 * * * date

#晚上11点到早上8点之间每两个小时，早上8点

0 23-7/2，8 * * * date

#每个月的4号和每个礼拜的礼拜一到礼拜三的早上11点

0 11 4 * mon-wed date

#1月份日早上4点

0 4 1 jan * date

范例

$crontab -l 列出用户目前的crontab.

http://www.cnblogs.com/xingzc/p/5969777.html

前一天学习了 at 命令是针对仅运行一次的任务，循环运行的例行性计划任务，linux系统则是由 cron (crond) 这个系统服务来控制的。Linux 系统上面原本就有非常多的计划性工作，因此这个系统服务是默认启动的。另外, 由于使用者自己也可以设置计划任务，所以， Linux 系统也提供了使用者控制计划任务的命令 :crontab 命令。

一、crond简介

crond是linux下用来周期性的执行某种任务或等待处理某些事件的一个守护进程，与windows下的计划任务类似，当安装完成操作系统后，默认会安装此服务工具，并且会自动启动crond进程，crond进程每分钟会定期检查是否有要执行的任务，如果有要执行的任务，则自动执行该任务。

Linux下的任务调度分为两类，系统任务调度和用户任务调度。

系统任务调度：系统周期性所要执行的工作，比如写缓存数据到硬盘、日志清理等。在/etc目录下有一个crontab文件，这个就是系统任务调度的配置文件。

/etc/crontab文件包括下面几行：

[root@localhost ~]# cat /etc/crontab

SHELL=/bin/bash

PATH=/sbin:/bin:/usr/sbin:/usr/bin

MAILTO=””HOME=/

# run-parts

51 * * * * root run-parts /etc/cron.hourly

24 7 * * * root run-parts /etc/cron.daily

22 4 * * 0 root run-parts /etc/cron.weekly

42 4 1 * * root run-parts /etc/cron.monthly

[root@localhost ~]#

前四行是用来配置crond任务运行的环境变量，第一行SHELL变量指定了系统要使用哪个shell，这里是bash，第二行PATH变量指定了系统执行命令的路径，第三行MAILTO变量指定了crond的任务执行信息将通过电子邮件发送给root用户，如果MAILTO变量的值为空，则表示不发送任务执行信息给用户，第四行的HOME变量指定了在执行命令或者脚本时使用的主目录。第六至九行表示的含义将在下个小节详细讲述。这里不在多说。

用户任务调度：用户定期要执行的工作，比如用户数据备份、定时邮件提醒等。用户可以使用 crontab 工具来定制自己的计划任务。所有用户定义的crontab 文件都被保存在 /var/spool/cron目录中。其文件名与用户名一致。

使用者权限文件：

文件：

/etc/cron.deny

说明：

该文件中所列用户不允许使用crontab命令

文件：

/etc/cron.allow

说明：

该文件中所列用户允许使用crontab命令

文件：

/var/spool/cron/

说明：

所有用户crontab文件存放的目录,以用户名命名

crontab文件的含义：

用户所建立的crontab文件中，每一行都代表一项任务，每行的每个字段代表一项设置，它的格式共分为六个字段，前五段是时间设定段，第六段是要执行的命令段，格式如下：

minute   hour   day   month   week   command

其中：

minute： 表示分钟，可以是从0到59之间的任何整数。

hour：表示小时，可以是从0到23之间的任何整数。

day：表示日期，可以是从1到31之间的任何整数。

month：表示月份，可以是从1到12之间的任何整数。

week：表示星期几，可以是从0到7之间的任何整数，这里的0或7代表星期日。

command：要执行的命令，可以是系统命令，也可以是自己编写的脚本文件。

在以上各个字段中，还可以使用以下特殊字符：

星号（*）：代表所有可能的值，例如month字段如果是星号，则表示在满足其它字段的制约条件后每月都执行该命令操作。

逗号（,）：可以用逗号隔开的值指定一个列表范围，例如，“1,2,5,7,8,9”

中杠（-）：可以用整数之间的中杠表示一个整数范围，例如“2-6”表示“2,3,4,5,6”

正斜线（/）：可以用正斜线指定时间的间隔频率，例如“0-23/2”表示每两小时执行一次。同时正斜线可以和星号一起使用，例如*/10，如果用在minute字段，表示每十分钟执行一次。

二、crond服务

安装crontab：

yum install crontabs

服务操作说明：

/sbin/service crond start //启动服务

/sbin/service crond stop //关闭服务

/sbin/service crond restart //重启服务

/sbin/service crond reload //重新载入配置

查看crontab服务状态：

service crond status

手动启动crontab服务：

service crond start

查看crontab服务是否已设置为开机启动，执行命令：

ntsysv

加入开机自动启动：

chkconfig –level 35 crond on

三、crontab命令详解

1．命令格式：

crontab [-u user] file

crontab [-u user] [ -e | -l | -r ]

2．命令功能：

通过crontab 命令，我们可以在固定的间隔时间执行指定的系统指令或 shell script脚本。时间间隔的单位可以是分钟、小时、日、月、周及以上的任意组合。这个命令非常设合周期性的日志分析或数据备份等工作。

3．命令参数：

-u user：用来设定某个用户的crontab服务，例如，“-u ixdba”表示设定ixdba用户的crontab服务，此参数一般有root用户来运行。

file：file是命令文件的名字,表示将file做为crontab的任务列表文件并载入crontab。如果在命令行中没有指定这个文件，crontab命令将接受标准输入（键盘）上键入的命令，并将它们载入crontab。

-e：编辑某个用户的crontab文件内容。如果不指定用户，则表示编辑当前用户的crontab文件。

-l：显示某个用户的crontab文件内容，如果不指定用户，则表示显示当前用户的crontab文件内容。

-r：从/var/spool/cron目录中删除某个用户的crontab文件，如果不指定用户，则默认删除当前用户的crontab文件。

-i：在删除用户的crontab文件时给确认提示。

4．常用方法：

1). 创建一个新的crontab文件

在考虑向cron进程提交一个crontab文件之前，首先要做的一件事情就是设置环境变量EDITOR。cron进程根据它来确定使用哪个编辑器编辑crontab文件。9 9 %的UNIX和LINUX用户都使用vi，如果你也是这样，那么你就编辑$ HOME目录下的. profile文件，在其中加入这样一行：

EDITOR=vi; export EDITOR

然后保存并退出。不妨创建一个名为<user> cron的文件，其中<user>是用户名，例如， davecron。在该文件中加入如下的内容。

# (put your own initials here)echo the date to the console every

# 15minutes between 6pm and 6am

0,15,30,45 18-06 * * * /bin/echo ‘date’ > /dev/console

保存并退出。确信前面5个域用空格分隔。

在上面的例子中，系统将每隔1 5分钟向控制台输出一次当前时间。如果系统崩溃或挂起，从最后所显示的时间就可以一眼看出系统是什么时间停止工作的。在有些系统中，用tty1来表示控制台，可以根据实际情况对上面的例子进行相应的修改。为了提交你刚刚创建的crontab文件，可以把这个新创建的文件作为cron命令的参数：

$ crontab davecron

现在该文件已经提交给cron进程，它将每隔1 5分钟运行一次。

同时，新创建文件的一个副本已经被放在/var/spool/cron目录中，文件名就是用户名(即dave)。

2). 列出crontab文件

为了列出crontab文件，可以用：

$ crontab -l

0,15,30,45,18-06 * * * /bin/echo `date` > dev/tty1

你将会看到和上面类似的内容。可以使用这种方法在$ H O M E目录中对crontab文件做一备份：

$ crontab -l > $HOME/mycron

这样，一旦不小心误删了crontab文件，可以用上一节所讲述的方法迅速恢复。

3). 编辑crontab文件

如果希望添加、删除或编辑crontab文件中的条目，而E D I TO R环境变量又设置为v i，那么就可以用v i来编辑crontab文件，相应的命令为：

$ crontab -e

可以像使用v i编辑其他任何文件那样修改crontab文件并退出。如果修改了某些条目或添加了新的条目，那么在保存该文件时， c r o n会对其进行必要的完整性检查。如果其中的某个域出现了超出允许范围的值，它会提示你。

我们在编辑crontab文件时，没准会加入新的条目。例如，加入下面的一条：

# DT:delete core files,at 3.30am on 1,7,14,21,26,26 days of each month

30 3 1,7,14,21,26 * * /bin/find -name “core’ -exec rm {} \;

现在保存并退出。最好在crontab文件的每一个条目之上加入一条注释，这样就可以知道它的功能、运行时间，更为重要的是，知道这是哪位用户的作业。

现在让我们使用前面讲过的crontab -l命令列出它的全部信息：

$ crontab -l

# (crondave installed on Tue May 4 13:07:43 1999)

# DT:ech the date to the console every 30 minites

0,15,30,45 18-06 * * * /bin/echo `date` > /dev/tty1

# DT:delete core files,at 3.30am on 1,7,14,21,26,26 days of each month

30 3 1,7,14,21,26 * * /bin/find -name “core’ -exec rm {} \;

4). 删除crontab文件

要删除crontab文件，可以用：

$ crontab -r

5). 恢复丢失的crontab文件

如果不小心误删了crontab文件，假设你在自己的$ H O M E目录下还有一个备份，那么可以将其拷贝到/var/spool/cron/<username>，其中<username>是用户名。如果由于权限问题无法完成拷贝，可以用：

$ crontab <filename>

其中，<filename>是你在$ H O M E目录中副本的文件名。

我建议你在自己的$ H O M E目录中保存一个该文件的副本。我就有过类似的经历，有数次误删了crontab文件（因为r键紧挨在e键的右边）。这就是为什么有些系统文档建议不要直接编辑crontab文件，而是编辑该文件的一个副本，然后重新提交新的文件。

有些crontab的变体有些怪异，所以在使用crontab命令时要格外小心。如果遗漏了任何选项，crontab可能会打开一个空文件，或者看起来像是个空文件。这时敲delete键退出，不要按<Ctrl-D>，否则你将丢失crontab文件。

5．使用实例

实例1：每1分钟执行一次command

命令：

* * * * * command

实例2：每小时的第3和第15分钟执行

命令：

3,15 * * * * command

实例3：在上午8点到11点的第3和第15分钟执行

命令：

3,15 8-11 * * * command

实例4：每隔两天的上午8点到11点的第3和第15分钟执行

命令：

3,15 8-11 */2 * * command

实例5：每个星期一的上午8点到11点的第3和第15分钟执行

命令：

3,15 8-11 * * 1 command

实例6：每晚的21:30重启smb

命令：

30 21 * * * /etc/init.d/smb restart

实例7：每月1、10、22日的4 : 45重启smb

命令：

45 4 1,10,22 * * /etc/init.d/smb restart

实例8：每周六、周日的1 : 10重启smb

命令：

10 1 * * 6,0 /etc/init.d/smb restart

实例9：每天18 : 00至23 : 00之间每隔30分钟重启smb

命令：

0,30 18-23 * * * /etc/init.d/smb restart

实例10：每星期六的晚上11 : 00 pm重启smb

命令：

0 23 * * 6 /etc/init.d/smb restart

实例11：每一小时重启smb

命令：

* */1 * * * /etc/init.d/smb restart

实例12：晚上11点到早上7点之间，每隔一小时重启smb

命令：

* 23-7/1 * * * /etc/init.d/smb restart

实例13：每月的4号与每周一到周三的11点重启smb

命令：

0 11 4 * mon-wed /etc/init.d/smb restart

实例14：一月一号的4点重启smb

命令：

0 4 1 jan * /etc/init.d/smb restart

实例15：每小时执行/etc/cron.hourly目录内的脚本

命令：

01   *   *   *   *     root run-parts /etc/cron.hourly

说明：

run-parts这个参数了，如果去掉这个参数的话，后面就可以写要运行的某个脚本名，而不是目录名了

四、使用注意事项

1. 注意环境变量问题

有时我们创建了一个crontab，但是这个任务却无法自动执行，而手动执行这个任务却没有问题，这种情况一般是由于在crontab文件中没有配置环境变量引起的。

在crontab文件中定义多个调度任务时，需要特别注意的一个问题就是环境变量的设置，因为我们手动执行某个任务时，是在当前shell环境下进行的，程序当然能找到环境变量，而系统自动执行任务调度时，是不会加载任何环境变量的，因此，就需要在crontab文件中指定任务运行所需的所有环境变量，这样，系统执行任务调度时就没有问题了。

不要假定cron知道所需要的特殊环境，它其实并不知道。所以你要保证在shelll脚本中提供所有必要的路径和环境变量，除了一些自动设置的全局变量。所以注意如下3点：

1）脚本中涉及文件路径时写全局路径；

2）脚本执行要用到java或其他环境变量时，通过source命令引入环境变量，如：

cat start_cbp.sh

#!/bin/sh

source /etc/profile

export RUN_CONF=/home/d139/conf/platform/cbp/cbp_jboss.conf

/usr/local/jboss-4.0.5/bin/run.sh -c mev &

3）当手动执行脚本OK，但是crontab死活不执行时。这时必须大胆怀疑是环境变量惹的祸，并可以尝试在crontab中直接引入环境变量解决问题。如：

0 * * * * . /etc/profile;/bin/sh /var/www/java/audit_no_count/bin/restart_audit.sh

2. 注意清理系统用户的邮件日志

每条任务调度执行完毕，系统都会将任务输出信息通过电子邮件的形式发送给当前系统用户，这样日积月累，日志信息会非常大，可能会影响系统的正常运行，因此，将每条任务进行重定向处理非常重要。

例如，可以在crontab文件中设置如下形式，忽略日志输出：

0 */3 * * * /usr/local/apache2/apachectl restart >/dev/null 2>&1

“/dev/null 2>&1”表示先将标准输出重定向到/dev/null，然后将标准错误重定向到标准输出，由于标准输出已经重定向到了/dev/null，因此标准错误也会重定向到/dev/null，这样日志输出问题就解决了。

3. 系统级任务调度与用户级任务调度

系统级任务调度主要完成系统的一些维护操作，用户级任务调度主要完成用户自定义的一些任务，可以将用户级任务调度放到系统级任务调度来完成（不建议这么做），但是反过来却不行，root用户的任务调度操作可以通过“crontab –uroot –e”来设置，也可以将调度任务直接写入/etc/crontab文件，需要注意的是，如果要定义一个定时重启系统的任务，就必须将任务放到/etc/crontab文件，即使在root用户下创建一个定时重启系统的任务也是无效的。

4. 其他注意事项

新创建的cron job，不会马上执行，至少要过2分钟才执行。如果重启cron则马上执行。

当crontab突然失效时，可以尝试/etc/init.d/crond restart解决问题。或者查看日志看某个job有没有执行/报错tail -f /var/log/cron。

千万别乱运行crontab -r。它从Crontab目录（/var/spool/cron）中删除用户的Crontab文件。删除了该用户的所有crontab都没了。

在crontab中%是有特殊含义的，表示换行的意思。如果要用的话必须进行转义\%，如经常用的date ‘+%Y%m%d’在crontab里是不会执行的，应该换成date ‘+\%Y\%m\%d’。

我在网上找的时候发现网上主要说了这5个原因：1 crond服务未启动crontab不是Linux内核的功能，而是依赖一个crond服务，这个服务可以启动当然也可以停止。如果停止了就无法执行任何定时任务了，解决的方法是打开它:crond或service crond start如果提示crond命令不存在，可能被误删除了，CentOS下可以通过这个命

来源： crontab定时任务不执行的原因 – u011734144的专栏 – 博客频道 – CSDN.NET

我在网上找的时候发现网上主要说了这5个原因：

1 crond服务未启动

crontab不是Linux内核的功能，而是依赖一个crond服务，这个服务可以启动当然也可以停止。如果停止了就无法执行任何定时任务了，解决的方法是打开它:

crond

或

service crond start

如果提示crond命令不存在，可能被误删除了，CentOS下可以通过这个命令重新安装：

yum -y install crontabs

2 权限问题

比如：脚本没有x执行权限，解决方法：

增加执行权限，或者用bash abc.sh的方法执行

3 路径问题

有的命令在shell中执行正常，但是在crontab执行却总是失败。有可能是因为crontab使用的sh未正确识别路径，比如：以root身份登录shell后执行一个/root/test.sh，只要执行

./test.sh

就可以了。但是在crontab中，就会找不到这个脚本，比如写完整：

/root/test.sh

4 时差问题

因为服务器与客户端时差问题，所以crontab的时间以服务器时间为准。

5 变量问题

有时候命令中含有变量，但crontab执行时却没有，也会造成执行失败。

验证后，我的定时脚本test.sh不执行不是上述任何一种原因，其实我的脚本就一句话：

我希望通过这种方式来测试 我设置的定时脚本起作用了，于是我设置了该脚本每分钟执行一次，但是死活在脚本所在目录看不到这个文件，我手动执行

# sh test.sh

却能看到在脚本所在目录能看到这个文件

我怀疑是crontab根本没有执行，于是我在crontab中直接添加了

testFile文件生成了，说明crontab是执行了的，那看来是我脚本自身存在问题

最后发现，原来是testFile这里必须写完整的路径，我天真的以为testFile会生成在脚本所在的目录，所以改成了如下形式

然后就可以了。

其实路径是个非常容易出问题的地方，假设在/home/denglinjie目录下有一个脚本文件test1.sh，然后在该目录下还有一个脚本文件test2.sh

在test1.sh中执行了test2.sh，而且用的是相对路径，即相对test1.sh所在的路径。

如果在crontab -e中编辑的时候，执行的方式是

sh /home/denglinjie/test1.sh，当执行到调用sh test2.sh的时候，系统会认为是从crontab文件所在的目录去找test2.sh，但是其实是找不到的，造成执行失败

最开始我想的方法是，我要将我写的待执行的脚本文件以及被调用的其他的脚本和crontab文件放到一个地方，这样就可以拉，但是失败了，可能是因为权限问题，我进不去/var/spool/cron目录。

所以另外一个解决方法就是在执行脚本之前先通过 cd   /home/denglinjie 命令进入到脚本所在目录

Cron是一个linux下的定时执行工具，可以在无需人工干预的情况下运行作业。由于Cron 是Linux的内置服务，但它不自动起来，可以用以下的方法启动、关闭这个服务：

/sbin/service crond start //启动服务
/sbin/service crond stop //关闭服务
/sbin/service crond restart //重启服务
/sbin/service crond reload //重新载入配置

你也可以将这个服务在系统启动的时候自动启动：
在/etc/rc.d/rc.local这个脚本的末尾加上：
/sbin/service crond start

现在Cron这个服务已经在进程里面了，我们就可以用这个服务了，Cron服务提供以下几种接口供大家使用：

1 直接用crontab命令编辑

cron服务提供crontab命令来设定cron服务的，以下是这个命令的一些参数与说明：

crontab -u //设定某个用户的cron服务，一般root用户在执行这个命令的时候需要此参数
crontab -l //列出某个用户cron服务的详细内容
crontab -r //删除某个用户的cron服务
crontab -e //编辑某个用户的cron服务

例：用crontab自动更新时间

*/1 * * * * /usr/sbin/ntpdate 210.72.145.44;
echo “$(date)”>>/tmp/updatetimes
> /dev/null 2>&1

2 解决cron自动发送邮件问题:

linux没有装sendmail,但你会发现crontab每执行一次任务都要给系统发信,没有找到sendmail还去执行，产生很多讨厌的垃圾文件。

先想办法不让crontab记录执行的命令:

crontab -e

在执行的命令后面加上 >/dev/null 2>&1

这样日志里虽然没有命令了但还有CRON: Exec of (/usr/lib/sendmail) failed: (No such file or directory)

检查下来发现这个没法解决,似乎是crond这个程序里已经固定好的,/etc/crontab也不能关闭,不可能去修改crontab的源码再编译.

于是 touch /usr/lib/sendmail

创建一个空白的sendmail文件,让crond去调!

再把/etc/syslog.conf的cron info的关掉. 终于 cron的log日志清净了.

概述  备份是容灾的基础，是指为防止系统出现操作失误或系统故障导致数据丢失，而将全部或部分数据集合从应用主机的硬盘或阵列复制到其它的存储介质的过程。而对于一些网站、系统来说，数据库就是一切，所以做好数据库的备份是至关重要的！备份是什么？为什么要备份容灾方案建设存储介质光盘 磁带 硬盘 磁盘阵列 DAS：直接附加存储 NAS：网络附加存储 SAN：存储区域网络 云存储这里主要以本地磁盘为

来源： linux下如何实现mysql数据库每天自动备份定时备份 – 无知人生，记录点滴 – 博客频道 – CSDN.NET

概述

备份是容灾的基础，是指为防止系统出现操作失误或系统故障导致数据丢失，而将全部或部分数据集合从应用主机的硬盘或阵列复制到其它的存储介质的过程。而对于一些网站、系统来说，数据库就是一切，所以做好数据库的备份是至关重要的！

备份是什么？

为什么要备份

容灾方案建设

存储介质

光盘
磁带
硬盘
磁盘阵列
DAS：直接附加存储
NAS：网络附加存储
SAN：存储区域网络
云存储

这里主要以本地磁盘为存储介质讲一下计划任务的添加使用，基本的备份脚本，其它存储介质只是介质的访问方式可能不大一样。

1、查看磁盘空间情况：

既然是定时备份，就要选择一个空间充足的磁盘空间，避免出现因空间不足导致备份失败，数据丢失的恶果！
存储到当前磁盘这是最简单，却是最不推荐的；服务器有多块硬盘，最好是把备份存放到另一块硬盘上；有条件就选择更好更安全的存储介质；

# df -h
Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root   50G   46G  1.6G  97% /
tmpfs                         1.9G   92K  1.9G   1% /dev/shm
/dev/sda1                     485M   39M  421M   9% /boot
/dev/mapper/VolGroup-lv_home  534G  3.6G  503G   1% /home

2、创建备份目录：

上面我们使用命令看出/home下空间比较充足，所以可以考虑在/home保存备份文件；

cd /home
mkdir backup
cd backup

3、创建备份Shell脚本:

注意把以下命令中的DatabaseName换为实际的数据库名称；
当然，你也可以使用其实的命名规则！

vi bkDatabaseName.sh

输入/粘贴以下内容：

#!/bin/bash
mysqldump -uusername -ppassword DatabaseName > /home/backup/DatabaseName_$(date +%Y%m%d_%H%M%S).sql

对备份进行压缩：

#!/bin/bash
mysqldump -uusername -ppassword DatabaseName | gzip > /home/backup/DatabaseName_$(date +%Y%m%d_%H%M%S).sql.gz

注意：
把 username 替换为实际的用户名；
把 password 替换为实际的密码；
把 DatabaseName 替换为实际的数据库名；

4、添加可执行权限：

chmod u+x bkDatabaseName.sh

添加可执行权限之后先执行一下，看看脚本有没有错误，能不能正常使用；

./bkDatabaseName.sh

5、添加计划任务

检测或安装 crontab

确认crontab是否安装：
执行 crontab 命令如果报 command not found，就表明没有安装

# crontab
-bash: crontab: command not found

如时没有安装 crontab，需要先安装它，具体步骤请参考：
CentOS下使用yum命令安装计划任务程序crontab
使用rpm命令从CentOS系统盘安装计划任务程序crontab

添加计划任务

执行命令：

crontab -e

这时就像使用vi编辑器一样，可以对计划任务进行编辑。
输入以下内容并保存：

*/1 * * * * /home/backup/bkDatabaseName.sh

具体是什么意思呢？
意思是每一分钟执行一次shell脚本“/home/backup/bkDatabaseName.sh”。

6、测试任务是否执行

很简单，我们就执行几次“ls”命令，看看一分钟过后文件有没有被创建就可以了！

如果任务执行失败了，可以通过以下命令查看任务日志：

# tail -f /var/log/cron

输出类似如下：

Sep 30 14:01:01 bogon run-parts(/etc/cron.hourly)[2503]: starting 0anacron
Sep 30 14:01:01 bogon run-parts(/etc/cron.hourly)[2512]: finished 0anacron
Sep 30 15:01:01 bogon CROND[3092]: (root) CMD (run-parts /etc/cron.hourly)
Sep 30 15:01:01 bogon run-parts(/etc/cron.hourly)[3092]: starting 0anacron
Sep 30 15:01:02 bogon run-parts(/etc/cron.hourly)[3101]: finished 0anacron
Sep 30 15:50:44 bogon crontab[3598]: (root) BEGIN EDIT (root)
Sep 30 16:01:01 bogon CROND[3705]: (root) CMD (run-parts /etc/cron.hourly)
Sep 30 16:01:01 bogon run-parts(/etc/cron.hourly)[3705]: starting 0anacron
Sep 30 16:01:01 bogon run-parts(/etc/cron.hourly)[3714]: finished 0anacron
Sep 30 16:15:29 bogon crontab[3598]: (root) END EDIT (root)

来源： lnmp 环境require(): open_basedir restriction in effect 错误 – 猴子请我来帮忙 – 博客园

最近配置开发用的lnmp环境，环境配置完成后，爆500错误，查看nginx错误日志

open_basedir 将 PHP 所能打开的文件限制在指定的目录树，包括文件本身

错误日志显示，访问脚本不在 open_basedir的限定目录里面，配置open_basedir 一般会在php.ini 或 nginx 配置文件里面

首先检测php.ini 我发现并没有配置 open_basedir

然后检测nginx配置

发现 fastcgi.conf 中配置了open_basedir $document_root指向的是网站跟目录 /home/www/yii/web,我的项目用的是php2.0 框架需要解析 /home/www/yii 下面的php文件

由于我配置的是开发环境 ，简单粗暴就把fastcgi.conf 里面open_basedir给注释掉了，线上环境建议 把$document_root 更改为 需要解析的网站目录

然后就可以愉快的玩耍了

来源： laravel安装使用、目录权限设置 – 东东东 陈煜东的博客

前置条件

增加mcrypt

如果想偷懒ubuntu用户直接 apt-get install php5-mcrypt，发现还是不能用，修改/usr/local/php/lib/php.ini（每个人有差异，同时cli模式下也需要增加）增加下面内容

如果你想自己编译安装，可以参考下文的openssl安装方法。

增加openssl的配置

我是从之前的PHP源码编译安装的。因为我之前的PHP源码还在的。

进入到/usr/local/php/lib/php.ini增加

重启php-fpm。

安装

自己动手，丰衣足食版

1. 先安装composer，参考官方文档
2. 然后下载laravel的最新版，解压缩。
3. 进入到目录下方compuser install
4. 这个会让你的文件目录下多vendor。

懒人版

下载一个完整的laravel，然后解压缩就能用，不用为laravel安装组件。

这个的缺点就是你要更新你的laravel，会依赖于其他人更新。

我的方法

我是在自己的本地安装了一个composer，然后自己去下载最新的laravel组件，最后把整个包压缩上传到服务器去。不过这样更新生产环境的laravel会比较麻烦。不管了，一本开发了也不会对框架做太多的更新。

如果你迫不及待的访问url，会出现一些错误error in exception handler.。这个是因为写缓存、日志目录的没有写权限

为目录设置正确的写权限

/app/storage这个目录是laravel的一些写文件的目录，会写log、session、页面缓存等数据，所以要对这个目录设置正确的权限。

如果你为了方便设置chmod +777 app/storage也是可以的。但是我还是不推荐。

我推荐将目录的权限设置为会写文件的用户名和用户组。

然后配置nginx就能访问了。

更改成Debug模式，查看错误信息

有时候会出现问题，有不知道具体的信息，所以需要打开laravel的Debug模式，可能查看更多的输出。

进入到laravel项目的/app/config/app.php

来源： PHP二维码生成的方法(google APi,PHP类库,libqrencode等) – 博客频道 – CSDN.NET

来源： lnmp+laravel部署到服务器出现 “GET / HTTP/1.1” 500 5 – and大头 – 博客园

lnmp一键安装包直接下载安装，就可以了，在此不多说。

虚拟机配置给个参考（lnmp安装包）

server
    {
        listen 80;
        #listen [::]:80;
        server_name www.dtcode.cn dtcode.cn;
        index index.html index.htm index.php default.html default.htm default.php;
        set $root  /home/wwwroot/laravel;
        root    /home/wwwroot/laravel/public;

        #include other.conf;
        #error_page   404   /404.html;
        include enable-php.conf;

location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
        {
            expires      30d;
        }

        location ~ .*\.(js|css)?$
        {
            expires      12h;
        }

 location / {
                try_files $uri $uri/ /index.php?$query_string;
        }
location ~ \.php$ {
            fastcgi_pass 127.0.0.1:9000;
            fastcgi_index /index.php;

            fastcgi_split_path_info       ^(.+\.php)(/.+)$;
            fastcgi_param PATH_INFO       $fastcgi_path_info;
            fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            include                       fastcgi_params;
     }

 location ~ /\.
        {
           deny all;
        }

        access_log  /home/wwwlogs/laravel_log.log;
    }

然后运行出现 500 Internal Server Error ，到这个我就怕了，解决方法

更改 laravel/storage   和 laravel/bootstrap/cache   权限为 777

同时修laravel改项目目录文件全限为 775，所属组 www

chown -R www   laravel

 chmod -R 775   laravel

错误继续出现： chown: changing ownership of `question/public/.user.ini’: Operation not permitted

发现root用户对该文件也没有-x执行权限。通过网上查找才知道，原来该文件被chattr锁定了。这里就了解了一下Linux的chattr和lsattr命令。

这两个命令是用来查看和改变文件目录属性的，和chmod相比，chmod只是改变文件的读写、执行权限，更底层的属性控制是由chattr来改变的。而lsattr命令是显示chattr命令设置的文件属性。所以，这里需要使用chattr命令对.user.ini文件解锁

解决办法，修改项目根目录，.user.ini文件

1.先给.user.ini 可以修改的权限
#chattr -i .user.ini
2.然后修改
# vi .use.ini
3.修改.use.ini内容
open_basedir=/home/wwwroot/default/laravel/public:/tmp/:/proc/
改为
open_basedir=/home/wwwroot/default/laravel/:/tmp/:/proc/
4.最后更改.user.ini权限为不能修改
#chattr +i .user.ini

环境要求：      操作系统：centOS；    PHP 5.4.4 (>=5.4即可)首先装好composer curl -sS https://getcomposer.org/installer | php mv composer.phar /usr/local/bin/composer安装完成，使用以下命令看是否安装成功composer -V安

来源： lnmp 安装laravel框架 – ZzyYeMen – 博客频道 – CSDN.NET

环境要求：

操作系统：centOS；

PHP 5.4.4 (>=5.4即可)

首先装好composer

安装完成，使用以下命令看是否安装成功

安装Laravel依赖于一些的php扩展

安装完成后，在Nginx的配置文件配置

配置好后咱们就开始安装laravel

大约8分钟时间，差不多就安装好了，最后来到你的laravel工程目录下，看到storage和vendor文件夹，使用以下命令修改其文件读写权限，让Nginx用户能读写它

来源： laravel启动过程简单解析 – wish123 – 博客园

laravel的启动过程

如果没有使用过类似Yii之类的框架，直接去看laravel，会有点一脸迷糊的感觉，起码我是这样的。laravel的启动过程，也是laravel的核心，对这个过程有一个了解，有助于得心应手的使用框架，希望能对大家有点帮助。
提示：在此之前，最好看一下官方文档，大概知道laravel，再来看这个笔记，这样效果可能会好一点。

统一入口

laravel框架使用了统一入口，入口文件：/public/index.php

<?php
//自动加载文件设置
require __DIR__.'/../bootstrap/autoload.php';

//初始化服务容器（可以查看一下关于‘服务容器’的相关文档）
$app = require_once __DIR__.'/../bootstrap/app.php';

//通过服务容器生成一个kernel类的实例（Illuminate\Contracts\Http\Kernel实际上只是一个接口，真正生成的实例是App\Http\Kernel类，至于怎么把接口和类关联起来，请查看Contracts相关文档）
$kernel = $app->make('Illuminate\Contracts\Http\Kernel');

//运行Kernel类的handle方法，主要动作是运行middleware和启动URL相关的Contrller
$response = $kernel->handle(
    $request = Illuminate\Http\Request::capture()
);

//控制器返回结果之后的操作，暂时还没看，以后补上
$response->send();

$kernel->terminate($request, $response);

相关链接

服务容器
Contracts协议模式

自动加载文件

laravel的自动加载，其实也就是Composer的自动加载

我的理解是，Composer根据声明的依赖关系，从相关库的源下载代码文件，并根据依赖关系在 Composer 目录下生成供类自动加载的 PHP 脚本，使用的时候，项目开始处引入 “/vendor/autoload.php” 文件，就可以直接实例化这些第三方类库中的类了。那么，Composer 是如何实现类的自动加载的呢？接下来，我们从 laravel 的入口文件开始顺藤摸瓜往里跟进，来一睹 Composer 自动加载的奥妙。

代码清单/bootstrap/autoload.php

<?php
define('LARAVEL_START', microtime(true));

//这就是传说中Composer的自动加载文件
require __DIR__.'/../vendor/autoload.php';

//Composer自动生成的各个核心类的集合，如果你需要修改一些vendor里面的文件来查看一些laravel运行细节，那么就请删除此文件
$compiledPath = __DIR__.'/../vendor/compiled.php';

if (file_exists($compiledPath))
{
    require $compiledPath;
}

代码清单 laravel/vendor/autoload.php

<?php

// autoload.php @generated by Composer

require_once __DIR__ . '/composer' . '/autoload_real.php';
//别被吓到了,他就是autoload_real.php文件的类名而已
return ComposerAutoloaderInit03dc6c3c47809c398817ca33ec5f6a01::getLoader();

代码清单laravel/vendor/composer/autoload_real.php：
主要是getLoader方法里面，加了注释的几行，这是关键

<?php

// autoload_real.php @generated by Composer

class ComposerAutoloaderInit03dc6c3c47809c398817ca33ec5f6a01
{
    private static $loader;

    public static function loadClassLoader($class)
    {
        if ('Composer\Autoload\ClassLoader' === $class) {
            require __DIR__ . '/ClassLoader.php';
        }
    }

    public static function getLoader()
    {
        if (null !== self::$loader) {
            return self::$loader;
        }

        spl_autoload_register(array('ComposerAutoloaderInit03dc6c3c47809c398817ca33ec5f6a01', 'loadClassLoader'), true, true);
        self::$loader = $loader = new \Composer\Autoload\ClassLoader();
        spl_autoload_unregister(array('ComposerAutoloaderInit03dc6c3c47809c398817ca33ec5f6a01', 'loadClassLoader'));

        $includePaths = require __DIR__ . '/include_paths.php';
        array_push($includePaths, get_include_path());
        set_include_path(join(PATH_SEPARATOR, $includePaths));

        //Psr0标准-设置命名空间对应的路径，以便于随后自动加载相关类文件（看看psr0和psr4的区别）
        $map = require __DIR__ . '/autoload_namespaces.php';
        foreach ($map as $namespace => $path) {
            $loader->set($namespace, $path);
        }
        //Psr4标准-设置命名空间对应的路径，以便于随后自动加载相关类文件（看看psr0和psr4的区别）
        $map = require __DIR__ . '/autoload_psr4.php';
        foreach ($map as $namespace => $path) {
            $loader->setPsr4($namespace, $path);
        }

        //设置类文件路径与类名的对应关系，以便于随后自动加载相关类文件（可能你有一部分类，由于历史原因，他们的命名空间不遵守PSR0和PSR4，你就可以使用此方法自动加载）
        $classMap = require __DIR__ . '/autoload_classmap.php';
        if ($classMap) {
            $loader->addClassMap($classMap);
        }

        //根据上述三种方法注册自动加载文档的方法，可以查看一下PHP的spl_autoload_register和__autoload方法
        $loader->register(true);

        //加载公用方法，比如app()方法取得一个application实例，就是这里加载的，可以查看一下autoload_files.php文件都加载了什么公用方法，有很多关于 array的操作方法哦
        $includeFiles = require __DIR__ . '/autoload_files.php';
        foreach ($includeFiles as $file) {
            composerRequire03dc6c3c47809c398817ca33ec5f6a01($file);
        }

        return $loader;
    }
}

function composerRequire03dc6c3c47809c398817ca33ec5f6a01($file)
{
    require $file;
}

对于laravel自动加载过程的总结

laravel自动加载的过程就是这样实现的，总结为四种加载方式:

1. PSR0加载方式—对应的文件就是autoload_namespaces.php
2. PSR4加载方式—对应的文件就是autoload_psr4.php
3. 其他加载类的方式—对应的文件就是autoload_classmap.php
4. 加载公用方法—对应的文件就是autoload_files.php

怎么样自定义自动加载方式

如果某些文件，需要自动自定义加载方式，可以在Composer.json文件中定义

"autoload" : {
        //以第一种方式自动加载，表示app目录下的所有类的命名空间都是以Apppsr0开始且遵循psr0规范（注意：您的laravel中没有此项，作为示意例子）
        "psr-0" : {
            "AppPsr0": "apppsr0/"
        }，
        //以第二种方式自动加载，表示app目录下的所有类的命名空间都是以App开始且遵循psr4规范
        "psr-4" : {
            "App\\": "app/"
        }，
        //以第三种加载方式自动加载，它会将所有.php和.inc文件中的类提出出来然后以类名作为key，类的路径作为值
        "classmap" : ["database"],
        //以第四种加载方式自动加载,composer会把这些文件都include进来（注意：您的laravel中没有此项，作为示意例子）
        "files" : ["common/util.php"]

    }

相关文档链接

Compposer中文文档

服务容器——laravel真正的核心

服务容器，也叫IOC容器，其实包含了依赖注入(DI)和控制反转(IOC)两部分，是laravel的真正核心。其他的各种功能模块比如 Route（路由）、Eloquent ORM（数据库 ORM 组件）、Request and Response（请求和响应）等等等等，实际上都是与核心无关的类模块提供的，这些类从注册到实例化，最终被你所使用，其实都是 laravel 的服务容器负责的。服务容器这个概念比较难解释清楚，只能一步步从服务容器的产生历史慢慢解释

IoC 容器诞生的故事——石器时代（原始模式）

我们把一个“超人”作为一个类，

class Superman {}

我们可以想象，一个超人诞生的时候肯定拥有至少一个超能力，这个超能力也可以抽象为一个对象，为这个对象定义一个描述他的类吧。一个超能力肯定有多种属性、（操作）方法，这个尽情的想象，但是目前我们先大致定义一个只有属性的“超能力”，至于能干啥，我们以后再丰富：

class Power {
    /**
     * 能力值
     */
    protected $ability;

    /**
     * 能力范围或距离
     */
    protected $range;

    public function __construct($ability, $range)
    {
        $this->ability = $ability;
        $this->range = $range;
    }
}

这时候我们回过头，修改一下之前的“超人”类，让一个“超人”创建的时候被赋予一个超能力：

class Superman
{
    protected $power;

    public function __construct()
    {
        $this->power = new Power(999, 100);
    }
}

这样的话，当我们创建一个“超人”实例的时候，同时也创建了一个“超能力”的实例，但是，我们看到了一点，“超人”和“超能力”之间不可避免的产生了一个依赖。

所谓“依赖”，就是“我若依赖你，少了你就没有我”。

在一个贯彻面向对象编程的项目中，这样的依赖随处可见。少量的依赖并不会有太过直观的影响，我们随着这个例子逐渐铺开，让大家慢慢意识到，当依赖达到一个量级时，是怎样一番噩梦般的体验。当然，我也会自然而然的讲述如何解决问题。

之前的例子中，超能力类实例化后是一个具体的超能力，但是我们知道，超人的超能力是多元化的，每种超能力的方法、属性都有不小的差异，没法通过一种类描述完全。我们现在进行修改，我们假设超人可以有以下多种超能力：
飞行，属性有：飞行速度、持续飞行时间
蛮力，属性有：力量值
能量弹，属性有：伤害值、射击距离、同时射击个数
我们创建了如下类：

class Flight
{
    protected $speed;
    protected $holdtime;
    public function __construct($speed, $holdtime) {}
}

class Force
{
    protected $force;
    public function __construct($force) {}
}

class Shot
{
    protected $atk;
    protected $range;
    protected $limit;
    public function __construct($atk, $range, $limit) {}
}

好了，这下我们的超人有点“忙”了。在超人初始化的时候，我们会根据需要来实例化其拥有的超能力吗，大致如下：

class Superman
{
    protected $power;

    public function __construct()
    {
        $this->power = new Fight(9, 100);
        // $this->power = new Force(45);
        // $this->power = new Shot(99, 50, 2);
        /*
        $this->power = array(
            new Force(45),
            new Shot(99, 50, 2)
        );
        */
    }
}

我们需要自己手动的在构造函数内（或者其他方法里）实例化一系列需要的类，这样并不好。可以想象，假如需求变更（不同的怪物横行地球），需要更多的有针对性的 新的 超能力，或者需要 变更 超能力的方法，我们必须 重新改造 超人。换句话说就是，改变超能力的同时，我还得重新制造个超人。效率太低了！新超人还没创造完成世界早已被毁灭。

这时，灵机一动的人想到：为什么不可以这样呢？超人的能力可以被随时更换，只需要添加或者更新一个芯片或者其他装置啥的（想到钢铁侠没）。这样的话就不要整个重新来过了。

IoC 容器诞生的故事——青铜时代（工厂模式）

我们不应该手动在 “超人” 类中固化了他的 “超能力” 初始化的行为，而转由外部负责，由外部创造超能力模组、装置或者芯片等（我们后面统一称为 “模组”），植入超人体内的某一个接口，这个接口是一个既定的，只要这个 “模组” 满足这个接口的装置都可以被超人所利用，可以提升、增加超人的某一种能力。这种由外部负责其依赖需求的行为，我们可以称其为 “控制反转（IoC）”。

工厂模式，顾名思义，就是一个类所以依赖的外部事物的实例，都可以被一个或多个 “工厂” 创建的这样一种开发模式，就是 “工厂模式”。

我们为了给超人制造超能力模组，我们创建了一个工厂，它可以制造各种各样的模组，且仅需要通过一个方法：

class SuperModuleFactory
{
    public function makeModule($moduleName, $options)
    {
        switch ($moduleName) {
            case 'Fight':     return new Fight($options[0], $options[1]);
            case 'Force':     return new Force($options[0]);
            case 'Shot':     return new Shot($options[0], $options[1], $options[2]);
        }
    }
}

这时候，超人 创建之初就可以使用这个工厂！

class Superman
{
    protected $power;

    public function __construct()
    {
        // 初始化工厂
        $factory = new SuperModuleFactory;

        // 通过工厂提供的方法制造需要的模块
        $this->power = $factory->makeModule('Fight', [9, 100]);
        // $this->power = $factory->makeModule('Force', [45]);
        // $this->power = $factory->makeModule('Shot', [99, 50, 2]);
        /*
        $this->power = array(
            $factory->makeModule('Force', [45]),
            $factory->makeModule('Shot', [99, 50, 2])
        );
        */
    }
}

可以看得出，我们不再需要在超人初始化之初，去初始化许多第三方类，只需初始化一个工厂类，即可满足需求。但这样似乎和以前区别不大，只是没有那么多 new 关键字。其实我们稍微改造一下这个类，你就明白，工厂类的真正意义和价值了。

class Superman
{
    protected $power;

    public function __construct(array $modules)
    {
        // 初始化工厂
        $factory = new SuperModuleFactory;

        // 通过工厂提供的方法制造需要的模块
        foreach ($modules as $moduleName => $moduleOptions) {
            $this->power[] = $factory->makeModule($moduleName, $moduleOptions);
        }
    }
}

// 创建超人
$superman = new Superman([
    'Fight' => [9, 100], 
    'Shot' => [99, 50, 2]
    ]);

现在修改的结果令人满意。现在，“超人” 的创建不再依赖任何一个 “超能力” 的类，我们如若修改了或者增加了新的超能力，只需要针对修改 SuperModuleFactory 即可。扩充超能力的同时不再需要重新编辑超人的类文件，使得我们变得很轻松。但是，这才刚刚开始。

IoC 容器诞生的故事——铁器时代（依赖注入）

由 “超人” 对 “超能力” 的依赖变成 “超人” 对 “超能力模组工厂” 的依赖后，对付小怪兽们变得更加得心应手。但这也正如你所看到的，依赖并未解除，只是由原来对多个外部的依赖变成了对一个 “工厂” 的依赖。假如工厂出了点麻烦，问题变得就很棘手。

其实大多数情况下，工厂模式已经足够了。工厂模式的缺点就是：接口未知（即没有一个很好的契约模型，关于这个我马上会有解释）、产生对象类型单一。总之就是，还是不够灵活。虽然如此，工厂模式依旧十分优秀，并且适用于绝大多数情况。不过我们为了讲解后面的 依赖注入 ，这里就先夸大一下工厂模式的缺陷咯。

我们知道，超人依赖的模组，我们要求有统一的接口，这样才能和超人身上的注入接口对接，最终起到提升超能力的效果。事实上，我之前说谎了，不仅仅只有一堆小怪兽，还有更多的大怪兽。嘿嘿。额，这时候似乎工厂的生产能力显得有些不足 —— 由于工厂模式下，所有的模组都已经在工厂类中安排好了，如果有新的、高级的模组加入，我们必须修改工厂类（好比增加新的生产线）：

class SuperModuleFactory
{
    public function makeModule($moduleName, $options)
    {
        switch ($moduleName) {
            case 'Fight':     return new Fight($options[0], $options[1]);
            case 'Force':     return new Force($options[0]);
            case 'Shot':     return new Shot($options[0], $options[1], $options[2]);
            // case 'more': .......
            // case 'and more': .......
            // case 'and more': .......
            // case 'oh no! its too many!': .......
        }
    }
}

看到没。。。噩梦般的感受！

其实灵感就差一步！你可能会想到更为灵活的办法！对，下一步就是我们今天的主要配角 —— DI （依赖注入）

由于对超能力模组的需求不断增大，我们需要集合整个世界的高智商人才，一起解决问题，不应该仅仅只有几个工厂垄断负责。不过高智商人才们都非常自负，认为自己的想法是对的，创造出的超能力模组没有统一的接口，自然而然无法被正常使用。这时我们需要提出一种契约，这样无论是谁创造出的模组，都符合这样的接口，自然就可被正常使用。

interface SuperModuleInterface
{
    /**
     * 超能力激活方法
     *
     * 任何一个超能力都得有该方法，并拥有一个参数
     *@param array $target 针对目标，可以是一个或多个，自己或他人
     */
    public function activate(array $target);
}

上文中，我们定下了一个接口 （超能力模组的规范、契约），所有被创造的模组必须遵守该规范，才能被生产。
其实，这就是 php 中 接口（ interface ） 的用处和意义！很多人觉得，为什么 php 需要接口这种东西？难道不是 java 、 C# 之类的语言才有的吗？这么说，只要是一个正常的面向对象编程语言（虽然 php 可以面向过程），都应该具备这一特性。因为一个 对象（object） 本身是由他的模板或者原型 —— 类 （class） ，经过实例化后产生的一个具体事物，而有时候，实现统一种方法且不同功能（或特性）的时候，会存在很多的类（class），这时候就需要有一个契约，让大家编写出可以被随时替换却不会产生影响的接口。这种由编程语言本身提出的硬性规范，会增加更多优秀的特性。

这时候，那些提出更好的超能力模组的高智商人才，遵循这个接口，创建了下述（模组）类：

/**
 * X-超能量
 */
class XPower implements SuperModuleInterface
{
    public function activate(array $target)
    {
        // 这只是个例子。。具体自行脑补
    }
}

/**
 * 终极炸弹 （就这么俗）
 */
class UltraBomb implements SuperModuleInterface
{
    public function activate(array $target)
    {
        // 这只是个例子。。具体自行脑补
    }
}

同时，为了防止有些 “砖家” 自作聪明，或者一些叛徒恶意捣蛋，不遵守契约胡乱制造模组，影响超人，我们对超人初始化的方法进行改造：

class Superman
{
    protected $module;

    public function __construct(SuperModuleInterface $module)
    {
        $this->module = $module
    }
}

改造完毕！现在，当我们初始化 “超人” 类的时候，提供的模组实例必须是一个 SuperModuleInterface 接口的实现。否则就会提示错误。

正是由于超人的创造变得容易，一个超人也就不需要太多的超能力，我们可以创造多个超人，并分别注入需要的超能力模组即可。这样的话，虽然一个超人只有一个超能力，但超人更容易变多，我们也不怕怪兽啦！

现在有人疑惑了，你要讲的 依赖注入 呢？
其实，上面讲的内容，正是依赖注入。

什么叫做 依赖注入?
本文从开头到现在提到的一系列依赖，只要不是由内部生产（比如初始化、构造函数 __construct 中通过工厂方法、自行手动 new 的），而是由外部以参数或其他形式注入的，都属于 依赖注入（DI） 。是不是豁然开朗？事实上，就是这么简单。下面就是一个典型的依赖注入：

// 超能力模组
$superModule = new XPower;

// 初始化一个超人，并注入一个超能力模组依赖
$superMan = new Superman($superModule);

关于依赖注入这个本文的主要配角，也就这么多需要讲的。理解了依赖注入，我们就可以继续深入问题。慢慢走近今天的主角……

IoC 容器诞生的故事——科技时代（IoC容器）

刚刚列了一段代码：

$superModule = new XPower;

$superMan = new Superman($superModule);

读者应该看出来了，手动的创建了一个超能力模组、手动的创建超人并注入了刚刚创建超能力模组。呵呵，手动。

现代社会，应该是高效率的生产，干净的车间，完美的自动化装配。

一群怪兽来了，如此低效率产出超人是不现实，我们需要自动化 —— 最多一条指令，千军万马来相见。我们需要一种高级的生产车间，我们只需要向生产车间提交一个脚本，工厂便能够通过指令自动化生产。这种更为高级的工厂，就是工厂模式的升华 —— IoC 容器。

class Container
{
    protected $binds;

    protected $instances;

    public function bind($abstract, $concrete)
    {
        if ($concrete instanceof Closure) {
            $this->binds[$abstract] = $concrete;
        } else {
            $this->instances[$abstract] = $concrete;
        }
    }

    public function make($abstract, $parameters = [])
    {
        if (isset($this->instances[$abstract])) {
            return $this->instances[$abstract];
        }

        array_unshift($parameters, $this);

        return call_user_func_array($this->binds[$abstract], $parameters);
    }
}

这时候，一个十分粗糙的容器就诞生了。现在的确很简陋，但不妨碍我们进一步提升他。先着眼现在，看看这个容器如何使用吧！

// 创建一个容器（后面称作超级工厂）
$container = new Container;

// 向该 超级工厂 添加 超人 的生产脚本
$container->bind('superman', function($container, $moduleName) {
    return new Superman($container->make($moduleName));
});

// 向该 超级工厂 添加 超能力模组 的生产脚本
$container->bind('xpower', function($container) {
    return new XPower;
});

// 同上
$container->bind('ultrabomb', function($container) {
    return new UltraBomb;
});

// ******************  华丽丽的分割线  **********************
// 开始启动生产
$superman_1 = $container->make('superman', 'xpower');
$superman_2 = $container->make('superman', 'ultrabomb');
$superman_3 = $container->make('superman', 'xpower');
// ...随意添加

看到没？通过最初的 绑定（bind） 操作，我们向 超级工厂 注册了一些生产脚本，这些生产脚本在生产指令下达之时便会执行。发现没有？我们彻底的解除了 超人 与 超能力模组 的依赖关系，更重要的是，容器类也丝毫没有和他们产生任何依赖！我们通过注册、绑定的方式向容器中添加一段可以被执行的回调（可以是匿名函数、非匿名函数、类的方法）作为生产一个类的实例的 脚本 ，只有在真正的 生产（make） 操作被调用执行时，才会触发。

这样一种方式，使得我们更容易在创建一个实例的同时解决其依赖关系，并且更加灵活。当有新的需求，只需另外绑定一个“生产脚本”即可。

实际上，真正的 IoC 容器更为高级。我们现在的例子中，还是需要手动提供超人所需要的模组参数，但真正的 IoC 容器会根据类的依赖需求，自动在注册、绑定的一堆实例中搜寻符合的依赖需求，并自动注入到构

现在，到目前为止，我们已经不再惧怕怪兽们了。高智商人才集思广益，井井有条，根据接口契约创造规范的超能力模组。超人开始批量产出。最终，人人都是超人，你也可以是哦 :stuck_out_tongue_closed_eyes:！

laravel初始化一个服务容器的大概过程

对于laravel初始化服务容器的过程，还是以代码加注释的方式来大致的解释一下，初始化过程都做了什么工作
/public/index.php文件里面有一行初始化服务器容器的代码，调度的相关文件就是：/bootstrap/app.php

代码清单/bootstrap/app.php

<?php
//真正的初始化服务容器代码，下面有此行的继续追踪
$app = new Illuminate\Foundation\Application(
    realpath(__DIR__.'/../')
);
//单例一个App\Http\Kernel对象，可以使用App::make('Illuminate\Contracts\Http\Kernel')调用
$app->singleton(
    'Illuminate\Contracts\Http\Kernel',
    'App\Http\Kernel'
);
//单例一个App\Console\Kernel对象，可以使用App::make('Illuminate\Contracts\Console\Kernel')调用
$app->singleton(
    'Illuminate\Contracts\Console\Kernel',
    'App\Console\Kernel'
);
//打字好累，同上，不解释
$app->singleton(
    'Illuminate\Contracts\Debug\ExceptionHandler',
    'App\Exceptions\Handler'
);
//返回一个初始化完成的服务容器
return $app;

代码清单Illuminate\Foundation\Application

//代码太多，只能解释几个主要的方法（真实情况是，我了解也不多，也就看了这几个方法*^_^*）
public function __construct($basePath = null)
    {
        //初始化最简单的容器
        $this->registerBaseBindings();
        //在容器中注册最基本的服务提供者（即ServiceProvider）
        $this->registerBaseServiceProviders();
        //在容器中注册一些核心类的别名（这个说法貌似有点不妥，可以参见以下的代码注释自己再理解一下）
        $this->registerCoreContainerAliases();
        //在容器中注册一些常用的文档绝对路径
        if ($basePath) $this->setBasePath($basePath);
    }

    protected function registerBaseBindings()
    {
        //初始化一个空的容器
        static::setInstance($this);
        //在容器中，实例化一个key为app的实例，相对的值就是当前容器，你可以使用App::make('app')来取得一个容器对象
        $this->instance('app', $this);
        //同上
        $this->instance('Illuminate\Container\Container', $this);
    }

    protected function registerBaseServiceProviders()
    {
        //EventServiceProvider这个服务提供者，其实是向容器注册了一个key为events的对象，可以在你的IDE里面追踪一下代码
        $this->register(new EventServiceProvider($this));
        //注册4个key分别为router、url、redirect、Illuminate\Contracts\Routing\ResponseFactory的对象
        $this->register(new RoutingServiceProvider($this));
    }

    /*这个方法的作用，就以一个例子来解释吧（语文不太好~\(≧▽≦)/~）
        在调用此方法之前，我们想取得一个容器实例的做法是 App::make('app');
        现在我们可以使用App::make('Illuminate\Foundation\Application')
        App::make('Illuminate\Contracts\Container\Container')
        App::make('Illuminate\Contracts\Foundation\Application')
        三种方法来取得一个容器实例，即Illuminate\Foundation\Application、Illuminate\Contracts\Container\Container、Illuminate\Contracts\Foundation\Application三者都是app的别名；
    */
    public function registerCoreContainerAliases()
    {
        $aliases = array(
            'app'                  => ['Illuminate\Foundation\Application', 'Illuminate\Contracts\Container\Container', 'Illuminate\Contracts\Foundation\Application'],
            'artisan'              => ['Illuminate\Console\Application', 'Illuminate\Contracts\Console\Application'],
            'auth'                 => 'Illuminate\Auth\AuthManager',
            'auth.driver'          => ['Illuminate\Auth\Guard', 'Illuminate\Contracts\Auth\Guard'],
            'auth.password.tokens' => 'Illuminate\Auth\Passwords\TokenRepositoryInterface',
            'blade.compiler'       => 'Illuminate\View\Compilers\BladeCompiler',
            'cache'                => ['Illuminate\Cache\CacheManager', 'Illuminate\Contracts\Cache\Factory'],
            'cache.store'          => ['Illuminate\Cache\Repository', 'Illuminate\Contracts\Cache\Repository'],
            'config'               => ['Illuminate\Config\Repository', 'Illuminate\Contracts\Config\Repository'],
            'cookie'               => ['Illuminate\Cookie\CookieJar', 'Illuminate\Contracts\Cookie\Factory', 'Illuminate\Contracts\Cookie\QueueingFactory'],
            'encrypter'            => ['Illuminate\Encryption\Encrypter', 'Illuminate\Contracts\Encryption\Encrypter'],
            'db'                   => 'Illuminate\Database\DatabaseManager',
            'events'               => ['Illuminate\Events\Dispatcher', 'Illuminate\Contracts\Events\Dispatcher'],
            'files'                => 'Illuminate\Filesystem\Filesystem',
            'filesystem'           => 'Illuminate\Contracts\Filesystem\Factory',
            'filesystem.disk'      => 'Illuminate\Contracts\Filesystem\Filesystem',
            'filesystem.cloud'     => 'Illuminate\Contracts\Filesystem\Cloud',
            'hash'                 => 'Illuminate\Contracts\Hashing\Hasher',
            'translator'           => ['Illuminate\Translation\Translator', 'Symfony\Component\Translation\TranslatorInterface'],
            'log'                  => ['Illuminate\Log\Writer', 'Illuminate\Contracts\Logging\Log', 'Psr\Log\LoggerInterface'],
            'mailer'               => ['Illuminate\Mail\Mailer', 'Illuminate\Contracts\Mail\Mailer', 'Illuminate\Contracts\Mail\MailQueue'],
            'paginator'            => 'Illuminate\Pagination\Factory',
            'auth.password'        => ['Illuminate\Auth\Passwords\PasswordBroker', 'Illuminate\Contracts\Auth\PasswordBroker'],
            'queue'                => ['Illuminate\Queue\QueueManager', 'Illuminate\Contracts\Queue\Factory', 'Illuminate\Contracts\Queue\Monitor'],
            'queue.connection'     => 'Illuminate\Contracts\Queue\Queue',
            'redirect'             => 'Illuminate\Routing\Redirector',
            'redis'                => ['Illuminate\Redis\Database', 'Illuminate\Contracts\Redis\Database'],
            'request'              => 'Illuminate\Http\Request',
            'router'               => ['Illuminate\Routing\Router', 'Illuminate\Contracts\Routing\Registrar'],
            'session'              => 'Illuminate\Session\SessionManager',
            'session.store'        => ['Illuminate\Session\Store', 'Symfony\Component\HttpFoundation\Session\SessionInterface'],
            'url'                  => ['Illuminate\Routing\UrlGenerator', 'Illuminate\Contracts\Routing\UrlGenerator'],
            'validator'            => ['Illuminate\Validation\Factory', 'Illuminate\Contracts\Validation\Factory'],
            'view'                 => ['Illuminate\View\Factory', 'Illuminate\Contracts\View\Factory'],
        );

        foreach ($aliases as $key => $aliases)
        {
            foreach ((array) $aliases as $alias)
            {
                $this->alias($key, $alias);
            }
        }
    }

由此得到的一个容器实例

Application {#2 ▼
  #basePath: "/Applications/XAMPP/xamppfiles/htdocs/laravel"
  #hasBeenBootstrapped: false
  #booted: false
  #bootingCallbacks: []
  #bootedCallbacks: []
  #terminatingCallbacks: []
  #serviceProviders: array:2 [▶]
  #loadedProviders: array:2 [▶]
  #deferredServices: []
  #storagePath: null
  #environmentFile: ".env"
  #resolved: array:1 [▶]
  #bindings: array:8 [▼
    "events" => array:2 [▶]
    "router" => array:2 [▶]
    "url" => array:2 [▶]
    "redirect" => array:2 [▶]
    "Illuminate\Contracts\Routing\ResponseFactory" => array:2 [▶]
    "Illuminate\Contracts\Http\Kernel" => array:2 [▶]
    "Illuminate\Contracts\Console\Kernel" => array:2 [▶]
    "Illuminate\Contracts\Debug\ExceptionHandler" => array:2 [▶]
  ]
  #instances: array:10 [▼
    "app" => Application {#2}
    "Illuminate\Container\Container" => Application {#2}
    "events" => Dispatcher {#5 ▶}
    "path" => "/Applications/XAMPP/xamppfiles/htdocs/laravel/app"
    "path.base" => "/Applications/XAMPP/xamppfiles/htdocs/laravel"
    "path.config" => "/Applications/XAMPP/xamppfiles/htdocs/laravel/config"
    "path.database" => "/Applications/XAMPP/xamppfiles/htdocs/laravel/database"
    "path.lang" => "/Applications/XAMPP/xamppfiles/htdocs/laravel/resources/lang"
    "path.public" => "/Applications/XAMPP/xamppfiles/htdocs/laravel/public"
    "path.storage" => "/Applications/XAMPP/xamppfiles/htdocs/laravel/storage"
  ]
  #aliases: array:59 [▼
    "Illuminate\Foundation\Application" => "app"
    "Illuminate\Contracts\Container\Container" => "app"
    "Illuminate\Contracts\Foundation\Application" => "app"
    "Illuminate\Console\Application" => "artisan"
    "Illuminate\Contracts\Console\Application" => "artisan"
    "Illuminate\Auth\AuthManager" => "auth"
    "Illuminate\Auth\Guard" => "auth.driver"
    "Illuminate\Contracts\Auth\Guard" => "auth.driver"
    "Illuminate\Auth\Passwords\TokenRepositoryInterface" => "auth.password.tokens"
    "Illuminate\View\Compilers\BladeCompiler" => "blade.compiler"
    "Illuminate\Cache\CacheManager" => "cache"
    "Illuminate\Contracts\Cache\Factory" => "cache"
    "Illuminate\Cache\Repository" => "cache.store"
    "Illuminate\Contracts\Cache\Repository" => "cache.store"
    "Illuminate\Config\Repository" => "config"
    "Illuminate\Contracts\Config\Repository" => "config"
    "Illuminate\Cookie\CookieJar" => "cookie"
    "Illuminate\Contracts\Cookie\Factory" => "cookie"
    "Illuminate\Contracts\Cookie\QueueingFactory" => "cookie"
    "Illuminate\Encryption\Encrypter" => "encrypter"
    "Illuminate\Contracts\Encryption\Encrypter" => "encrypter"
    "Illuminate\Database\DatabaseManager" => "db"
    "Illuminate\Events\Dispatcher" => "events"
    "Illuminate\Contracts\Events\Dispatcher" => "events"
    "Illuminate\Filesystem\Filesystem" => "files"
    "Illuminate\Contracts\Filesystem\Factory" => "filesystem"
    "Illuminate\Contracts\Filesystem\Filesystem" => "filesystem.disk"
    "Illuminate\Contracts\Filesystem\Cloud" => "filesystem.cloud"
    "Illuminate\Contracts\Hashing\Hasher" => "hash"
    "Illuminate\Translation\Translator" => "translator"
    "Symfony\Component\Translation\TranslatorInterface" => "translator"
    "Illuminate\Log\Writer" => "log"
    "Illuminate\Contracts\Logging\Log" => "log"
    "Psr\Log\LoggerInterface" => "log"
    "Illuminate\Mail\Mailer" => "mailer"
    "Illuminate\Contracts\Mail\Mailer" => "mailer"
    "Illuminate\Contracts\Mail\MailQueue" => "mailer"
    "Illuminate\Pagination\Factory" => "paginator"
    "Illuminate\Auth\Passwords\PasswordBroker" => "auth.password"
    "Illuminate\Contracts\Auth\PasswordBroker" => "auth.password"
    "Illuminate\Queue\QueueManager" => "queue"
    "Illuminate\Contracts\Queue\Factory" => "queue"
    "Illuminate\Contracts\Queue\Monitor" => "queue"
    "Illuminate\Contracts\Queue\Queue" => "queue.connection"
    "Illuminate\Routing\Redirector" => "redirect"
    "Illuminate\Redis\Database" => "redis"
    "Illuminate\Contracts\Redis\Database" => "redis"
    "Illuminate\Http\Request" => "request"
    "Illuminate\Routing\Router" => "router"
    "Illuminate\Contracts\Routing\Registrar" => "router"
    "Illuminate\Session\SessionManager" => "session"
    "Illuminate\Session\Store" => "session.store"
    "Symfony\Component\HttpFoundation\Session\SessionInterface" => "session.store"
    "Illuminate\Routing\UrlGenerator" => "url"
    "Illuminate\Contracts\Routing\UrlGenerator" => "url"
    "Illuminate\Validation\Factory" => "validator"
    "Illuminate\Contracts\Validation\Factory" => "validator"
    "Illuminate\View\Factory" => "view"
    "Illuminate\Contracts\View\Factory" => "view"
  ]
  #extenders: []
  #tags: []
  #buildStack: []
  +contextual: []
  #reboundCallbacks: []
  #globalResolvingCallbacks: []
  #globalAfterResolvingCallbacks: []
  #resolvingCallbacks: []
  #afterResolvingCallbacks: []
}

怎么打印一个实例？？
到这一步为止，你可以这样做dd(app())

dd(app())什么意思？？
这里包含两个方法dd()和app(),具体定义请看自动加载的第四种方法

那说好的App::make(‘app’)方法咋不能用呢？
这是因为这个方法需要用到Contracts，而到此为止，还未定义App作为Illuminate\Support\Facades\App的别名，因而不能用；需要等到统一入口文件里面的运行Kernel类的handle方法才能用，所以在Controller里面是可以用的，现在不能用

到此为止，一个容器实例就诞生了，事情就是这么个事情，情况就是这个个情况，再具体的那就需要你自己去看代码了，我知道的就这些

启动Kernel代码

Kernel实例调用handle方法，意味着laravel的核心和公用代码已经准备完毕，此项目正式开始运行

代码清单/app/Http/Kernel.php

<?php namespace App\Http;

use Illuminate\Foundation\Http\Kernel as HttpKernel;

class Kernel extends HttpKernel {

    //这是在调用路由之前需要启动的中间件,一般都是核心文件，不要修改
    protected $middleware = [
        'Illuminate\Foundation\Http\Middleware\CheckForMaintenanceMode',
        'Illuminate\Cookie\Middleware\EncryptCookies',
        'Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse',
        'Illuminate\Session\Middleware\StartSession',
        'Illuminate\View\Middleware\ShareErrorsFromSession',
        'App\Http\Middleware\VerifyCsrfToken',
    ];

    //这是我们在router.php文件里面或者Controller文件里面，可以使用的Middleware元素，可以自定义加入很多
    protected $routeMiddleware = [
        'auth' => 'App\Http\Middleware\Authenticate',
        'auth.basic' => 'Illuminate\Auth\Middleware\AuthenticateWithBasicAuth',
        'guest' => 'App\Http\Middleware\RedirectIfAuthenticated',
        'test' => 'App\Http\Middleware\testMiddleWare',
    ];

}

大家看到了，其实这个文件里面没有handle方法，只有一些属性定义，所以真正的handle方法，实在父类里面实现的

代码清单…/Illuminate/Foundation/Http/Kernel.php

//好多代码，见几个我看过的扯扯，其他的期待你们补上

//这个很重要，是项目的一些启动引导项，Kernel的重要步骤中，首先就是启动这些文件的bootstrap方法
protected $bootstrappers = [
        //检测环境变量文件是否正常
        'Illuminate\Foundation\Bootstrap\DetectEnvironment',
        //取得配置文件，即把/config/下的所有配置文件读取到容器（app()->make('config')可以查看所有配置信息）
        'Illuminate\Foundation\Bootstrap\LoadConfiguration',
        //绑定一个名字为log的实例到容器，怎么访问？？（app()->make('log')）
        'Illuminate\Foundation\Bootstrap\ConfigureLogging',
        //设置异常抓取信息，这个还没仔细看，但大概就是这个意思
        'Illuminate\Foundation\Bootstrap\HandleExceptions',
        //把/config/app.php里面的aliases项利用PHP库函数class_alias创建别名，从此，我们可以使用App::make('app')方式取得实例
        'Illuminate\Foundation\Bootstrap\RegisterFacades',
        //把/config/app.php里面的providers项,注册到容器
        'Illuminate\Foundation\Bootstrap\RegisterProviders',
        //运行容器中注册的所有的ServiceProvider中得boot方法
        'Illuminate\Foundation\Bootstrap\BootProviders',
    ];

  //真正的handle方法
  public function handle($request)
    {
        try
        {
            //主要是这行，调度了需要运行的方法
            return $this->sendRequestThroughRouter($request);
        }
        catch (Exception $e)
        {
            $this->reportException($e);

            return $this->renderException($request, $e);
        }
    }


    protected function sendRequestThroughRouter($request)
    {
        $this->app->instance('request', $request);
        Facade::clearResolvedInstance('request');
        //运行上述$bootstrappers里面包含的文件的bootstrap方法，运行的作用，上面已经注释
        $this->bootstrap();
        //这是在对URL进行调度之前，也就是运行Route之前，进行的一些准备工作
        return (new Pipeline($this->app))    //不解释
                    ->send($request)        //继续不解释
                    //需要运行$this->middleware里包含的中间件
                    ->through($this->middleware)
                    //运行完上述中间件之后，调度dispatchToRouter方法，进行Route的操作
                    ->then($this->dispatchToRouter());
    }

    //前奏执行完毕之后，进行Route操作
    protected function dispatchToRouter()
    {
        return function($request)
        {
            $this->app->instance('request', $request);
            //跳转到Router类的dispatch方法
            return $this->router->dispatch($request);
        };
    }

下面就需要根据URL和/app/Http/routes.php文件，进行Route操作

文件清单…/Illuminate/Routing/Router.php

//代码好多，挑几个解释

    public function dispatch(Request $request)
    {
        $this->currentRequest = $request;
        //在4.2版本里面，Route有一个筛选属性；5.0之后的版本，被Middleware代替
        $response = $this->callFilter('before', $request);

        if (is_null($response))
        {    
            //继续调度
            $response = $this->dispatchToRoute($request);
        }

        $response = $this->prepareResponse($request, $response);
        //在4.2版本里面，Route有一个筛选属性；5.0之后的版本，被Middleware代替
        $this->callFilter('after', $request, $response);

        return $response;
    }

    public function dispatchToRoute(Request $request)
    {
        $route = $this->findRoute($request);
        $request->setRouteResolver(function() use ($route)
        {
            return $route;
        });

        $this->events->fire('router.matched', [$route, $request]);
        $response = $this->callRouteBefore($route, $request);

        if (is_null($response))
        {
            // 只看这一行，还是调度文件
            $response = $this->runRouteWithinStack(
                $route, $request
            );
        }

        $response = $this->prepareResponse($request, $response);
        $this->callRouteAfter($route, $request, $response);

        return $response;
    }

    //干货来了
    protected function runRouteWithinStack(Route $route, Request $request)
    {
        // 取得routes.php里面的Middleware节点
        $middleware = $this->gatherRouteMiddlewares($route);
        //这个有点眼熟
        return (new Pipeline($this->container))
                        ->send($request)
                        //执行上述的中间件
                        ->through($middleware)
                        ->then(function($request) use ($route)
                        {    
                            //不容易啊，终于到Controller类了
                            return $this->prepareResponse(
                                $request,
                                //run控制器
                                $route->run($request)
                            );
                        });
    }

    public function run(Request $request)
    {
        $this->container = $this->container ?: new Container;
        try
        {
            if ( ! is_string($this->action['uses']))
                return $this->runCallable($request);
            if ($this->customDispatcherIsBound())
            //实际上是运行了这行
                return $this->runWithCustomDispatcher($request);

            //其实我是直接想运行这行
            return $this->runController($request);
        }
        catch (HttpResponseException $e)
        {
            return $e->getResponse();
        }
    }

    //继续调度，最终调度到.../Illuminate/Routing/ControllerDispatcher.php文件的dispatch方法
    protected function runWithCustomDispatcher(Request $request)
    {
        list($class, $method) = explode('@', $this->action['uses']);

        $dispatcher = $this->container->make('illuminate.route.dispatcher');
        return $dispatcher->dispatch($this, $request, $class, $method);
    }

文件清单…/Illuminate/Routing/ControllerDispatcher.php

    public function dispatch(Route $route, Request $request, $controller, $method)
    {
        $instance = $this->makeController($controller);

        $this->assignAfter($instance, $route, $request, $method);

        $response = $this->before($instance, $route, $request, $method);

        if (is_null($response))
        {
            //还要调度
            $response = $this->callWithinStack(
                $instance, $route, $request, $method
            );
        }

        return $response;
    }

    protected function callWithinStack($instance, $route, $request, $method)
    {
        //又是Middleware......有没有忘记，官方文档里面Middleware可以加在控制器的构造函数中！！没错，这个Middleware就是在控制器里面申明的
        $middleware = $this->getMiddleware($instance, $method);
        //又是这个，眼熟吧
        return (new Pipeline($this->container))
                    ->send($request)
                    //再次运行Middleware
                    ->through($middleware)
                    ->then(function($request) use ($instance, $route, $method)
                    {    
                        运行控制器，返回结果
                        return $this->call($instance, $route, $method);
                    });
    }

这就是从入口文件到控制器中间，进行的一系列操作，心塞塞的，终于到我们干活的地方了