究其根本原因，是因为老数据中，有部分文章过长导致。

下面详细说明两个需要更改的地方。希望官方也能重视并给出更好的解决方案。

1、aws_articl.search_text的字段类型

由于新版4.0系统的文章表aws_article，多了一个search_text字段，备注是“搜索文本”该字段在初始化的时候，被设定为 text  类型，最长只能65535个字节。

而真正存储文章的message字段，用了longtext类型，最长可以4G字节。

问题就在于， 老版本数据转换 插件，只是将老数据库中的message数据，用“strip_tags”函数，去掉了html代码，就直接存入。

一旦遇到message字段实际数据大于65535个字节的情况，就会报错。因为数据太长了，可以插入longtext类型的message字段，却无法插入 text  类型的search_text字段。

解决方法：

在启动转换程序转换之前，手动把aws_articl.search_text的字段类型，由text改longtext。

具体操作：

在navicat中，点鼠标就可以完成。

2、导入文章时分页数阀值

因为php脚本也是需要执行时间的，官方插件为了避免脚本执行过长被服务器或浏览器暂停，就采用了分页执行的方式。

但部分超长的文章，会严重拉长转换的时长，导致脚本执行被服务器强制中止。这时候就不会有任何报错信息。

解决方法：

把文章的分页量减少，从500改为10。即一次只转换10篇文章，分段转换。这样脚本就不会超时被杀了。

具体操作：

plugins\old2new\controller\Index.php 的第701行

//导入文章
    private function import_article($page)
    {
        $articles = $this->dbObj->name('article')->page($page,500)->order('id','ASC')->select()->toArray();

把500改为10：

//导入文章
    private function import_article($page)
    {
        $articles = $this->dbObj->name('article')->page($page,10)->order('id','ASC')->select()->toArray();