# 保哥笔记 — 网页编辑器 > 本分片含 3 篇文章，按发布日期倒序。全部分片索引见 https://zhangwenbao.com/llms-full.md **站点**：https://zhangwenbao.com/ **分类**：网页编辑器 **生成**：2026-09-10 10:30:06 CST --- ## Markdown编辑器怎么用？左边写右边实时预览，一键导出干净HTML - URL：https://zhangwenbao.com/markdown-editor-realtime-preview-gfm-export-guide.html - 分类：网页编辑器 - 发布：2026-04-07 | 更新：2026-04-07 - 摘要：这是一款纯浏览器端运行的实时Markdown编辑器：左侧编辑、右侧逐字符同步预览，渲染由作者手写的正则解析器完成，不依赖marked或markdown-it等外部库。 - 关键词：Markdown,SEO,Word > **TLDR**：摘要：这个Markdown编辑器干的活很纯粹——左边一个框让你敲Markdown，右边实时把它渲染成HTML给你看，敲一个字、右边变一处，中间没有任何延迟。它支持标准Markdown加上GFM的表格、任务列表、删除线和自动目录，写完能一键导出成 .md、带内联样式的 .html 或纯文本 .txt。整套渲染靠它自己手写的正则解析器跑在你浏览器里，不依赖marked、markdown-it这类外部库，数据也不上传服务器。但它有几处要说在前头：代码块只会给你标个语言类名、并不真的做语法高亮（界面宣传得有点过）；目录只扫到三级标题；不支持数学公式、不支持嵌套列表、关掉页面不自动保存。把它当成一个干净利落的写作加预览台，而不是功能全开的专业IDE，期待就摆正了。 > 摘要：这个Markdown编辑器干的活很纯粹——左边一个框让你敲Markdown，右边实时把它渲染成HTML给你看，敲一个字、右边变一处，中间没有任何延迟。它支持标准Markdown加上GFM的表格、任务列表、删除线和自动目录，写完能一键导出成 .md、带内联样式的 .html 或纯文本 .txt。整套渲染靠它自己手写的正则解析器跑在你浏览器里，不依赖marked、markdown-it这类外部库，数据也不上传服务器。但它有几处要说在前头：代码块只会给你标个语言类名、并不真的做语法高亮（界面宣传得有点过）；目录只扫到三级标题；不支持数学公式、不支持嵌套列表、关掉页面不自动保存。把它当成一个干净利落的写作加预览台，而不是功能全开的专业IDE，期待就摆正了。 写网页内容的人，迟早会遇到一个选择：初稿到底用什么写？直接在富文本编辑器里拖拖拽拽，格式经常乱、复制出来一堆脏标签；直接手敲HTML，标签括号能把人写到眼花，光是给一段加粗就得 前后包一遍。在这两个极端之间，Markdown是被无数人验证过的甜点位——你用极简的符号写结构，工具替你转成规整的HTML。 而要把Markdown写得顺手，你需要一个能边写边看的编辑器。光在记事本里敲Markdown符号、靠脑补预想渲染效果，是件挺反人类的事——你永远不确定那个表格的竖线对没对齐、那个嵌套列表会不会塌掉。这个Markdown编辑器，就是来补上“边写边看”这一环的。这篇把它的内部机制、能力清单和边界，连同它在内容生产流水线里的位置，一次性讲透。 ## 内容生产第一步，为什么该用Markdown而不是直接写HTML？ 先把这个前提聊清楚，否则后面都是空中楼阁。Markdown的核心价值是“写的时候只关心结构，不关心标签”。你用 # 表示标题、用 - 表示列表项、用 ** 包住要加粗的字，符号本身轻得几乎不打断思路，而最终产出的却是结构清晰、标签规范的HTML。这种“输入极简、输出规整”的特性，让它成了博客、技术文档、说明书这类结构化内容的天然起草格式。 对做SEO和内容的人来说，还有一层额外的好处：Markdown逼着你把内容的层级想清楚。你不可能一边写Markdown一边糊弄标题层级——该是二级标题就得敲两个井号，该是列表就得老老实实用减号起头。这种约束反而是好事，它产出的HTML标题层级分明、列表语义正确，正是搜索引擎和读屏软件都爱的那种干净结构。比起在富文本里把正文也加粗成“看起来像标题”的假标题，Markdown写出来的东西，骨架要硬实得多。 更现实的一个理由是：Markdown已经成了AI时代的内容通用语。你让大模型写一篇初稿，它默认吐出来的就是Markdown；各种笔记软件、静态博客、文档平台，进出口也都认Markdown。这意味着它处在一个枢纽位置——上游接得住AI生成的草稿，下游导得出能上线的HTML。一个趁手的Markdown编辑器，就是卡在这个枢纽上的转换台。 ## 这个编辑器到底是个什么东西？ 一句话定位：它是一个纯浏览器端运行、左写右看的实时Markdown编辑器，自带工具栏、目录生成、字数统计和多格式导出。打开页面，你会看到典型的双栏布局——左边是一个大文本框，你在里面敲Markdown源码；右边是预览区，实时显示渲染后的HTML效果。两栏之间，是它的全部魔法。 它和“转换器”要分清楚。转换器是你贴一段进去、点一下、出一段结果，是单向的、一次性的。而这个是编辑器——你持续地写、它持续地渲染，是一个交互式的创作环境。它默认还会帮你载入一篇博客文章模板当起手示例，省得你面对空白框发呆。 另一个关键定位是“纯前端”。它所有的解析、渲染、导出都在你自己的浏览器里完成，源码里那个PHP文件几乎只负责吐出页面外壳，没有任何后端处理逻辑。你写的内容不会被上传到任何服务器，这对写一些还没公开的草稿、内部文档来说，是个让人安心的属性——东西始终在你自己机器上。 ## 左边敲、右边变，这个实时预览是怎么做到的？ 机制朴素得有点出人意料。左边那个文本框上挂了一个输入事件，你每敲一个键，它就立刻调用一次渲染函数：把文本框里的全部内容读出来，丢进解析器转成HTML，再把结果整个塞进右边预览区。没有防抖、没有节流，是真正逐字符级别的同步刷新——你打一个字，右边立刻就变。 真正值得说的是这个解析器本身。它没有引入任何现成的Markdown库，整个Markdown转HTML的逻辑是作者用JavaScript正则一行行手写出来的。它逐行扫描你的输入，判断每一行是标题、是列表、是引用还是普通段落，再对行内的粗体、斜体、链接这些做替换。这种自写实现的好处是轻——整个页面不用加载任何第三方依赖，打开即用、响应飞快；代价是它处理不了那些需要完整语法树才能搞定的复杂嵌套情况，这点后面会专门展开。 因为是逐行状态机式的解析，它对“围栏代码块”做了特殊处理：遇到三个反引号开头，它就进入代码块模式，把后面的内容原样保留、不再当Markdown解析，直到遇到下一组三个反引号才退出。这保证了你在代码块里写的 **星号** 不会被误当成加粗。这种状态切换，是手写解析器里最容易出bug的地方，但基础的围栏代码块它处理得是对的。 ## 它到底认得哪些Markdown语法？ 标准Markdown的常用语法，它基本都覆盖了。标题方面，# 到 ###### 六级全支持，而且会自动给每个标题生成一个锚点id，方便目录跳转。行内格式有粗体、斜体、行内代码；块级元素有围栏代码块、引用、无序列表、有序列表、分割线；链接和图片也都认得。日常写一篇文章要用到的语法，它都接得住。 这里要厘清一个容易混的概念：标准Markdown到底以谁为准。业界公认的形式化基准是CommonMark——它把Markdown那些原本含糊的语法行为（比如多少个空格算缩进、强调符号怎么配对）都精确定义了下来，CommonMark官方规范 (https://spec.commonmark.org/)就是这套标准的出处。这个工具的解析大体朝着这套标准走，但因为是手写正则、不是严格实现，边界情况会有出入，这点心里要有数。 GFM扩展是它的加分项。所谓GFM，就是GitHub在标准Markdown之上加的那套实用扩展，定义写在 GitHub Flavored Markdown官方规范 (https://github.github.com/gfm/)里。它支持其中最常用的四样：删除线（用 ~~ 包住）、表格（用竖线和短横线那套写法）、任务列表（- [ ] 和 - [x] 会渲染成可勾选的复选框）、以及在文中写 [TOC] 自动生成目录。对写技术文档的人来说，表格和任务列表是高频刚需，它都给了。 但有几条边界要明说。第一，它的列表不支持嵌套——因为解析器是逐行靠正则判断、没有追踪缩进层级，你写多级缩进的子列表，它接不住，嵌套会断掉。第二，链接和图片不支持标题属性，你写 [文字](网址 "提示") 里那个引号包着的提示，它不认。第三，代码块只支持三反引号的围栏式，不支持靠四个空格缩进来表示代码块的老写法。这些都是手写解析器为了保持简单而做的取舍，写之前心里有数就好。 ## 代码块到底有没有语法高亮？这里得说句实话 这是最需要纠偏的一点。界面和说明里提到“代码块语法高亮”，但翻开它的实现你会发现：代码块其实并没有真正的语法高亮。它做的事情仅仅是——把你在围栏后面写的语言标识（比如 js、python）记录成代码标签上的一个 language-xxx 类名，代码内容本身是原样转义后输出的，黑白一片，并没有把关键字、字符串染成不同颜色。 这个 language-xxx 类名有什么用？它是给下游的高亮库留的接口。也就是说，你把它导出的HTML拿到自己网站上，只要页面里挂了像highlight.js那样的高亮库，那个类名就能被识别、代码才会真正变彩色。换句话说，高亮这件事它只铺了一半的路——标好了语言，但上色得靠别人。理解这一点很重要，否则你会困惑“为什么我标了语言，预览里代码还是黑白的”。 它倒是有另一处真实存在的“伪高亮”，藏在“查看HTML源码”这个功能里。当你切换去看渲染产出的HTML源代码时，它会用正则把标签染成蓝色、属性染成绿色、属性值染成橙色，让你读源码时舒服些。但要分清：这是给HTML源码视图上色，不是给你代码块里的代码上色，两码事。把这两点掰开，你对它的“高亮”能力就不会有错误期待了。 ## 工具栏那一排按钮和快捷键，哪些最值得记？ 如果你Markdown符号还没背熟，工具栏就是你的拐杖。它把常用操作做成了按钮：加粗、斜体、删除线、行内代码各一个，点一下就在光标处插入对应的符号对，并把光标停在中间等你输入；标题有H1、H2、H3三个快捷按钮；列表、任务列表、引用、代码块、表格、分割线、链接、图片也各有按钮。还有一个表格按钮，点一下直接插入一个三列两行的表格模板，省得你手敲那堆竖线。 真正高频的两个操作，作者给配了快捷键：选中文字按 Ctrl+B 加粗、按 Ctrl+I 变斜体，和你在Word里的习惯一致，肌肉记忆能直接迁移。另外按 Tab 键，它会插入两个空格而不是把焦点跳走——这是代码和Markdown编辑器里很贴心的一个细节，让你能用Tab做缩进。其余的按钮没有配快捷键，得靠鼠标点。 它还内置了几套模板，从下拉里选就能一键载入：README模板、博客文章模板、API文档模板、Markdown速查表。新建文档不知道怎么起头时，挑一套贴近的模板改改，比从零开始快得多。页面默认就帮你载入了博客模板，算是给了个温柔的起点。 ## 导出MD、HTML、TXT，三种格式各在什么场景用？ 写完之后，导出是这个工具兑现价值的关键一环，它给了三种格式，对应三种不同的下游需求。导出 .md，存的是你的Markdown源文本，适合归档、版本管理、或者拿去喂给另一个支持Markdown的平台——你的原始结构原封不动地带走。 导出 .html 最值得说。它导出的不是光秃秃的HTML片段，而是一个带了内联样式的完整HTML文档——字体、颜色、表格边框、代码块背景这些样式都内嵌在文件里。这意味着你双击就能在浏览器里打开、效果跟预览区一模一样，拿去离线分享、做附件发给别人都行。但也正因为它是“完整文档加内联样式”，如果你想把内容塞进自己CMS的正文框里，这个完整文档反而不合适——你要的是干净的正文片段，这时更该用“复制HTML”按钮，把预览区的HTML复制出来再做取舍。 导出 .txt 则是把渲染后的内容剥成纯文本，标签全去掉，适合你只要文字、不要任何格式的场景，比如导进一个只认纯文本的地方。三种格式之外，它还有“复制Markdown”和“复制HTML”两个剪贴板按钮，配合导出，基本覆盖了“我要把成品搬到哪去”的各种姿势。 ## 把它接进AI内容生产工作流，到底能省多少事？ 这才是它在今天最有价值的用法。现在很多内容团队的初稿，是让大模型先生成的——而大模型默认输出的就是Markdown。问题来了：AI给你一大段Markdown，你怎么快速看清它的结构对不对、标题层级有没有乱、表格画得齐不齐？直接读源码符号太累，塞进CMS又太重。这个编辑器恰好补上中间这一环：把AI的Markdown整段贴进左边，右边立刻渲染出来，结构是好是坏一目了然。 在预览里，你能很快发现AI初稿的结构毛病：是不是通篇只有一级标题没有层次、列表是不是该用却用了流水段落、关键数据是不是该进表格却堆在正文里。看出问题，回到左边改Markdown，右边同步变，这个“改一处看一处”的循环，比在Word里盲改高效太多。等结构调顺了，一键导出HTML，下游再做精修。 从SEO的角度，这一环的价值在于“把内容洗成干净的语义结构”。AI初稿经常层级混乱，而你在这一步用Markdown把标题层级、列表、表格捋顺，导出的HTML自然就有了清晰的 h2、h3 骨架和规范的列表语义。MDN在它的标题元素文档 (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/Heading_Elements)里讲得很清楚：一个页面通常该只有一个 h1、标题要逐级嵌套不要跳级，读屏软件甚至会靠标题生成全页大纲来帮用户导航。Markdown的写法天然就在引导你遵守这套规矩，这是它产出SEO友好结构的底层原因。 ## 用它写出来的HTML，对SEO到底友不友好？ 结论是：骨架友好，但有几个细节你得自己补。友好的部分前面说了——标题层级清晰、列表语义正确、表格规整，这些都是搜索引擎喜欢的结构信号。它给标题自动加锚点id，也方便你后续做页内跳转和目录。从“内容结构是否规范”这个维度看，它产出的HTML是合格的。 但有几处它帮不了你，得心里有数。第一，图片的 alt 文本得你自己在Markdown里写全——它会忠实地把 ![描述](图片) 里的描述转成 alt 属性，但如果你写图片时偷懒留空，它不会替你补，而 alt 恰恰是图片SEO和无障碍的关键。第二，它的目录只扫到三级标题，四级以下的标题不会进 [TOC]，如果你的文章层级很深，自动目录会不完整。 第三，前面提过的代码高亮——导出的代码块只有 language-xxx 类名、没有真高亮，你的网站得自己配高亮库才能让代码变彩色，否则读者看到的是黑白代码块。这些都不是大毛病，但属于“工具产出干净骨架、你负责填好血肉”的分工。把它定位成结构层的好帮手、而不是全自动的SEO优化器，用起来才不会有落差。如果你的内容最终要做成AMP移动页，记得上线前再用 AMP验证器 (https://zhangwenbao.com/amp-validator-mobile-amp-html-compliance-guide.html)过一道合规检查。 ## 三步，把一篇AI初稿变成能上线的干净HTML 说了这么多，不如给一条能照着走的流程。我们团队在处理AI辅助写作的稿子时，常用下面这三步把Markdown草稿收成可发的成品。 - 贴进去看结构。把AI生成的、或你自己手写的Markdown整段粘到左边文本框，立刻看右边的渲染效果。重点扫三样：标题层级是否分明、该用列表和表格的地方有没有用、有没有通篇大段不分段。结构上的硬伤，这一眼基本能抓全。 - 边改边补血肉。用工具栏和快捷键把结构调顺——拆标题、补列表、把堆在正文里的数据搬进表格。同时把每张图片的 alt 描述写全、给代码块标好语言。改一处右边变一处，直到预览效果你满意为止。 - 按需导出。要离线分享或存档，导出带样式的 .html；要塞进自己CMS的正文框，改用“复制HTML”拿干净片段、再做取舍；要留原始结构做版本管理，导出 .md。选对出口，成品才好接下一棒。 这套流程的核心，是把“看不见结构的盲写”变成“所见即所得的明写”。结构这东西，光在脑子里想容易翻车，摆在眼前改才靠谱。三步下来，一篇结构干净、骨架规范的HTML就出来了，后面交给HTML编辑器 (https://zhangwenbao.com/html-editor-html-css-js-live-preview-guide.html)精修样式、调呈现效果，或者直接进CMS，都顺。 ## 宠物用品那个站，后来是怎么把它用顺的？ 去年帮一个做智能宠物饮水机和猫砂盆的出海独立站理内容流程。他们的痛点很典型：博客是几个人一起写的，有人用Word、有人用在线文档、还有人直接让AI生成，交上来的稿子格式五花八门，编辑光是把这些统一成能进CMS的干净HTML，每周就要耗掉大半天，而且经常漏改。 我们给的方案不复杂：要求所有初稿，不管最初用什么写，最后都先过一遍这个Markdown编辑器。AI生成的稿子本就是Markdown，直接贴进去；Word和在线文档写的，作者自己花两分钟转成Markdown再贴。统一在这一栏里，对照右边的预览把标题层级、列表、表格捋顺，图片 alt 补全。结构对齐之后，编辑只需要从这里拿规范的HTML，再不用面对五种格式各自的脏标签。 效果最明显的是博客文章的结构一致性。以前几个作者写出来的文章，标题层级各有各的乱，有人通篇一级标题、有人正文加粗冒充标题；统一过编辑器之后，每篇都是清清楚楚的二级、三级标题嵌套，列表和表格也都用对了地方。一段时间下来，他们博客在长尾词上的表现稳了不少——倒不全是这个工具的功劳，但“内容结构终于规整了”这件事，确实是个绕不开的地基。工具本身没干什么高深的事，它只是把“人人格式不一”这摊乱账，收敛成了一条所有人都走的统一通道。 ## 它和那些功能全开的专业Markdown编辑器，差在哪？ 得诚实承认，跟那些重量级的桌面Markdown编辑器比，它是个轻量选手，有几样东西它确实没有。最要紧的一条：它不自动保存。它没有用浏览器的本地存储做草稿持久化，你写的内容只活在当前页面里，一旦手滑关了标签页、或者浏览器崩了，没导出的内容就没了。所以用它的铁律是——写到一段落就导出一次，别指望它替你兜底。 其他缺的功能还有：不支持数学公式，写论文里那种LaTeX公式它渲染不了；编辑区和预览区不支持同步滚动，你拉长文档时，左右两边各滚各的，对不上行（界面宣传里曾提到同步滚动，但实际没实现，这点也得纠正一下）；没有多文档管理、没有云端同步、没有协作编辑。这些都是专业编辑器的标配，它一概没有。 那它的位置在哪？恰恰在于“随手就能用”。专业编辑器要下载安装、要学一堆功能，而它开个网页就用、零学习成本、数据不出本地、还免费。当你只是要快速看一段Markdown的渲染效果、临时改一篇稿子的结构、或者把AI初稿洗成HTML，杀鸡真不必用牛刀。把它当作内容流水线上那个轻便趁手的预览加转换台，而不是你日常重度写作的主力IDE，定位就对了。 ## 关掉网页内容就没了，怎么避免白写一场？ 这是用它最容易踩的坑，单独拎出来强调。前面说过它不自动保存，所有内容只在当前浏览器标签页的内存里。这意味着任何意外——误关标签页、浏览器崩溃、电脑重启、甚至不小心点了“清空”——都会让没导出的内容灰飞烟灭，且无法恢复。它没有回收站、没有历史版本、没有任何后悔药。 规避的办法只有一个，就是养成“勤导出”的习惯。写作时每完成一个段落、或者每隔十几分钟，就顺手按一下导出 .md，把当前进度存成文件。文件存在你硬盘上，下次要接着写，再把内容贴回来即可。这听起来有点笨，但对一个明确不做自动保存的工具来说，这是唯一稳妥的姿势。 更稳的做法，是干脆别把它当长期写作的容器。把真正的写作和存稿放在你有版本管理的地方（比如本地的Markdown文件、或者带云同步的笔记软件），只在需要“看渲染、调结构、转HTML”的时候，把内容临时贴进这个编辑器过一道。把它当成一个加工工位、而不是仓库，你就永远不会因为它不保存而吃亏。 ## 这把写作快刀，切不动哪些活？ 把边界一次性钉清楚，免得你在某个细节上栽跟头。第一类是语法上的边界：不支持嵌套列表、不支持数学公式、链接和图片不支持标题属性、代码块只认围栏式不认缩进式、行内代码里嵌反引号会出错。这些都是手写解析器为求轻量做的取舍，写复杂结构时它会力不从心。 第二类是功能上的缺失：代码块没有真正的语法高亮（只标语言类名）、目录只扫到三级标题、不自动保存、不支持同步滚动、没有多文档和协作。它是个单文档、纯本地、写完即走的轻量工具，重度写作要的那些花活它都没有。 第三类是定位上的边界：它是编辑加预览台，不是排版工具、不是发布系统、更不是SEO优化器。它能帮你产出结构干净的HTML骨架，但图片 alt 写没写全、关键词布得好不好、代码高亮配没配，这些得你自己接着干。把这几条记牢——语法有取舍、功能偏轻量、定位是加工台——它就是内容流水线上一把趁手的快刀；忘了这些，它可能在你最需要它扛事的时候掉链子。理解它的窄，才能用好它的快。 🔧 动手试试：Markdown编辑器 左边写右边实时预览，一键导出干净HTML。这是保哥自研的免费在线工具，浏览器里打开就能用，不用注册、不用装插件。 → 打开Markdown编辑器 (https://zhangwenbao.com/tools/markdown-editor.php) ## 常见问题解答 它用的是marked或markdown-it这类库吗？渲染结果会和GitHub完全一致吗？都不是，它的Markdown转HTML是作者用JavaScript正则手写的解析器，没有引入任何第三方Markdown库。所以渲染结果跟GitHub、跟严格遵循CommonMark的渲染器会有细微出入，尤其在复杂嵌套、边界语法上。日常的标题、列表、表格、代码块它处理得对，但你要的是和某个平台像素级一致的渲染，得用那个平台同款的解析器，别指望它百分百对齐。 我标了代码块的语言，为什么预览里代码还是黑白的？因为它本身不做代码语法高亮，只是把你标的语言记成代码标签上的 language-xxx 类名，留给下游的高亮库去识别。预览区没挂高亮库，所以代码是黑白的、这是正常现象。等你把导出的HTML放到自己网站、且网站里挂了像highlight.js这样的库，那个类名才会被识别、代码才会真正变彩色。 导出的HTML能直接贴进WordPress或我的CMS正文吗？不建议直接贴导出的那个 .html 文件——它是个带内联样式的完整文档，包含 html、head、style 这些外层结构，塞进CMS正文框会冲突。正确做法是用“复制HTML”按钮，复制预览区的正文片段，再按需删掉不想要的内联样式，这样拿到的才是干净、能直接入库的正文HTML。 它的字数统计准吗？中文怎么算？它的字数统计是把内容里的空白字符去掉后数总字符数，再附带统计行数。所以对中文来说，它数的其实是“字符个数”，一个汉字算一个；英文则是按字符不是按单词算。如果你对篇幅有精确要求、需要区分中英文词数、或者要算阅读时长，建议另用更专业的字数统计工具 (https://zhangwenbao.com/word-counter-content-length-reading-time-audit-guide.html)，它做的统计维度要细得多。 我写到一半电脑重启，内容还在吗？大概率不在了。它不做自动保存，内容只存在当前浏览器标签页里，重启、关页面、浏览器崩溃都会让没导出的内容丢失且无法恢复。唯一的办法是勤导出——写到一段落就按一下导出 .md 存成文件。更稳妥的姿势是把它当临时加工台、而不是写作仓库，真正的稿子存在你有版本管理的地方。 ## KindEditor批量上传图片限制：2方法+避坑实战 - URL：https://zhangwenbao.com/kindeditor-images-upload-batches-modified.html - 分类：网页编辑器 - 发布：2020-11-20 | 更新：2026-06-02 - 摘要：KindEditor批量上传图片数量与大小限制如何修改？详解imageSizeLimit、imageUploadLimit两种放宽方案、kindeditor-all.js源码改法、PHP与Nginx配套配置、升级合并脚本和性能优化技巧。 - 关键词：kindeditor,富文本编辑器,JavaScript > **TLDR**：摘要：KindEditor批量上传图片的数量和大小限制怎么改？本文先讲清两个限制到底从哪来，给两种放宽方案——初始化时直接配imageSizeLimit和imageUploadLimit参数、直接改kindeditor-all.js源码默认值，再讲服务端PHP与接口必改的参数、升级时怎么保留改动、大批量上传的性能调优和迁移建议。 > 摘要：KindEditor批量上传图片的数量和大小限制怎么改？本文先讲清两个限制到底从哪来，给两种放宽方案——初始化时直接配imageSizeLimit和imageUploadLimit参数、直接改kindeditor-all.js源码默认值，再讲服务端PHP与接口必改的参数、升级时怎么保留改动、大批量上传的性能调优和迁移建议。 保哥前段时间帮朋友维护一个老的企业站，后台编辑器用的是KindEditor (https://zhangwenbao.com/ecshop-replaces-baidu-editor-to-add-batch-upload-pictures.html) 4.1系列。客户那边经常一次要往一篇文章里塞五六十张产品图，结果一上传就提示一次最多20张、单图不超过1MB。这两个限制其实是KindEditor自己默认的，并不是PHP或者Nginx卡住的，所以解决思路也比较固定。下面这篇是我把改这台机器的过程整理出来的实战记录，包含初始化参数配置、源码层修改、PHP与Nginx的配套参数、升级时的合并脚本和大批量上传的性能调优经验，方便后面再有项目踩到同一个坑可以直接复用，省掉每次重新摸一遍的时间成本。 ## 先确认两个限制到底是从哪里来的 这是排查这类问题最重要的一步，否则改了半天发现改错地方，白白浪费时间。KindEditor的批量图片上传插件叫multiimage，它的两个默认值写在kindeditor-all.js里，在4.1.11版本中大约在8085行附近： imgPath = self.pluginsPath + 'multiimage/images/', imageSizeLimit = K.undef(self.imageSizeLimit, '1MB'), imageFileTypes = K.undef(self.imageFileTypes, '*.jpg;*.gif;*.png'), imageUploadLimit = K.undef(self.imageUploadLimit, 20), 这里K.undef的意思是：如果调用方没有显式传入imageSizeLimit和imageUploadLimit，就用默认的1MB和20。换句话说，限制有两个层次。第一层是前端默认值，写死在kindeditor-all.js里，影响所有调用方；第二层是后端兜底，上传接口（PHP的upload_json.php或者你自己实现的接口）会再校验一次。两个层次都要看，前端只是不让你选超过限制的文件，真正能不能存下来还得看后端。 我之前调试时就遇到过前端配好了10MB，后端php.ini还是2M，结果换成弹服务器拒绝上传，那种报错更迷惑。所以正确的姿势是先想清楚自己改的到底是哪一层，避免来回折腾。三层校验从浏览器到磁盘的顺序大致是：浏览器JS校验文件大小和数量、上传请求经过Nginx判断client_max_body_size、PHP接管读取upload_max_filesize和post_max_size、最后KindEditor自带upload_json.php或自写接口再做MIME和扩展名校验。任何一层没改对，上传都会失败，错误现象还各不相同。 ## 三层校验的失败现象与定位方法 建立一张速查表，遇到失败时直接对照定位，能节省大量盲改时间： 失败现象 | HTTP状态 | 失败层次 | 定位思路 | 前端弹窗"文件大小超过1MB" | 未发起请求 | JS默认值 | 改imageSizeLimit或源码K.undef默认值 | 前端弹窗"最多上传20个文件" | 未发起请求 | JS默认值 | 改imageUploadLimit或源码K.undef默认值 | 上传后浏览器报413 Request Entity Too Large | 413 | Nginx | 放大client_max_body_size | 上传后浏览器报500 Internal Server Error | 500 | PHP内存或体积 | 检查memory_limit和upload_max_filesize | 页面无响应，$_FILES为空 | 200但空 | PHP整体POST | 放大post_max_size、max_file_uploads | 返回JSON里写着error: 上传文件大小超过限制 | 200 | upload_json.php | 改max_size字节数 | 返回JSON里写着error: 不允许的文件类型 | 200 | upload_json.php白名单 | 改$ext_arr的image数组 | 这张表是我过去5年维护KindEditor项目时反复用到的，按HTTP状态码倒推根因，比一遍遍把所有配置都改一遍要科学得多。第一次遇到413时我花了2小时才发现是Nginx卡的，后来直接看状态码就知道改哪里。 ## 方法一：在初始化KindEditor时直接配置参数 这是我最推荐的做法，因为不用改第三方源码，未来升级KindEditor的时候不会被覆盖丢失，对版本管理也最友好。把页面里调用KindEditor的那段JS改成下面这样： 几个我自己踩过的小坑顺手说一下。第一，imageSizeLimit一定要带单位，写成数字会按字节算，写成10直接变成10字节，相当于完全不让上传。第二，imageUploadLimit是数字不是字符串，这个参数没单位，写成字符串100也能跑但和官方文档不一致，建议保持数字类型避免类型校验误判。第三，旧浏览器（比如IE9）会忽略multiple属性，自然也就没有批量概念，遇到这种情况只能升级浏览器，没法靠KindEditor解决。第四，如果你给页面同时挂了多个编辑器实例，每个实例的参数要单独传，不然第二个会继承第一个的默认配置导致行为诡异。 第五个坑相对隐蔽：当你在动态加载的iframe或Vue组件里初始化KindEditor时，KindEditor.ready可能因为DOM未就绪而提前执行，导致参数丢失。解决办法是在容器节点渲染完成后再手动调用KindEditor.create，或者用nextTick等待DOM刷新。这个问题在用Element UI的Dialog和Modal时特别容易出现，我有一次为此调试了整整一天，最后发现是Dialog的v-if销毁了DOM节点。 ## 方法二：直接改kindeditor-all.js源码默认值 如果项目里有几十个页面都在初始化KindEditor，又不想一个一个改JS，可以选择改源码默认值。先把原始文件备份一份，再用编辑器搜索multiimage，定位到上面那段K.undef赋值代码，把后两行改成： imageSizeLimit = K.undef(self.imageSizeLimit, '10MB'), imageUploadLimit = K.undef(self.imageUploadLimit, 100), 注意改完别忘了清缓存。如果你的网站套了CDN，最稳妥的做法是给kindeditor-all.js加一个版本号查询串： 这样CDN和浏览器都会拉新版本。我自己写过一个小脚本，把每次发布的时间戳自动写进script src里，省掉手动改版本号的麻烦。如果项目里有自动构建工具，比如Webpack或Vite，可以让构建时自动注入哈希；如果没有，写个简单的PHP帮助函数也够用： function asset($path) { $abs = __DIR__ . '/public' . $path; $ver = file_exists($abs) ? filemtime($abs) : time(); return $path . '?v=' . $ver; } 这样模板里写asset函数包裹路径就会自动带上文件最后修改时间，文件改一次缓存就被打破一次，绝对不会出现客户那边看到的还是旧版的尴尬。在大型项目里我还会进一步做版本号的子资源完整性校验（SRI），给script标签加integrity属性，避免CDN劫持后用户拉到被篡改的JS文件。 ## 服务端PHP配套必改的参数 这一步绝对不能忘。前端放宽了，服务端没放宽，照样上传失败，而且报错还不直观。以php.ini为例，至少要确认下面几个值： file_uploads = On upload_max_filesize = 20M post_max_size = 220M memory_limit = 256M max_file_uploads = 200 max_execution_time = 120 max_input_time = 120 这里有个隐藏规则：post_max_size必须大于等于单图体积乘以一次上传的张数，否则PHP会直接吃掉整个POST而$_POST、$_FILES都是空的，前端表现就是按了上传没反应，连PHP错误日志里都看不到记录，非常容易把人逼疯。我的经验值是：单图10MB+张数100=1000MB理论上限，实际配置220MB通常足够覆盖典型批量上传场景，因为客户极少一次性满额上传。 如果用的是Nginx，记得在站点配置里把上传体积也放开： client_max_body_size 220m; client_body_buffer_size 1m; client_body_timeout 120s; send_timeout 120s; 配置改完执行nginx -t检查语法，确认无误后reload nginx，然后reload php-fpm让两边都生效。重启与reload的区别在于：reload不会断开现有连接，对生产环境更友好；restart会强制断开，建议只在调试时使用。我自己排查这类问题的顺序是：先开浏览器F12看上传失败的请求HTTP状态码，413一定是Nginx拒绝，500一般是PHP内存或upload_max_filesize不够，200但返回的JSON里写着error才是KindEditor自己的逻辑校验。按状态码倒推根因，比把所有配置都改一遍要科学得多。 ## 服务端接口本身的限制也要看一眼 第三层兜底是KindEditor自带的php/upload_json.php，里面也写死了一份白名单和大小限制。打开这个文件，会看到类似下面的代码： $ext_arr = array( 'image' => array('gif', 'jpg', 'jpeg', 'png', 'bmp'), 'flash' => array('swf', 'flv'), 'media' => array('swf', 'flv', 'mp3', 'wav', 'wma', 'wmv', 'mid', 'avi', 'mpg', 'asf', 'rm', 'rmvb'), 'file' => array('doc', 'docx', 'xls', 'xlsx', 'ppt', 'htm', 'html', 'txt', 'zip', 'rar', 'gz', 'bz2'), ); $max_size = 1000000; $max_size是字节数，1000000大约就是1MB。要改成10MB直接写： $max_size = 10 * 1024 * 1024; 如果你想顺便支持webp，把image那一行改成包含webp扩展名的数组，再把avif也加上，能覆盖2025年主流手机厂商导出的新一代图片格式。这一步是不少教程会漏掉的地方，前端、php.ini、Nginx都改完了还失败，往往就是这里在卡。还有一个小细节：upload_json.php默认会用getimagesize来确认是不是真图片，遇到某些手机厂商导出的特殊webp时这个函数会失败，建议改成结合mime_content_type和扩展名一起判断，可以兼容更多格式。 从安全角度看，upload_json.php还有一个经典漏洞：默认会用原始文件名拼接路径保存，如果用户上传名为../../../../etc/passwd.jpg的文件，再加上MIME校验不严，可能导致目录穿越。修复办法是用md5(uniqid())重命名所有上传文件，扩展名也用白名单严格校验，永远不要信任客户端传上来的文件名。 ## 升级版本时如何保留这些改动 KindEditor已经多年没有大版本更新，但偶尔还是会打安全补丁。每次升级我都会经历同样的流程，干脆固化成一个清单放在项目README里：备份现有的kindeditor整个目录、解压新版到临时目录、用diff对比新旧kindeditor-all.js中multiimage段的差异、把自定义的imageSizeLimit和imageUploadLimit重新合并进去、把php/upload_json.php里的max_size和ext_arr同样合并、把旧目录改名做备份再把新版重命名为正式目录、最后给JS加一个新版本号防CDN缓存。 我自己还多写了一个简单的shell脚本，用来一次性完成上面这些事： #!/usr/bin/env bash set -euo pipefail ROOT=/var/www/html/static/kindeditor DATE=$(date +%Y%m%d%H%M) cp -a "$ROOT" "$ROOT.bak.$DATE" unzip -o /tmp/kindeditor-new.zip -d /tmp/ke-new rsync -a /tmp/ke-new/kindeditor/ "$ROOT/" sed -i "s/'1MB'/'10MB'/" "$ROOT/kindeditor-all.js" sed -i "s/imageUploadLimit, 20/imageUploadLimit, 100/" "$ROOT/kindeditor-all.js" echo "done at $DATE" 这套流程我现在用了三年，一次都没翻过车。比起每次升级都靠记忆去改，写下来照做实在轻松太多，新人接手也能立刻按部就班执行，不会一上手就把客户的配置覆盖丢。脚本里的关键点：set -euo pipefail能让任何一步失败立刻退出避免半成品状态、cp -a保留权限和时间戳、rsync -a保证目录权限正确、sed的两个替换精确锁定要改的行不会误伤其他位置。 ## 大批量上传的真实性能调优经验 聊完了限制怎么改，再说点实际遇到的性能问题。客户那边经常一次拖几十张高分辨率手机照片进来，单张原图动辄五六兆，真要一次性丢上来很容易把页面卡到无响应。保哥总结过一些可以立竿见影的优化办法。 第一是在前端加上一个简单的图片预压缩流程。浏览器现在对Canvas和OffscreenCanvas支持都已经很完善，可以在用户选完图片之后立刻在客户端按最大边缩到1920像素，再丢给上传接口。这样既能减少流量又能减少服务器内存压力。50张原图平均5MB的总量250MB，压缩后能降到80至100MB，上传时间从原来的2分多钟缩短到30秒左右，体验完全不在一个量级。 第二是在服务器端用imagick替代gd处理大图。imagick对内存的控制远比gd友好，处理一张二十兆的RAW时不会动不动就把PHP进程撑爆。安装命令是apt install php8.2-imagick或yum install php-imagick，重启php-fpm生效。imagick还支持读取RAW、HEIC等手机厂商专有格式，对苹果设备导出的图片兼容性最好。 第三是把图片的原图存到对象存储而不是本机磁盘。常见选型包括阿里云OSS、腾讯云COS、AWS S3、Cloudflare R2等。R2在2025年起免出口流量费用，对流量大的项目特别友好。原图存对象存储后接CDN，访问体验会有一个数量级的提升，源站只需要保留缩略图 (https://zhangwenbao.com/deformable-clipping-method-for-dedecms-thumbnails.html)本地缓存即可。 再说一个容易忽视的细节。KindEditor的批量上传走的是一个个独立的POST请求，每张图片对应一次HTTP调用，并不是把所有文件打包成一个请求一次传完。所以如果你只是放大了post_max_size而没有改max_file_uploads，看上去也还是能用，但实际上每张图片都在串行发起请求，浏览器一次只跑两到六个并行连接。要让批量上传感觉更快，可以在afterCreate里把上传插件的并发数手动调一下，比如把请求分成几组并发发出，再统一回写到编辑器里。改完之后客户那边明显感受到差别，原来上传50张图要等两分多钟，现在大概30秒就能搞定。 最后顺手提醒一句：所有客户端层面的优化都不能替代服务端校验，上传体积、文件类型、文件名安全性这些校验在后端必须都要做一遍，否则等于在前端贴了一张纸，恶意用户绕过去毫无成本。 ## 2026年KindEditor的生存现状与迁移建议 KindEditor的最后一次正式更新是2018年，2026年的今天它依然在数万个传统企业站、政府门户和论坛系统里跑得稳稳的。这种"老而弥坚"的现象其实非常合理：富文本编辑器的核心需求是稳定输出HTML、支持图片上传、能扩展自定义按钮，KindEditor这三件事都做得很扎实，新版编辑器拼的是协同编辑、Markdown、AI辅助等附加能力，对传统企业站不是刚需。 但如果你的项目有下面这些特征，可以考虑迁移到更现代的编辑器： - 用了TypeScript做技术栈，需要编辑器原生支持类型定义。 - 需要协同编辑功能，多人同时改一篇文章不冲突。 - 需要Markdown和富文本混排，方便开发者和编辑共用。 - 需要移动端友好，KindEditor在iOS Safari上的工具栏体验较差。 - 合规要求严格，新编辑器的XSS防护机制更完善。 主流替代方案的优劣对比： 编辑器 | 核心优势 | 主要劣势 | 迁移难度 | TinyMCE 7 | 商业支持、插件生态丰富 | 免费版功能受限、商用需授权 | 低 | CKEditor 5 | 协同编辑、Markdown混排 | API完全重写、迁移成本高 | 高 | wangEditor 5 | 国产、文档中文、轻量级 | 插件生态小、企业支持弱 | 中 | Quill 2 | 开源免费、Delta格式可控 | 富文本能力相对弱 | 中 | ProseMirror | 底层框架、自定义能力最强 | 需自行实现UI、开发周期长 | 高 | 我自己迁移过一次，做法是先写一个临时脚本把所有pre.wp-block-code这类老的内联样式批量改成新编辑器认识的标签，再迁移内容，迁移完肉眼抽检几篇典型文章，没问题再切流量，整个过程相对平稳。如果你的内容量超过万篇，建议分批迁移：先迁100篇试点，观察一周用户反馈，再批量迁剩余内容，避免一次性全量切换风险过大。 ## 常见问题解答 ## KindEditor默认能批量上传多少张图片？ KindEditor的multiimage插件默认值写死在kindeditor-all.js里，一次最多20张、单张最大1MB。这两个值由K.undef(self.imageUploadLimit, 20)和K.undef(self.imageSizeLimit, 1MB)控制，没有显式传参时就走默认。要放宽必须从前端参数、源码默认值、服务端接口三层任选其一改起，单层改动不够会被另一层兜底卡住。一般推荐改前端参数加服务端配套，源码默认值改动留作所有页面统一升级时使用。 ## imageSizeLimit和imageUploadLimit参数怎么用？ imageSizeLimit是单文件大小上限，必须带单位写10MB或20MB，写成纯数字会被当字节算导致几乎不能上传。imageUploadLimit是批量数量上限，纯数字传入即可，例如100或200。两个参数在KindEditor.create的配置对象里直接写，优先级高于源码默认值，是最干净的改法，未来升级KindEditor也不会丢失。配置完成后必须配合服务端php.ini和Nginx对应放大才能完整生效。 ## 改完前端后还是上传失败是什么原因？ 最常见的是浏览器或CDN缓存了旧的kindeditor-all.js，给script标签加版本号查询串如?v=20260513能强制刷新。第二常见的是PHP和Nginx的兜底没改，post_max_size必须大于单图体积乘以一次上传张数，client_max_body_size也要同步放大。第三是KindEditor自带的php/upload_json.php里写死的max_size=1000000仍在卡，需要改成10*1024*1024。按F12浏览器开发者工具看请求状态码能快速定位失败层级。 ## 修改kindeditor-all.js源码升级时怎么保留？ 用版本控制把diff保存下来。每次升级执行三步：备份现有目录、解压新版到临时位置、用sed把imageSizeLimit和imageUploadLimit两个默认值替换回自定义值。也可以写shell脚本固化流程，例如sed -i s/1MB/10MB/和sed -i s/imageUploadLimit, 20/imageUploadLimit, 100/。脚本配版本号查询串能彻底解决CDN缓存问题。建议把整个升级流程写进项目README，让新人接手也能照做。 ## 服务端PHP配套需要改哪些参数？ php.ini里upload_max_filesize必须大于imageSizeLimit，post_max_size要大于单图乘以张数，max_file_uploads要大于imageUploadLimit数字，memory_limit建议256MB以上，max_execution_time和max_input_time给到120秒。Nginx的client_max_body_size、client_body_timeout、send_timeout同步放大。改完执行php-fpm reload和nginx reload两边生效，再开浏览器F12看上传请求状态码反向定位。 ## KindEditor 2026年还推荐使用吗？ KindEditor已经多年没有大版本更新，但代码结构简单、性能稳定，至今仍是大量传统企业站和论坛的首选编辑器。如果项目需要更现代的编辑体验或团队需要TypeScript支持，推荐迁移到TinyMCE 7、CKEditor 5或国产的wangEditor 5。迁移前先用脚本把所有内联样式和老标签批量映射到新编辑器认识的格式，迁移后抽检几篇典型文章再切流量，能把迁移风险降到最低。 ## 上传大批量图片性能慢如何优化？ 前端在用户选图后用Canvas或OffscreenCanvas按最大边1920像素预压缩，能减少70%以上的上传体积。服务端用imagick替代gd处理大图，imagick的内存控制比gd友好得多，处理20MB的RAW图也不会撑爆PHP进程。把原图存到对象存储而不是本机磁盘并接CDN边缘缩略图服务，能让首页响应快一个数量级。所有客户端优化必须配合服务端复检，文件类型、体积、文件名安全都要在后端再做一遍。 ## 结语 KindEditor虽然多年没有大版本更新，但它结构简单、改动透明，至今依然是很多老项目里最稳定的编辑器之一。只要你理解了它三层校验的逻辑——前端参数、源码默认值、服务端接口三处改动都能对得上号，这种限制类的问题基本就不会再困扰你了。如果项目计划长期维护，建议把本文的升级合并脚本和PHP/Nginx配套参数固化到部署文档里，新人接手也能按部就班执行；如果项目计划在未来一两年迁移到更现代的编辑器，可以先把本文方法一的KindEditor.create配置抽成独立模块，迁移时只需替换模块内部实现，外部调用代码不用动，把迁移成本压到最低。 ## 权威参考资料 ## KindEditor编辑器深度优化指南：上传目录归档、批量限额、p标签清理与CSRF安全加固 - URL：https://zhangwenbao.com/kindeditor-image-upload.html - 分类：网页编辑器 - 发布：2020-11-20 | 更新：2026-06-02 - 摘要：KindEditor开箱即用，但上传目录、批量限额、空标签和安全都得自己收口。本文给出具体代码：调批量上传数量与单图大小、按年月分目录归档并UUID重命名、清理空p与图片包段落，再补登录鉴权、双扩展名拦截、MIME真实类型校验和三层限额配置。 - 关键词：kindeditor,富文本编辑器,安全加固 > **TLDR**：摘要：KindEditor开箱即用，但上传目录、批量限额、空标签和安全都得自己收口。本文给具体代码——关闭网络图片标签页、调批量上传数量与单图大小、上传目录按日期归档并UUID重命名、清理图片自动包的p标签，再补CSRF与XSS与文件类型验证的安全加固，以及与WordPress和Discuz和DedeCMS的集成和实战故障排查。 > 摘要：KindEditor开箱即用，但上传目录、批量限额、空标签和安全都得自己收口。本文给具体代码——关闭网络图片标签页、调批量上传数量与单图大小、上传目录按日期归档并UUID重命名、清理图片自动包的p标签，再补CSRF与XSS与文件类型验证的安全加固，以及与WordPress和Discuz (https://zhangwenbao.com/discuz-global-variables-details.html)和DedeCMS的集成和实战故障排查。 KindEditor (https://zhangwenbao.com/kindeditor-images-upload-batches-modified.html) 是 2006 年起就被广泛集成进 PHP/.NET CMS 的所见即所得编辑器，DedeCMS、ECShop (https://zhangwenbao.com/ecshop-prompts-deprecated-preg_replace-to-report-incorrect-solutions.html)、phpcms、Discuz 多个版本都把它当过默认富文本编辑器。绝大多数项目用它都会撞上同一组痛点：图片上传目录混乱、上传大小受限、单图传完会自动包一层


