在 Laravel 项目中，由于测试，有时候用 php artisan make:migration create_xxx_table 创建数据库迁移。如果把创建的迁移文件 database/migrations/2016_09_13_081736_create_xxx_table.php 文件给删除了，再次执行 php artisan make:migration create_xxx_table 会报错：

[ErrorException]
include(/data/wwwroot/tj.com/vendor/composer/../../database/migrations/2016_09_13_081736_create_xxx_table.php): failed to open stream: No such file or directory
重新运行 composer update 又可以执行上面的命令了。
 
经过对比发现，在执行 artisan 命令后，会在 vendor/composer/autoload_classmap.php 和 vendor/composer/autoload_static.php 这两个文件里加上新生成的类和文件的映射，因为有了这个映射， artisan 命令就没有再生成新的文件。
 
所以删除上面两个文件里的有 create_xxx_table 的行就可以解决这个问题。
 
或者再用 artisan 创建一个新的数据库迁移，这时会更新 composer 类和文件的映射。原来那个映射没有了，这时再创建先前那个 migration 也不会报错了。
                    在 Laravel 项目中，由于测试，有时候用 php artisan make:migration create_xxx_table 创建数据库迁移。如果把创建的迁移文件 database/migrations/2016_09_13_081736_create_xxx_table.php 文件给删除了，再次执行 php artisan make:migration create_xxx_table
				
laravel会在你的数据库里面生成一个migrations 表，这个表记录了你的migrate操作，当我们进行一些操作，比如手动删除表的时候，migrations表里面的记录没有删除，手动删除，重新执行php artisan migrate 命令就可以了
				
ErrorException include(F:\wamp\www\blog\vendor\composer/…/…/app/Models/Reply.php): Failed to open stream: No such file or directory
执行：composer dump-autoload
在多人开发的项目中，我们都习惯了使用SVN或者Git来对代码做版本控制，主要的目的就是为了解决多人开发代码冲突和版本回退的问题。
其实，数据库的变更也需要版本控制，在日常开发中，我们经常会遇到下面的问题：
自己写的SQL忘了在所有环境执行；
	别人写的SQL我们不能确定是否都在所有环境执行过了；
	有人修改了已经执行过的SQL，期望再次执行；