做UEditor二次开发的基本都撞上过这个邪门问题批量选了一堆图片上传服务器那边也显示全部上传成功回到编辑器一看图片顺序七零八落甚至有时候只插进来最后一张。更要命的是有些版本还会弹一句“上传成功服务器返回错误”明明图已经传到服务器了前端就是不往编辑器里插。这三个现象看着像三个bug其实根子都在同一个地方——UEditor的批量上传回调逻辑。今天这篇就是把这个问题彻底讲透包括乱序产生的原因、几种亲测有效的修复方案、怎么处理“上传成功但提示服务器返回错误”这个经典伴生问题以及实际排查时的顺序和技巧。适合正在维护老项目、或者还在用UEditor 1.4.x系列做后台管理的开发者参考。1. 乱序问题到底出在哪一环1.1 上传回调和插入回调是两个阶段先把流程捋清楚。UEditor的批量上传并不是一次性把图片全部插入编辑器而是分两个阶段第一阶段是上传。前端把选中的文件批量发给服务端服务端逐个处理最后返回一个JSON数组里面含有每张图片的URL、原始文件名等信息。第二阶段是插入。前端拿到这个返回的数组后遍历数组逐个把img标签插入编辑器内容区。我之前调试的时候第一反应是服务端返回顺序不对。后来用F12看了Network面板里的响应发现返回的JSON顺序和选择顺序完全一致问题出在第二阶段的插入逻辑。也就是说服务端没毛病是UEditor自身在插入环节把顺序搞乱了。1.2 光标漂移才是罪魁祸首UEditor插入图片用的是execCommand(insertHtml, html)这个命令的行为是把HTML插入到当前光标位置然后编辑器会把光标移动到刚插入内容的末尾方便你继续输入。这就出问题了。批量插入时UEditor是在一个循环里反复执行execCommand(insertHtml)// 类似这样的循环不同版本细节略有差异 for (var i 0; i list.length; i) { var item list[i]; if (item.src) { var html img src item.src alt (item.alt || ) /; editor.execCommand(insertHtml, html); } }第一张图片插入后光标跑到第一张图片的后面。第二张图片插入时正常应该插到第一张图片之后但UEditor在某些版本里每次执行insertHtml之前会重新聚焦或者重置选区结果光标回到了编辑器开头或者跳到了最后一张图片的位置。实际操作中我见过两种乱法一种是完全逆序最后选的那张跑到了最前面另一种是中间偶尔跳位看起来毫无规律。还有个隐蔽情况如果某张图片的item.src为空循环里的continue会导致这一次插入被跳过但光标位置已经被前一次插入改变后面图片的插入位置整体错位。这就是为什么有时候“只显示最后一张图”现象也会跟着出现。2. 第一个修复方案拼成一次插入2.1 找到批量插入的核心循环最直接、改动最小的修复方式就是把循环里逐个执行insertHtml改成把所有图片的HTML拼成一个字符串然后只执行一次insertHtml。这需要找到UEditor源码里批量图片上传完成后的那段回调代码。不同版本位置不太一样有的在ueditor.all.js里有的在dialogs/image/image.js里甚至有人改了名字。不用死记直接搜关键字insertHtmllist.lengthgetInfoList搜到之后把原来那种“循环里逐个执行insertHtml”的代码替换成下面的样子// 修复前逐个插入光标漂移导致乱序 for (var i 0; i list.length; i) { var item list[i]; if (!item.src) { continue; } var html img src item.src alt (item.alt || ) /; editor.execCommand(insertHtml, html); }// 修复后先拼成完整HTML一次性插入 var htmlArr []; for (var i 0; i list.length; i) { var item list[i]; if (!item.src) { continue; } htmlArr.push(img src item.src alt (item.alt || ) /); } if (htmlArr.length 0) { editor.execCommand(insertHtml, htmlArr.join()); }这样改完整个HTML是作为一个整体插入的编辑器只做一次光标移动顺序严格按照list数组的顺序不会再出现中间跳位。2.2 为什么这样能根治乱序这个方案之所以有效是因为它绕开了光标漂移问题。一次execCommand(insertHtml)执行时实际只有一次“确定插入位置”的动作后面所有图片都在同一个位置后面连续排列不存在二次定位。有人可能会问那如果list本身顺序不对拼接也没用。所以这个方案的前提是服务端返回的list顺序正确。默认情况下UEditor官方PHP版是按上传顺序返回的大部分乱序案例都是前端插入导致而不是服务端返回导致。另外要注意一个细节拼接的图片HTML里除了src之外最好把_src、alt、style这些属性也带上。有些二次开发版本里图片插入后还要做_src回填否则编辑器切到源码模式再切回来图片可能显示不出来。3. 更稳的生产级方案前端排序 服务端有序返回3.1 服务端给你的list补一个seq字段第一种方案虽然简单但有个隐患批量上传是并发的服务端处理完成返回的顺序在极端情况下可能和选择顺序不一致。我自己就遇到过服务器性能波动大时小图先传完、大图后传完返回的list顺序乱了前端再拼接也白搭。生产环境我更推荐双保险前端在插入前对list按seq字段主动排一次序。这个seq字段从哪来UEditor的前端上传组件在提交每个文件时其实会给每个文件分配一个序号但很多服务端代码在图省事的情况下不会把这个序号写进返回结果。所以要在服务端补上这一步。以常见的PHP版本为例在controller.php或自定义的批量上传接口里遍历上传文件时把序号带进去?php // 批量上传处理$files是收到的文件数组 $list []; foreach ($files as $index $file) { // 这里省略具体的move_uploaded_file等处理逻辑 $list[] [ seq $index, // 关键把序号写进返回结果 state SUCCESS, url $fullPath, original $file[name], source $file[name], ]; } // 返回前按seq升序排序确保前端拿到的顺序和选择顺序一致 usort($list, function ($a, $b) { return $a[seq] - $b[seq]; }); echo json_encode([ state SUCCESS, list $list ]);注意urldecode、转义等细节别漏尤其是文件名为中文的时候。返回的url一定要是可访问的绝对路径或正确的相对路径这一步没做对后面就会触发“服务器返回错误”。关于这个我会在第4节专门讲。3.2 前端在插入前先按seq排好序服务端返回了seq字段之后前端在上传完成回调里插入之前先排序// 上传完成回调里拿到json后先做排序 if (json.state SUCCESS) { var list json.list || []; list.sort(function (a, b) { return (a.seq || 0) - (b.seq || 0); }); // 排完序后再走插入逻辑可以和方案A结合拼接后一次插入 var htmlArr []; for (var i 0; i list.length; i) { var item list[i]; if (!item.src) { continue; } htmlArr.push(img src item.src alt (item.alt || ) /); } if (htmlArr.length 0) { editor.execCommand(insertHtml, htmlArr.join()); } }这套组合拳的好处是无论服务端返回什么顺序前端都能通过seq还原成正确的选择顺序而一次拼接插入又避免了光标漂移。两者互相补充是目前我试过最稳的方案基本能做到批量上传100张图片顺序分毫不差。3.3 这两个方案怎么选方案A简单改动小适合旧项目快速打补丁一行代码都不用加减只是把循环改一下。方案B稍微多几行但抗干扰能力强适合图片多、服务器并发上传压力大的场景。我个人习惯如果只是临时给客户修bug用方案A如果是自己项目里做长期维护建议直接上方案B。毕竟UEditor官方1.4.3.3之后基本就没大更新过后续所有问题都得自己兜底不如一开始就把排序逻辑做严谨。4. 顺手解决“上传成功服务器返回错误”4.1 这个错其实和乱序是孪生问题“提示上传成功服务器返回错误”这个现象我在排查乱序问题时几乎每次都碰到。它发生的场景通常是批量上传时第一张图插入成功后面的图怎么也插不进去界面弹一个“服务器返回错误”。但打开服务器目录图片确确实实传上去了。为什么会这样原因就是插入循环里某一张图片的src为空或者返回的JSON字段有问题导致插入逻辑走到了异常分支。这个异常分支会终止后续插入表现就是“只插进来一部分图”或者“只插进来最后一张图”。最经典的触发点在于服务端返回的JSON格式。UEditor要求的格式是{ state: SUCCESS, url: http://你的域名/upload/image/2024/01/123.jpg, original: 原名.jpg, title: , source: 原名.jpg }如果服务端犯懒返回了{status:success,path:xxx.jpg}或者url字段漏了前端连不到图就会直接报“服务器返回错误”。4.2 三步排查法碰到这个错别急着改代码按下面三步排查基本能定位第一步打开浏览器F12切到Network面板找到上传图片的请求看响应内容。这一步能确认两件事响应是不是一个合法的JSONJSON里有没有url字段如果响应体前面多了几个看不见的字符比如BOM头前端JSON.parse会直接抛异常这也算“服务器返回错误”的一个隐藏原因。第二步确认state字段的值是不是精确的大写SUCCESS。注意SUCCESS和success不一样UEditor判断的时候用的是严格相等。PHP代码里如果用strtoupper转一下保险得多。第三步把响应里的url复制出来直接浏览器打开确认图片能不能访问。很多场景下服务端返回的是../../upload/image/xxx.jpg这种相对路径在编辑器后台页面里访问不到前端一样会当成出错。打开php/controller.php找到uploadimage分支确保返回格式是完整的JSON并且url是可访问的地址?php // controller.php 中 uploadimage 分支的关键返回 header(Content-Type: application/json; charsetutf-8); echo json_encode([ state SUCCESS, url $fullPath, // 一定要是完整可访问的路径 title , original $originalName, source $originalName ]);这里有一个很容易被忽略的点PHP文件如果是以UTF-8编码保存但带了BOM那么header()前面会多输出几个字符导致JSON解析失败。用编辑器把文件另存为“无BOM的UTF-8”格式可以彻底避免这个问题。4.3 有没有连带解决“只显示最后一张图”有。这个现象的本质是循环里第一张图片插入了但插入后光标位置被重置后面的图片全被插到了同一个位置最后一张把前面的覆盖了视觉上就是“只显示最后一张”。只要把插入逻辑改成“拼接后一次插入”这个现象就自动消失。因为不存在多次插入和多次光标移动了所有图片都会老老实实排在同一个位置后面。所以我一直说方案A是性价比最高的修复一次性解决乱序和“只显示最后一张”两个问题。5. 常见问题速查表与避坑心得5.1 排查速查表现象可能原因处理办法图片顺序完全颠倒插入循环中光标漂移每张图片插入后光标位置变化改为拼接HTML后一次insertHtml图片顺序偶尔乱不是完全倒序服务端并发处理上传返回list顺序不稳定服务端返回seq字段前端按seq排序后再插入只显示最后一张图片多次insertHtml图片被插入同一位置后者覆盖前者同“顺序完全颠倒”的修复方案上传成功但提示“服务器返回错误”JSON格式不对或url字段缺失或返回的JSON带了BOM按4.2节三步排查修正服务端返回上传成功但编辑器里图片不显示url是相对路径前端无法访问返回完整可访问的图片地址只有第一张能插入后面的全部失败某张图片的src为空插入循环中走到continue后光标错乱过滤空src同时改用一次拼接插入这个表我贴了好几次基本后端群里有人问UEditor图片问题我都是直接发这个表过去的。查起来比一遍遍讲原理快得多。5.2 我踩过的几个坑第一个坑改完ueditor.all.js后页面没反应。那时候我还以为是改错了后来发现是浏览器缓存。UEditor的JS文件通常会被浏览器缓存得很顽固改完代码一定要强制刷新或者在引用路径后面加个版本号参数比如ueditor.all.js?v20240101否则你改半天线上跑的还是旧代码。第二个坑服务端返回的JSON里url字段前面的域名用了HTTPS但网站本身是HTTP浏览器会拦截混合内容图片加载不出来。有些场景下会被误判成“服务器返回错误”。如果你用的是HTTP站点返回的图片链接最好也用相对路径或同协议地址别写死HTTPS。第三个坑图片多的时候上传接口响应时间变长PHP默认的max_execution_time只有30秒。一次传50张高清图接口可能跑到一半就超时了前端收到的响应不完整JSON解析失败。这种情况要适当调大超时时间或者分批上传。我项目里是把max_execution_time调到120秒同时给前端加了一个loading提示用户体验会好很多。第四个坑大批量图片上传后编辑器内容区出现过长的HTML字符串某些浏览器会渲染卡顿。100张图片一下子插入页面可能要卡个一两秒。这种情况可以在插入后主动调用一次editor.sync()把内容同步到textarea避免用户切换源码模式时看到旧内容。同步操作放在execCommand(insertHtml)执行之后再调用顺序别搞反。这个老编辑器虽然停止大版本更新了但存量项目里用得还是很多。批量上传图片乱序这个问题本质不算难但坑在于很多文档只告诉你“改排序”没说清楚为什么排序、在哪一步排序、服务端要不要配合。希望这篇文章能帮你把这笔历史债还干净。我在实际项目里一般就是方案B加排查速查表这一套组合拳处理完基本没有再复发过。 
长河君 · 2026/9/11 12:29:13 · 阅读 1.2k UEditor批量上传图片乱序根因分析及修复方案详解
做UEditor二次开发的基本都撞上过这个邪门问题批量选了一堆图片上传服务器那边也显示全部上传成功回到编辑器一看图片顺序七零八落甚至有时候只插进来最后一张。更要命的是有些版本还会弹一句“上传成功服务器返回错误”明明图已经传到服务器了前端就是不往编辑器里插。这三个现象看着像三个bug其实根子都在同一个地方——UEditor的批量上传回调逻辑。今天这篇就是把这个问题彻底讲透包括乱序产生的原因、几种亲测有效的修复方案、怎么处理“上传成功但提示服务器返回错误”这个经典伴生问题以及实际排查时的顺序和技巧。适合正在维护老项目、或者还在用UEditor 1.4.x系列做后台管理的开发者参考。1. 乱序问题到底出在哪一环1.1 上传回调和插入回调是两个阶段先把流程捋清楚。UEditor的批量上传并不是一次性把图片全部插入编辑器而是分两个阶段第一阶段是上传。前端把选中的文件批量发给服务端服务端逐个处理最后返回一个JSON数组里面含有每张图片的URL、原始文件名等信息。第二阶段是插入。前端拿到这个返回的数组后遍历数组逐个把img标签插入编辑器内容区。我之前调试的时候第一反应是服务端返回顺序不对。后来用F12看了Network面板里的响应发现返回的JSON顺序和选择顺序完全一致问题出在第二阶段的插入逻辑。也就是说服务端没毛病是UEditor自身在插入环节把顺序搞乱了。1.2 光标漂移才是罪魁祸首UEditor插入图片用的是execCommand(insertHtml, html)这个命令的行为是把HTML插入到当前光标位置然后编辑器会把光标移动到刚插入内容的末尾方便你继续输入。这就出问题了。批量插入时UEditor是在一个循环里反复执行execCommand(insertHtml)// 类似这样的循环不同版本细节略有差异 for (var i 0; i list.length; i) { var item list[i]; if (item.src) { var html img src item.src alt (item.alt || ) /; editor.execCommand(insertHtml, html); } }第一张图片插入后光标跑到第一张图片的后面。第二张图片插入时正常应该插到第一张图片之后但UEditor在某些版本里每次执行insertHtml之前会重新聚焦或者重置选区结果光标回到了编辑器开头或者跳到了最后一张图片的位置。实际操作中我见过两种乱法一种是完全逆序最后选的那张跑到了最前面另一种是中间偶尔跳位看起来毫无规律。还有个隐蔽情况如果某张图片的item.src为空循环里的continue会导致这一次插入被跳过但光标位置已经被前一次插入改变后面图片的插入位置整体错位。这就是为什么有时候“只显示最后一张图”现象也会跟着出现。2. 第一个修复方案拼成一次插入2.1 找到批量插入的核心循环最直接、改动最小的修复方式就是把循环里逐个执行insertHtml改成把所有图片的HTML拼成一个字符串然后只执行一次insertHtml。这需要找到UEditor源码里批量图片上传完成后的那段回调代码。不同版本位置不太一样有的在ueditor.all.js里有的在dialogs/image/image.js里甚至有人改了名字。不用死记直接搜关键字insertHtmllist.lengthgetInfoList搜到之后把原来那种“循环里逐个执行insertHtml”的代码替换成下面的样子// 修复前逐个插入光标漂移导致乱序 for (var i 0; i list.length; i) { var item list[i]; if (!item.src) { continue; } var html img src item.src alt (item.alt || ) /; editor.execCommand(insertHtml, html); }// 修复后先拼成完整HTML一次性插入 var htmlArr []; for (var i 0; i list.length; i) { var item list[i]; if (!item.src) { continue; } htmlArr.push(img src item.src alt (item.alt || ) /); } if (htmlArr.length 0) { editor.execCommand(insertHtml, htmlArr.join()); }这样改完整个HTML是作为一个整体插入的编辑器只做一次光标移动顺序严格按照list数组的顺序不会再出现中间跳位。2.2 为什么这样能根治乱序这个方案之所以有效是因为它绕开了光标漂移问题。一次execCommand(insertHtml)执行时实际只有一次“确定插入位置”的动作后面所有图片都在同一个位置后面连续排列不存在二次定位。有人可能会问那如果list本身顺序不对拼接也没用。所以这个方案的前提是服务端返回的list顺序正确。默认情况下UEditor官方PHP版是按上传顺序返回的大部分乱序案例都是前端插入导致而不是服务端返回导致。另外要注意一个细节拼接的图片HTML里除了src之外最好把_src、alt、style这些属性也带上。有些二次开发版本里图片插入后还要做_src回填否则编辑器切到源码模式再切回来图片可能显示不出来。3. 更稳的生产级方案前端排序 服务端有序返回3.1 服务端给你的list补一个seq字段第一种方案虽然简单但有个隐患批量上传是并发的服务端处理完成返回的顺序在极端情况下可能和选择顺序不一致。我自己就遇到过服务器性能波动大时小图先传完、大图后传完返回的list顺序乱了前端再拼接也白搭。生产环境我更推荐双保险前端在插入前对list按seq字段主动排一次序。这个seq字段从哪来UEditor的前端上传组件在提交每个文件时其实会给每个文件分配一个序号但很多服务端代码在图省事的情况下不会把这个序号写进返回结果。所以要在服务端补上这一步。以常见的PHP版本为例在controller.php或自定义的批量上传接口里遍历上传文件时把序号带进去?php // 批量上传处理$files是收到的文件数组 $list []; foreach ($files as $index $file) { // 这里省略具体的move_uploaded_file等处理逻辑 $list[] [ seq $index, // 关键把序号写进返回结果 state SUCCESS, url $fullPath, original $file[name], source $file[name], ]; } // 返回前按seq升序排序确保前端拿到的顺序和选择顺序一致 usort($list, function ($a, $b) { return $a[seq] - $b[seq]; }); echo json_encode([ state SUCCESS, list $list ]);注意urldecode、转义等细节别漏尤其是文件名为中文的时候。返回的url一定要是可访问的绝对路径或正确的相对路径这一步没做对后面就会触发“服务器返回错误”。关于这个我会在第4节专门讲。3.2 前端在插入前先按seq排好序服务端返回了seq字段之后前端在上传完成回调里插入之前先排序// 上传完成回调里拿到json后先做排序 if (json.state SUCCESS) { var list json.list || []; list.sort(function (a, b) { return (a.seq || 0) - (b.seq || 0); }); // 排完序后再走插入逻辑可以和方案A结合拼接后一次插入 var htmlArr []; for (var i 0; i list.length; i) { var item list[i]; if (!item.src) { continue; } htmlArr.push(img src item.src alt (item.alt || ) /); } if (htmlArr.length 0) { editor.execCommand(insertHtml, htmlArr.join()); } }这套组合拳的好处是无论服务端返回什么顺序前端都能通过seq还原成正确的选择顺序而一次拼接插入又避免了光标漂移。两者互相补充是目前我试过最稳的方案基本能做到批量上传100张图片顺序分毫不差。3.3 这两个方案怎么选方案A简单改动小适合旧项目快速打补丁一行代码都不用加减只是把循环改一下。方案B稍微多几行但抗干扰能力强适合图片多、服务器并发上传压力大的场景。我个人习惯如果只是临时给客户修bug用方案A如果是自己项目里做长期维护建议直接上方案B。毕竟UEditor官方1.4.3.3之后基本就没大更新过后续所有问题都得自己兜底不如一开始就把排序逻辑做严谨。4. 顺手解决“上传成功服务器返回错误”4.1 这个错其实和乱序是孪生问题“提示上传成功服务器返回错误”这个现象我在排查乱序问题时几乎每次都碰到。它发生的场景通常是批量上传时第一张图插入成功后面的图怎么也插不进去界面弹一个“服务器返回错误”。但打开服务器目录图片确确实实传上去了。为什么会这样原因就是插入循环里某一张图片的src为空或者返回的JSON字段有问题导致插入逻辑走到了异常分支。这个异常分支会终止后续插入表现就是“只插进来一部分图”或者“只插进来最后一张图”。最经典的触发点在于服务端返回的JSON格式。UEditor要求的格式是{ state: SUCCESS, url: http://你的域名/upload/image/2024/01/123.jpg, original: 原名.jpg, title: , source: 原名.jpg }如果服务端犯懒返回了{status:success,path:xxx.jpg}或者url字段漏了前端连不到图就会直接报“服务器返回错误”。4.2 三步排查法碰到这个错别急着改代码按下面三步排查基本能定位第一步打开浏览器F12切到Network面板找到上传图片的请求看响应内容。这一步能确认两件事响应是不是一个合法的JSONJSON里有没有url字段如果响应体前面多了几个看不见的字符比如BOM头前端JSON.parse会直接抛异常这也算“服务器返回错误”的一个隐藏原因。第二步确认state字段的值是不是精确的大写SUCCESS。注意SUCCESS和success不一样UEditor判断的时候用的是严格相等。PHP代码里如果用strtoupper转一下保险得多。第三步把响应里的url复制出来直接浏览器打开确认图片能不能访问。很多场景下服务端返回的是../../upload/image/xxx.jpg这种相对路径在编辑器后台页面里访问不到前端一样会当成出错。打开php/controller.php找到uploadimage分支确保返回格式是完整的JSON并且url是可访问的地址?php // controller.php 中 uploadimage 分支的关键返回 header(Content-Type: application/json; charsetutf-8); echo json_encode([ state SUCCESS, url $fullPath, // 一定要是完整可访问的路径 title , original $originalName, source $originalName ]);这里有一个很容易被忽略的点PHP文件如果是以UTF-8编码保存但带了BOM那么header()前面会多输出几个字符导致JSON解析失败。用编辑器把文件另存为“无BOM的UTF-8”格式可以彻底避免这个问题。4.3 有没有连带解决“只显示最后一张图”有。这个现象的本质是循环里第一张图片插入了但插入后光标位置被重置后面的图片全被插到了同一个位置最后一张把前面的覆盖了视觉上就是“只显示最后一张”。只要把插入逻辑改成“拼接后一次插入”这个现象就自动消失。因为不存在多次插入和多次光标移动了所有图片都会老老实实排在同一个位置后面。所以我一直说方案A是性价比最高的修复一次性解决乱序和“只显示最后一张”两个问题。5. 常见问题速查表与避坑心得5.1 排查速查表现象可能原因处理办法图片顺序完全颠倒插入循环中光标漂移每张图片插入后光标位置变化改为拼接HTML后一次insertHtml图片顺序偶尔乱不是完全倒序服务端并发处理上传返回list顺序不稳定服务端返回seq字段前端按seq排序后再插入只显示最后一张图片多次insertHtml图片被插入同一位置后者覆盖前者同“顺序完全颠倒”的修复方案上传成功但提示“服务器返回错误”JSON格式不对或url字段缺失或返回的JSON带了BOM按4.2节三步排查修正服务端返回上传成功但编辑器里图片不显示url是相对路径前端无法访问返回完整可访问的图片地址只有第一张能插入后面的全部失败某张图片的src为空插入循环中走到continue后光标错乱过滤空src同时改用一次拼接插入这个表我贴了好几次基本后端群里有人问UEditor图片问题我都是直接发这个表过去的。查起来比一遍遍讲原理快得多。5.2 我踩过的几个坑第一个坑改完ueditor.all.js后页面没反应。那时候我还以为是改错了后来发现是浏览器缓存。UEditor的JS文件通常会被浏览器缓存得很顽固改完代码一定要强制刷新或者在引用路径后面加个版本号参数比如ueditor.all.js?v20240101否则你改半天线上跑的还是旧代码。第二个坑服务端返回的JSON里url字段前面的域名用了HTTPS但网站本身是HTTP浏览器会拦截混合内容图片加载不出来。有些场景下会被误判成“服务器返回错误”。如果你用的是HTTP站点返回的图片链接最好也用相对路径或同协议地址别写死HTTPS。第三个坑图片多的时候上传接口响应时间变长PHP默认的max_execution_time只有30秒。一次传50张高清图接口可能跑到一半就超时了前端收到的响应不完整JSON解析失败。这种情况要适当调大超时时间或者分批上传。我项目里是把max_execution_time调到120秒同时给前端加了一个loading提示用户体验会好很多。第四个坑大批量图片上传后编辑器内容区出现过长的HTML字符串某些浏览器会渲染卡顿。100张图片一下子插入页面可能要卡个一两秒。这种情况可以在插入后主动调用一次editor.sync()把内容同步到textarea避免用户切换源码模式时看到旧内容。同步操作放在execCommand(insertHtml)执行之后再调用顺序别搞反。这个老编辑器虽然停止大版本更新了但存量项目里用得还是很多。批量上传图片乱序这个问题本质不算难但坑在于很多文档只告诉你“改排序”没说清楚为什么排序、在哪一步排序、服务端要不要配合。希望这篇文章能帮你把这笔历史债还干净。我在实际项目里一般就是方案B加排查速查表这一套组合拳处理完基本没有再复发过。