、网络图片入口有安全隐患、多图批量上传数量太少。本文按上传目录、上传限额、网络图片关闭、p 标签包裹、视觉显示优化、CSRF 与 XSS 加固六个维度逐一给出代码改造，覆盖 KindEditor 4.1.x 主流版本。 ## KindEditor 整体架构与改造前的准备 ## 核心目录结构 典型部署路径下 KindEditor 的目录长这样： kindeditor/ ├── kindeditor-all.js # 完整版 JS（开发版） ├── kindeditor-all-min.js # 完整版 JS（压缩版） ├── kindeditor.js # 核心 JS ├── plugins/ # 插件目录 │ ├── image/ # 单图上传插件 │ ├── multiimage/ # 多图批量上传 │ ├── filemanager/ # 文件管理器 │ └── ... ├── themes/ # 皮肤 ├── lang/ # 多语言 ├── php/ │ ├── upload_json.php # 单图与文件上传后端 │ ├── file_manager_json.php │ └── JSON.php └── jsp/ # JSP 后端（如不用 JSP 可删） 改造前先做一份完整备份，所有路径写改动备忘以便回滚。 ## 识别 KindEditor 实例的两种调用形态 KindEditor 的初始化有两种常见写法，决定后续改造代码改哪儿： 形态 A：完整富文本编辑器 KindEditor.create('#editor', { uploadJson: '/kindeditor/php/upload_json.php', fileManagerJson: '/kindeditor/php/file_manager_json.php', allowFileManager: true, items: ['source','|','undo','redo','|','image','multiimage','...'] }); 形态 B：单独调用图片上传弹窗（不带编辑器） var editor = KindEditor.editor({ uploadJson: '/kindeditor/php/upload_json.php', allowFileManager: true }); editor.loadPlugin('image', function() { editor.plugin.imageDialog({ showRemote: false, clickFn: function(url, title, width, height) { // 处理结果 } }); }); ## 关闭网络图片标签页 KindEditor 默认的图片上传弹窗有“本地上传”“网络图片”“图片空间”三个标签页。“网络图片”让用户输入任意 URL 直接插入页面，对站点有两个隐患： - 外链 (https://zhangwenbao.com/free-backlink-building-strategies.html)图片随时失效，正文图片显示成裂图。 - 第三方图床的隐私追踪 cookie 会跟着请求发送，触发用户的隐私警告。 关闭方法按调用形态分两种： ## 形态 B（单独图片上传） 在调用 imageDialog 时直接传参： editor.plugin.imageDialog({ showRemote: false, showLocal: true }); ## 形态 A（编辑器内的图片按钮） 编辑 plugins/image/image.js，找到内部对 imageDialog 的调用： self.plugin.imageDialog({ imageUrl : K(this.cmd.range.startContainer).attr('src'), clickFn : function(url, title, width, height, border, align) { // ... } }); 加上 showRemote: false： self.plugin.imageDialog({ showRemote: false, imageUrl : K(this.cmd.range.startContainer).attr('src'), clickFn : function(url, title, width, height, border, align) { // ... } }); 同样的改法对 multiimage.js 也适用——多图批量上传弹窗也有网络图片入口。 ## 批量上传：调整数量、单张大小、并发 ## 前端限额 编辑 plugins/multiimage/multiimage.js，定位到： KindEditor.plugin('multiimage', function(K) { var self = this, imageSizeLimit = K.undef(self.imageSizeLimit, '5MB'), imageUploadLimit = K.undef(self.imageUploadLimit, 20); ... }); 把默认 5MB / 20 张分别改大。生产里我常用的设置是 30MB / 200 张： var imageSizeLimit = K.undef(self.imageSizeLimit, '30MB'), imageUploadLimit = K.undef(self.imageUploadLimit, 200); 不建议直接改成 1000 张，浏览器一次拖入 1000 张图片会让 DOM 卡死，分批上传体验更好。 ## 后端限额（upload_json.php） 编辑 php/upload_json.php，定位： $max_size = 1000 * 1024; // 默认 1MB 改成与前端一致： $max_size = 30 * 1024 * 1024; // 30MB ## php.ini 三个关键参数 仅改前后端不够，PHP 本身有三道闸门，必须同步调整： upload_max_filesize = 30M post_max_size = 100M max_file_uploads = 200 max_execution_time = 300 memory_limit = 256M post_max_size 必须 ≥ 单文件大小 × 单次上传数量，否则一次性上传 50 张 5MB 图会触发 413 Request Entity Too Large。memory_limit 不够会让 PHP 在 GD 库处理图片时内存不足致命错误。 ## nginx 同步调整 nginx 默认 client_max_body_size 是 1MB，必须改： http { client_max_body_size 100m; client_body_timeout 300s; client_body_buffer_size 128k; } 这一项不改的话，nginx 会先于 PHP 拒绝请求，前端看到的是 413 而不是 PHP 的友好错误提示。 ## Apache 同步调整 .htaccess 里加： php_value upload_max_filesize 30M php_value post_max_size 100M php_value max_execution_time 300 php_value memory_limit 256M LimitRequestBody 104857600 ## 上传目录改造与按日期归档 ## 原始默认行为 upload_json.php 默认所有文件都上传到 attached/ 目录，时间长了会累积几万个文件在一个目录里，运维查找麻烦、ext4 文件系统单目录文件数太多会导致 ls 卡顿、备份增量同步也变慢。 ## 按日期归档的改法 编辑 php/upload_json.php，定位： // 文件保存目录路径 $save_path = $php_path . '../attached/'; // 文件保存目录URL $save_url = $base_url . '../attached/'; 改成按年月分目录： $year_month = date('Ym'); // 例如 202405 $save_path = $php_path . '../attached/' . $year_month . '/'; $save_url = $base_url . '../attached/' . $year_month . '/'; if (!file_exists($save_path)) { mkdir($save_path, 0755, true); } 0755 在多数生产环境下足够（owner=apache/nginx 用户写入，group/other 只读），不要用 0777。 ## 按业务模块进一步细分 如果你的站点有多个业务模块（比如商品图、文章图、用户头像走同一个 KindEditor），可以通过 GET/POST 参数传递 module 名做更细分类： $module = isset($_REQUEST['module']) ? preg_replace('/[^a-z0-9_]/i', '', $_REQUEST['module']) : 'default'; $save_path = $php_path . '../attached/' . $module . '/' . $year_month . '/'; $save_url = $base_url . '../attached/' . $module . '/' . $year_month . '/'; preg_replace 这一步是安全屏障，避免恶意构造的 module 名做目录穿越（比如 module=../../etc）。 ## 文件名重命名规则 原始 upload_json.php 用以下规则给文件改名： $new_file_name = date('YmdHis') . '_' . rand(10000, 99999) . '.' . $file_ext; 这个规则在并发场景下还有概率撞名（同一秒内两个用户都摇到 12345）。建议改成 UUID 或加上原始文件名 hash： $new_file_name = date('YmdHis') . '_' . substr(md5(uniqid(mt_rand(), true)), 0, 12) . '.' . $file_ext; UUID 部分 12 位 hex 共 16^12 ≈ 281 万亿组合，撞名概率近乎为零。 ## 图片自动包 p 标签的处理 ## 问题描述 KindEditor 默认在图片插入到正文后会自动包一层


，原意是给用户留下后续输入文字的位置。但当用户连续插入多张图时，每张图前后都会出现一个空 p，正文渲染时多出大量空行，移动端尤其难看。 ## 方案 A：保留 p 但去掉空 p 编辑 kindeditor.js，找到这一段： html = html.replace(/(<(?:p|p\s[^>]*)>)\s*(<\/p>)/ig, '$1
$2'); 改成： html = html.replace(/(<(?:p|p\s[^>]*)>)\s*(<\/p>)/ig, ''); 原代码保留空 p 并填一个 br；新代码直接删除空 p。空段落消失，多图连排布局紧凑。 ## 方案 B：给所有图片单独包 p 这一改法适合“每张图一个段落”的版式（旅行游记、产品多图展示）。在 kindeditor.js 的 insertimage 函数里： insertimage : function() { var self = this; self.exec('insertimage', ...); } 改成把 img 包在 p 里再 exec： insertimage : function(url, title, width, height, border, align) { var img = '

' + title + '

'; this.exec('inserthtml', img); } ## 方案 C：清理后端正文 有些情况编辑器输出已经写库，再去前端清空 p 不现实。这时候改 PHP 后端，在保存前清理： function clean_editor_html($html) { // 删除空段落 $html = preg_replace('/]*>\s*()?\s*<\/p>/i', '', $html); // 合并多余空白 $html = preg_replace('/\s{2,}/', ' ', $html); return $html; } $content = clean_editor_html($_POST['content']); ## 视觉显示优化（编辑器内） ## 问题：富文本所见即所得不像 KindEditor 在 iframe 内渲染正文，自带 css 让段落紧贴、图片溢出、光标显示不清。这与最终前台展示效果差距大，作者不知道发出去会变成什么样。 ## 定位 _getInitHtml 函数 kindeditor.js 内 _getInitHtml 函数返回 iframe 内的初始 HTML，包含 head 里的 style 块。原始 style 大概长这样： 'body {' + ' font:12px/1.5 \'Microsoft YaHei\',\'simsun\',\'Helvetica\',sans-serif;' + ' margin:8px;' + '}' + 'p {margin:5px 0;}' + 'img {border:0;}' ## 对照前台样式调整 建议把 iframe 内的 css 与前台正文 css 大致对齐。我项目里常用的调整： 'body {' + ' font:16px/1.7 \'Microsoft YaHei\',\'PingFang SC\',sans-serif;' + ' margin:16px;' + ' color: #333;' + ' background: #fff;' + '}' + 'p {margin:12px 0; line-height:1.7;}' + 'p img {max-width:100%; height:auto; border-radius:4px;}' + 'img {border:0; padding:0 4px;}' + 'h2 {font-size:22px; margin-top:24px; border-left:4px solid #4a90e2; padding-left:10px;}' + 'h3 {font-size:18px; margin-top:18px; color:#4a90e2;}' + 'a {color:#4a90e2; text-decoration:none;}' + 'pre {background:#f4f4f4; padding:12px; border-radius:4px; overflow-x:auto;}' ## 安全加固：CSRF / XSS / 文件类型验证 ## upload_json.php 的默认安全漏洞 KindEditor 4.1.x 自带的 upload_json.php 有这些已知问题： - 没有 CSRF token 校验，任何域名都能往后端 post 文件。 - file_manager_json.php 没有权限校验，未登录用户能列出 attached/ 目录所有文件。 - 白名单扩展名靠后缀判断，能被双扩展名（pic.jpg.php）绕过。 - 未做 MIME 真实类型检查，能用伪造 header 上传 PHP 文件。 ## 加 CSRF token upload_json.php 顶部加： session_start(); if (empty($_REQUEST['_csrf']) || $_REQUEST['_csrf'] !== $_SESSION['kindeditor_csrf']) { header('Content-Type: application/json'); echo json_encode(['error' => 1, 'message' => 'CSRF check failed']); exit; } 前端调用 KindEditor 时把 token 传过去： KindEditor.create('#editor', { uploadJson: '/kindeditor/php/upload_json.php?_csrf=' }); ## 双扩展名拦截 原代码： $ext = strtolower(strrchr($file_name, '.')); $ext = trim($ext, '.'); if (!in_array($ext, $ext_arr[$dir_name])) { ... } 双扩展名（image.jpg.php）会被识别成 .php 拒绝，但 image.php.jpg 会被识别成 .jpg 通过——实际是 PHP 文件。修复：检查全部扩展名： $file_parts = explode('.', $file_name); $dangerous = ['php', 'phtml', 'php3', 'php4', 'php5', 'pht', 'asp', 'aspx', 'jsp', 'cer', 'cdx', 'asa']; foreach ($file_parts as $part) { if (in_array(strtolower($part), $dangerous)) { die(json_encode(['error' => 1, 'message' => 'Dangerous extension'])); } } ## MIME 真实类型检查 $finfo = new finfo(FILEINFO_MIME_TYPE); $mime = $finfo->file($_FILES['imgFile']['tmp_name']); $allowed_mimes = ['image/jpeg', 'image/png', 'image/gif', 'image/webp']; if (!in_array($mime, $allowed_mimes)) { die(json_encode(['error' => 1, 'message' => 'Invalid MIME type'])); } ## file_manager_json.php 加登录验证 file_manager_json.php 头部加： session_start(); if (empty($_SESSION['user_id']) || $_SESSION['user_role'] !== 'admin') { header('HTTP/1.1 403 Forbidden'); exit; } 这一项至关重要——之前发现过黑产专门扫描 KindEditor 的 file_manager_json.php，匿名拉走整个 attached/ 目录的图片清单做爬虫源。 ## 多语言、皮肤、自定义工具栏的扩展 ## 切换中文界面 KindEditor.create('#editor', { langType: 'zh-CN', themeType: 'default' }); 同时确保 lang/zh-CN.js 文件存在。如果想自定义某些菜单文案，直接编辑这个文件，热更新无需重启。 ## 定制工具栏按钮顺序 KindEditor.create('#editor', { items: [ 'source', '|', 'undo', 'redo', '|', 'cut', 'copy', 'paste', 'plainpaste', 'wordpaste', '|', 'justifyleft', 'justifycenter', 'justifyright', '|', 'insertorderedlist', 'insertunorderedlist', '|', 'fontname', 'fontsize', '|', 'forecolor', 'hilitecolor', 'bold', 'italic', 'underline', '|', 'image', 'multiimage', 'flash', 'media', '|', 'table', 'hr', 'emoticons', '|', 'link', 'unlink' ] }); 移除掉“网络图片”“图片空间”“flash”等不常用功能，工具栏更整洁，同时降低被滥用的风险。 ## 与 WordPress / Discuz / DedeCMS 的具体集成 ## WordPress 后台用 KindEditor 替换 TinyMCE 不建议这么做。WordPress 5.0 之后默认编辑器是 Gutenberg block editor，KindEditor 是 2010 年代设计的传统富文本，强行替换会丢失所有 block 功能。如果非要用，参考 wp-kindeditor 这类老旧插件。 ## DedeCMS 把内置编辑器换成 KindEditor 编辑 include/inc/inc_fun_funAdmin.php 找到 ShowEditor 函数，替换 fck/ueditor 的调用为 KindEditor。具体步骤涉及 JS path 调整、上传后端对接 dedeAjax，非常繁琐，仅在二次开发项目里值得做。 ## Discuz 集成 Discuz 默认编辑器是自家的 ckeditor 改造版。强行替换会破坏帖子 BBCode 解析。建议只在自定义页面（比如插件后台）里用 KindEditor，原帖编辑器保留 Discuz 默认。 ## 实战故障排查 ## 故障 1：图片上传成功但前台显示裂图 查后端返回的 JSON： {"error":0,"url":"/kindeditor/attached/202405/test.jpg"} 看 url 字段——如果是相对路径但你的页面在子目录，会拼错。修复 upload_json.php 让 url 始终返回绝对路径： $file_url = ($_SERVER['HTTPS'] === 'on' ? 'https' : 'http') . '://' . $_SERVER['HTTP_HOST'] . $save_url . $new_file_name; echo json_encode(['error' => 0, 'url' => $file_url]); ## 故障 2：上传 50 张图后浏览器卡死 一次性把所有图加入 DOM 让浏览器渲染压力爆炸。改造 multiimage.js 让它分批 5 张一次插入： function batchInsert(files, idx) { if (idx >= files.length) return; var batch = files.slice(idx, idx + 5); insertImages(batch); setTimeout(function() { batchInsert(files, idx + 5); }, 200); } ## 故障 3：粘贴 Word 文档进编辑器后样式爆炸 Word 粘贴的 HTML 里夹杂了大量 mso-* 内联样式与命名空间。KindEditor 自带 wordpaste 按钮可以清理，但默认未启用。在 items 工具栏配置里把 wordpaste 加进去，并设置 pasteType 配置： KindEditor.create('#editor', { pasteType: 1, // 0=禁止粘贴, 1=纯文本粘贴, 2=允许 HTML 粘贴 afterCreate: function() { this.cmd.range.addRange(/* ... */); } }); ## 故障 4：移动端编辑器无法拖拽图片上传 KindEditor 4.1.x 没有针对移动端优化，多图上传依赖 input[type=file][multiple]，移动浏览器对此支持差。建议移动端改用 wangEditor 或 Quill 这类现代编辑器。 ## 故障 5：上传后图片自动旋转 90° iPhone 拍的横屏照片 EXIF 里有旋转信息，浏览器渲染前会按 EXIF 旋转。后端用 GD 重新保存时丢失 EXIF，前端再加载就“转向不对”。修复：上传时同步处理 EXIF： $exif = exif_read_data($_FILES['imgFile']['tmp_name']); if (!empty($exif['Orientation'])) { $img = imagecreatefromjpeg($_FILES['imgFile']['tmp_name']); switch ($exif['Orientation']) { case 3: $img = imagerotate($img, 180, 0); break; case 6: $img = imagerotate($img, -90, 0); break; case 8: $img = imagerotate($img, 90, 0); break; } imagejpeg($img, $save_path . $new_file_name, 90); } ## 常见问题解答 ## KindEditor 还在维护吗？ 原作者 Roddy 自 2014 年后已不再活跃维护。最后一个版本是 4.1.12（2017 年）。如果是新项目，建议选择 wangEditor、CKEditor 5、TinyMCE 6、Quill 这类有持续更新的现代编辑器。如果是老项目里已经用了 KindEditor，本文的改造方案足够覆盖大多数运营需求。 ## upload_json.php 改了之后多图上传仍然走老目录？ 多图上传走的是同一个 upload_json.php，但路径计算可能因为 PHP_SELF 不同而走到不同的相对路径分支。建议改造时把所有 save_path/save_url 计算都改用绝对路径，避免分支不一致。 ## 批量上传 200 张图速度很慢怎么办？ 瓶颈通常在后端 GD 库处理图片。三个加速：上传时不做缩略图（异步交给 cron）；用 Imagick 替代 GD（处理速度快 30%）；前端先压缩再上传（用 browser-image-compression 这类 JS 库）。 ## KindEditor 与 fileinput.js 哪个上传体验更好？ fileinput.js 的 UI 更现代，支持拖拽、进度条、缩略图预览，移动端友好。但它只是单纯文件上传组件，不带富文本编辑功能。如果业务只是“上传图片”可以用 fileinput.js 替代 KindEditor 的 multiimage 模块。 ## 能否把 KindEditor 切换成 markdown 编辑器？ 切换成本接近重写。建议直接用 SimpleMDE、EasyMDE、Editor.md 这种专业 markdown 编辑器，KindEditor 强行支持 markdown 体验差。 ## file_manager_json.php 不加权限校验有多严重？ 非常严重。曾遇到过实战案例：黑产扫到未保护的 file_manager_json.php，遍历整个 attached/ 目录找用户上传的身份证、合同截图，扒走数据库。所有线上 KindEditor 部署都必须加管理员权限校验。 ## 升级 PHP 到 7.4+ 后上传报错？ KindEditor 4.1.12 的 PHP 后端用了一些 PHP 7+ 移除的写法（each() 函数、__autoload）。需要手动改成 foreach、spl_autoload_register 替代。或者干脆把 upload_json.php 重写成现代 PHP 版本（200 行内）。 ## 多个站点共用一个 KindEditor 部署可行吗？ 可行，但 upload_json.php 必须按 Host 区分上传目录，否则站点 A 上传的图能被站点 B 访问。在 upload_json.php 顶部加：$host_dir = preg_replace('/[^a-z0-9_.-]/i', '_', $_SERVER['HTTP_HOST']); $save_path .= $host_dir . '/'; ## KindEditor 的 SVG 上传支持吗？ 默认扩展名白名单不含 svg。手动加上后要注意：SVG 文件可以包含