1. 先搞清楚政务CMS里的智能填充到底要解决什么1.1 三个让人头疼的真实场景做政务CMS的朋友应该都有这种感觉编辑器本身能用就行真正麻烦的永远是内容从哪里来、最后要变成什么。而KindEditor恰恰又是国内政务CMS里存量最大的编辑器之一从老牌PHP站群系统到后来Java重写的门户平台工具栏上那个熟悉的K标几乎成了标配。新需求一来大家第一反应往往是要不要换编辑器但换编辑器在政务场景里几乎是最不现实的选项存量模板、历史数据、用户习惯全都要推倒重来。我最近连续在两个项目里遇到同一个诉求就是标题里这个多格式文档智能填充。拆开看其实对应着三个扎心的日常场景。第一个场景是公告公示的重复誊写。业务科室在审批系统里录完项目名称、建设单位、审批文号、公示期限这些结构化数据再到CMS后台重新抄一遍。十几二十个字段复制粘贴加手动排版一小时能做完一篇就算手快。更麻烦的是同样一篇公示可能要在门户网站发HTML版、给上级部门报Word版、归档还要PDF版每发一个渠道就等于重新做一遍。第二个场景是公文格式的混乱。同一个单位的通知张三从Word复制过来是宋体五号李四带过来的是仿宋三号还有人直接把Word文件里的xml垃圾代码一起粘进来前端渲染出来段落间距五花八门。政务内容对格式规范是有明确要求的标题用什么字体、正文几号字、落款怎么对齐都有套路但纯靠编辑器里肉眼排版十个人能排出十种效果。第三个场景是模板数据的脱节。很多CMS的文档模板其实就是把样例文字复制一份再让人手动改内容。模板里没有任何数据映射关系系统也不知道这里应该填什么本质还是人肉填充。稍微进阶一点的做法是做个表单界面填完再拼接到文档里但表单和编辑器是两张皮数据的格式校验、字段联动、回显编辑全都处于裸奔状态。1.2 智能填充不是模板套壳是一条数据流水线智能填充这个词看着玄乎实际拆分下来就是一条数据流水线从业务系统或数据库取出结构化数据按照模板里约定的占位符规则把数据映射到文档中的指定区域最后再按需要输出成HTML、Word、PDF等不同格式。整个过程用户只在编辑器界面操作不需要中途切换到Excel、Word或者其他转换工具。我习惯把这条流水线分成四个环节缺一个都会在后期返工数据接入业务系统提供查询接口返回JSON格式的结构化数据字段命名规范、类型明确这是后面所有环节的地基。模板绑定每个文档模板声明自己需要哪些占位符比如${projectName}、${approvalNo}并处理好这些字段的展示样式。智能回填前端拿到数据后根据占位符规则把值替换进去。替换不是无脑的字符串拼接要处理转义、去脚本、特殊字符、空值兜底。多格式输出编辑器里完成的是HTML内容要把HTML稳定地转成Word和PDF而且排版尽量不乱。这四个环节里真正花时间的是后两个尤其是多格式输出政务环境里经常要跟公文排版规范较劲。后面我会单独展开。1.3 为什么在KindEditor上扩展而不是换掉它很多同行问过这个问题既然KindEditor这么多年没大更新为什么不干脆用TinyMCE或者国产的富文本编辑器我的答案很直接政务CMS的改造从来不是编辑器一个组件的事。首先是存量负担。一个用了八九年的CMS里可能有几千篇历史文章都是用KindEditor编辑和存储的。换编辑器意味着历史内容的HTML解析规则可能变化那种带span style...嵌套、p段落规范的内容新编辑器未必解析得完全一致。页面一旦出现历史文章批量显示异常这个责任谁都不好背。其次是兼容性要求。政务内网环境里Windows 7配IE11到现在都不稀奇更不用说各种国产浏览器。KindEditor的老代码本身就是为这种环境生的扩展它不用引入新的构建体系不用强迫用户换浏览器。这一点在政企项目里是实打实的硬约束。第三是插件机制。KindEditor的插件注册方式是KindEditor.plugin(name, fn)结构清晰、没有框架绑架加一个自定义工具栏按钮只需要写一个JS文件再把插件名灌进items配置里。这正好契合我们最小侵入扩展的思路。所以结论很明确不是KindEditor最好而是它最符合政务CMS现状。扩展它是在现有约束下性价比最高的路径。2. 方案设计插件、模板、转换三层怎么搭2.1 整体架构与数据流整个扩展方案我分成三层前端插件层、后端服务层、转换输出层。为了保证后面写代码不跑偏先把数据流理清楚。用户在编辑器工具栏点击智能填充按钮前端插件打开一个对话框对话框里做两件事选择文档模板、配置数据来源。数据来源有两种典型形态一种是直接输入业务流水号或项目编号由后端接口去关联数据另一种是通过查询条件筛选数据比如按部门、按时间范围拉一个待办公文列表选中一条再填充。我建议初期只做第一种交互最简单也最容易梳理数据权限。选定模板和数据后前端发请求到后端后端返回JSON数据。前端拿到数据后用模板填充器把编辑器里的占位符替换成实际内容替换过程中做HTML转义和安全过滤。填充完成后用户可以直接微调、走CMS已有的内容审批和发布流程。发布环节如果需要Word或PDF版本再调用转换服务把编辑器里的HTML内容转成目标格式。后端服务层需要三块接口模板管理接口负责模板的增删改查、占位符提取、分类维护数据查询接口负责对接业务系统返回填数所需的JSON转换接口负责接收HTML文本和转换参数返回生成的文件下载地址。如果有条件这三块建议做成独立的服务模块方便多个CMS站点共用。2.2 占位符规范机器能替换、人能看懂的约定模板填充最恨的就是占位符规则混乱。有的模板用{name}有的用{{name}}有的用[name]解析器写起来像在猜谜。我在项目里固定了一套规则用到现在没出过歧义。单值字段用${fieldName}表示嵌套数据用点号比如${project.name}。列表循环用{{#listName}}开头、{{/listName}}结尾中间包住一段包含单值占位符的HTML块。这样设计的好处是模板写出来像普通正文非技术人员看几眼也能理解哪里会被替换成什么。空值兜底也要在规范里定义清楚。我约定默认空值替换成空字符串但模板可以显式给出兜底文案${approvalNo|待补充}竖线后面就是空值时的显示内容。这种细节看起来不起眼实际用起来特别重要不然数据源漏了一个字段文档里出现一大片空白用户根本不知道是自己选错了数据还是接口漏了字段。还要考虑字面量冲突。如果文档正文里真的要出现剂量为${mg}这种文字不想被替换怎么办我留了一个转义写法\${mg}填充器先把转义符暂时替换成占位标记等全部替换完再还原成字面量${mg}。这个坑是我上线后一个月才补上的有次一个药品采购公示里出现了${mg}被解析器当成字段替换成空值差点造成公示内容缺失。2.3 模板库与数据源如何组织模板不能只存一份HTML字符串那样占位符信息全丢了。我在数据库里设计了一张模板表和一张字段映射表模板表存正文内容、分类、适用部门、状态字段映射表存每个模板用到的占位符列表和对应的数据源路径。这样用户选择模板时系统能提前校验当前数据源能不能填满这个模板缺字段直接提示而不是等填充完才发现一堆空值。数据源的组织也要分层。同一个业务系统可能有多个接口返回不同的数据形态有的返回单对象有的返回列表。我建议后端封装一层数据源适配器对外暴露统一的查询语义按业务主键查单条、按条件查列表。这样模板里写的数据路径就是相对稳定的底层业务表结构变化时只需要改适配器不用动模板和前端逻辑。3. 实操手写一个KindEditor的智能填充插件3.1 插件骨架注册工具栏按钮KindEditor的插件扩展其实挺简单核心就是KindEditor.plugin(name, function(K){...})。我在项目里叫它docfill注册之后只要在编辑器初始化时把docfill加进items数组工具栏就会出现对应按钮。KindEditor.plugin(docfill, function(K) { var self this; var name docfill; self.clickToolbar(name, function() { self.plugin.docfill.openDialog(); }); });初始化编辑器时把插件名加进itemsK.create(#content, { width: 100%, height: 520px, items: [ source, |, undo, redo, |, docfill, |, bold, italic, forecolor, |, fullscreen ], afterCreate: function() { // 编辑器创建完成后可以预加载模板列表 } });这里有个容易忽略的点clickToolbar绑定的是工具栏点击事件但如果插件名没有出现在items里按钮不会渲染。所以排查按钮为什么没出来的时候先看items配置别一股脑怀疑插件文件加载问题。对话框我直接用KindEditor自带的K.dialog不引第三方弹窗库。这样风格统一也不引入额外依赖兼容性最好。self.plugin.docfill.openDialog function() { var dialog K.dialog({ width: 720, height: 520, title: 多格式文档智能填充, body: div iddocfill-panel div classdocfill-row模板select iddocfill-template/select/div div classdocfill-row业务编号input iddocfill-bizid typetext placeholder输入业务流水号或项目编号 //div div classdocfill-row iddocfill-preview/div /div, closeBtn: { name: 取消, click: function() { dialog.remove(); } }, yesBtn: { name: 填充文档, click: function() { var tplId K(#docfill-template).val(); var bizId K(#docfill-bizid).val(); if (!tplId || !bizId) { alert(请选择模板并输入业务编号); return; } // 1. 请求模板内容 // 2. 请求业务数据 // 3. 执行填充逻辑 // 4. 结果写回编辑器 // 5. 关闭对话框 dialog.remove(); } } }); };我在多个项目里一直用这套对话框写法稳定、好调试还能兼容IE11下的显示。3.2 数据回填模板加载、数据请求与填充逻辑填充的核心逻辑是一段正则替换加递归。模板内容拿回来之后先做列表循环块的处理再做单值字段的替换。列表处理用递归是因为循环块内部可能还会嵌套其他字段甚至子循环。function fillTemplate(content, data) { // 先处理列表循环块 {{#list}} ... {{/list}} content content.replace(/\{\{#(\w)\}\}([\s\S]*?)\{\{\/\1\}\}/g, function(match, listName, block) { var items data[listName] || []; var result []; for (var i 0; i items.length; i) { result.push(fillTemplate(block, items[i])); } return result.join(); }); // 再处理单值字段 ${fieldName} 和 ${fieldName|兜底文案} content content.replace(/\$\{([^}])\}/g, function(match, expr) { var parts expr.split(|); var path parts[0].trim(); var fallback parts.length 1 ? parts[1] : ; // 将转义的 \${ 还原这里预先用哨兵标记处理过了 var value getByPath(data, path); if (value undefined || value null || value ) { return escapeHtml(fallback); } return escapeHtml(value); }); return content; } function getByPath(obj, path) { var keys path.split(.); var cur obj; for (var i 0; i keys.length; i) { if (cur null) return undefined; cur cur[keys[i]]; } return cur; } function escapeHtml(str) { return String(str) .replace(//g, amp;) .replace(//g, lt;) .replace(//g, gt;) .replace(//g, quot;) .replace(//g, #39;); }填充完成后写回编辑器。这里有个关键细节如果是一次性整体替换用editor.html(html)如果只是在光标处插入一段内容必须用editor.insertHtml(html)。很多新手把这两个混着用结果要么光标位置丢得莫名其妙要么整个文档被覆盖。写回之后还要记得editor.sync()把编辑器内容同步回原始textarea否则表单提交时后台拿到的是空值这个坑我踩过不止一次。3.3 多格式输出服务端转换链路编辑器里的内容是HTML要输出Word和PDF我试过几种方案。最省事的是前端直接调浏览器打印生成PDF但政务系统里打印设置五花八门页眉页脚、边距根本控制不住效果很难统一。后来我把转换收口到服务端统一用LibreOffice headless模式。soffice --headless --convert-to pdf --outdir /data/docfill/out /data/docfill/tmp/source.htmlJava侧这样调用ProcessBuilder pb new ProcessBuilder( soffice, --headless, --convert-to, pdf, --outdir, outDir, srcPath ); Process p pb.start(); int code p.waitFor();转Word我同样用LibreOffice转成docx或者odt再另存。这样一圈下来格式统一性比前端打印强太多。但服务端转换有两个前置条件必须处理好一是服务器必须安装中文字体否则中文全变豆腐块二是临时HTML文件必须带meta charsetutf-8声明不然会出现中文乱码。这两个问题我在下一节踩坑实录里详细展开。如果你的环境不允许装LibreOffice也可以考虑用Aspose.Words这类商业组件转换质量更好但是按服务器授权采购流程要提前走。政务项目我建议先确认部署环境的软件安装策略再定技术方案否则方案写得再漂亮到了现场装不上都是白搭。3.4 与CMS用户权限和审批流程整合插件只是工具真正落地的坑在流程整合。模板不是所有用户都能用的不同部门能看到的模板集合同样要做隔离。我在后端模板接口里接入了CMS的统一权限体系按角色返回可见模板列表。这一步不做等上线之后某个部门用了另一个部门的内部模板那才是真的麻烦。填充操作还要留痕。每次填充我都在后端记一条操作日志内容包括操作用户、IP、模板ID、业务数据主键、填充时间。更重要的是填充完成后文档里要嵌入一份数据快照。为什么做快照因为业务系统的数据是活的今天填进去的项目金额明天可能被修改如果文档最后被归档读者看到的却成了后来改过的数据追责时说不清楚。我的做法是把填充时的数据JSON序列化后存到附件的扩展字段里谁有疑问直接比对。整个流程走完之后文档回到CMS的草稿箱走原有的内容审批和发布流程不在编辑器这层单独搞一套发布逻辑。4. 踩坑实录这些坑比功能本身更值得记录4.1 编辑器内容与iframe不同步KindEditor的编辑区是iframe用户看到的内容是iframe里body的innerHTML。程序往编辑器写入内容或提交表单时最容易出问题的是同步。典型症状是填充完成后文章在编辑器里看着没问题一发布出去正文是空的。原因就是editor.html(html)只改了iframe里的body没同步回原来的textarea。KindEditor有个editor.sync()方法把所有编辑区内容写回textarea必须在填充逻辑和表单提交事件里都调用。另外一个和同步相关的坑editor.html(html)会把内容完全重置同时清空撤销历史。用户如果不满一次填充结果按CtrlZ是撤不回来的。所以我在填充前会先editor.saveRange()存一下选中区域填充后用editor.restoreRange()恢复并且对需要局部插入的场景优先用insertHtml而不是整体html()。// 正确的填充写回姿势 editor.saveRange(); editor.html(newHtml); editor.restoreRange(); editor.sync();4.2 特殊字符、XSS与公文安全政务系统的数据来自多个业务系统填充数据绝对不能直接拼进HTML。我曾经在测试环境遇到过一条包含scriptalert(1)/script的数据填进模板后编辑器里弹了窗。虽然内网系统风险相对可控但等保测评如果抓到这个整改单是少不了的。我的做法是双层过滤。前端填充时用escapeHtml把数据里的HTML特殊字符转义保证进入编辑器内容区的只是纯文本。后端在保存接口再过滤一遍用白名单方式只允许p、span、br、table这类常规标签其余标签和事件属性全部剥掉。两层都做不是为了性能而是为了防住绕过前端直发后端的情况。还有一类特殊字符是百分号、花括号和反斜杠。数据内容里如果带了${xxx}这种串填充时会被当成占位符二次解析造成内容错乱。我在填充器里做了一个哨兵替换先把所有\${替换成一个不可能出现在正文里的标记单值替换完成后再把标记还原为${字面量。这个逻辑必须放在列表循环递归处理之前顺序反了照样出错。4.3 中文乱码与字体缺失服务端用LibreOffice转换中文文档最经典的两个问题一个是中文变乱码一个是中文字体全部变成方块。乱码十有八九是临时HTML文件没声明字符集。我用Java写临时文件时默认是平台编码在Linux服务器上大多UTF-8没问题但有些政务服务器设置过GBK环境变量。稳妥做法是显式写文件时用OutputStreamWriter指定UTF-8并且在HTML的head里加上meta charsetutf-8两边统一。字体缺失更隐蔽。有次我在跳板机上转换正常放到正式服务器上PDF里中文全变成空心方块排查了半天才发现正式服务器是最小化安装根本没装中文字体。解决方案是给服务器安装CJK字体包比如fonts-noto-cjk或者fonts-arphic-uming装完重启LibreOffice进程让它重新加载字体缓存。如果公文对字体有硬性要求比如标题要小标宋体、正文要仿宋还得把对应字体文件放到服务器字体目录并注册。这里要提醒一句商业字体的授权问题必须提前确认很多政务项目直接用开源字体替代或者采购字体授权。4.4 老旧浏器兼容IE11与国产浏览器KindEditor的存量用户很多跑在IE11甚至更老的内核上所以我的插件JS刻意保持了老语法用var、用function、不用箭头函数、不用Promise、不用fetch网络请求全部走K.ajax或者jQuery.ajax。这在2024年听起来像是考古但真在政务内网环境里见过一次用户点填充按钮后白屏就是因为new了一个Map对象IE不认识。调试建议装一台干净的Windows 7虚拟机只装IE11把插件完整跑一遍。Chrome上没问题不代表IE上没问题尤其要注意正则表达式、字符串的startsWith、includes这些方法IE里统统没有。4.5 大数据量填充导致页面卡死有的模板带大表格比如项目清单、资金明细一填就是几十上百行。如果用editor.html(html)整体替换大文档浏览器渲染iframe内部DOM会有明显卡顿如果在循环里每次insertHtml追加一行那性能更是灾难。我优化后的做法是在循环拼接阶段把每行HTML推入数组最后join()一次性组装完成再调用editor.html整体写回。数组push加join的性能远好于字符串连续拼接这个优化在数据量大时体感特别明显。另外填充期间给对话框加一个正在填充的遮罩提示避免用户重复点击造成编辑器状态错乱。5. 上线之后权限、审计与后续扩展5.1 操作留痕与数据权限边界功能上线只是开始后面三件事一件比一件重要。第一件是数据权限。用户在填充框里输入业务编号后端查询数据时必须校验这个用户有没有权限看这条业务数据。这个校验绝对不能只靠前端隐藏选项后端接口要拿着用户身份信息跟CMS权限中心对一遍。我遇到过数据接口直接按主键查数据、不带权限校验的情况理论上任何人知道编号就能拉出来这在政务环境里属于事故级别的漏洞。第二件是留痕。前面说过填充日志和数据快照这里再强调一个细节日志里除了记录谁在什么时候填了什么还要记录模板版本号。模板是会改的同一个模板改了三版之后追溯历史文档是用哪版模板生成的就必须依赖版本号。5.2 模板版本与占位符变更管理政务系统的数据字段变化比你想象的频繁。去年叫项目类型今年叫事项类型模板里的占位符就得跟着改。如果不做版本管理字段一变动所有存量模板瞬间失效填充出来的文档全是空值。我的做法是模板每次修改都生成新版本占位符列表一并存档。填充器运行前会检查当前模板的字段列表是否都能在数据源里找到找不到的字段列出明细用户可以选择忽略或者换数据源。这样做的好处是把结果坏了才发现提前到动作之前就预警体验差别很大。5.3 扩展空间OFD、签章与审批流对接这套框架搭好之后后面加功能都顺了。现在政务电子文件越来越多要求OFD格式在我们这套架构里只需要在转换服务层增加一个OFD转换器前端逻辑完全不用动。电子签章同理转换完成后的文件去调用签章服务本质上是在转换输出链路末尾接一个处理器。再往后扩可以把智能填充做成独立的微服务同时服务门户CMS、OA系统、行政审批平台模板和数据源统一管理避免每个系统各做一套、模板规则越搞越乱。这个方向是我目前看到的比较靠谱的落地演进路径。我个人在实际项目里最深刻的体会是KindEditor扩展本身不难难的是你愿不愿意把模板规范、数据适配、转换链路、权限审计这些脏活累活一次性想清楚。这个插件我前后迭代了三版才稳定下来第一版只做了字符串替换第二版加了列表循环和转义第三版才把模板版本和数据快照补上。如果你也在做类似的功能建议一开始就把模板版本和数据快照纳入设计别等上线之后被业务方追着补。最后再分享一个小技巧在模板预览区放一个调试填充按钮专门输出当前模板所有占位符的实际解析结果这个排查工具在整个生命周期里都非常好用。 
长河君 · 2026/10/4 18:53:48 · 阅读 1.2k 基于KindEditor的政务CMS多格式文档智能填充插件实战
1. 先搞清楚政务CMS里的智能填充到底要解决什么1.1 三个让人头疼的真实场景做政务CMS的朋友应该都有这种感觉编辑器本身能用就行真正麻烦的永远是内容从哪里来、最后要变成什么。而KindEditor恰恰又是国内政务CMS里存量最大的编辑器之一从老牌PHP站群系统到后来Java重写的门户平台工具栏上那个熟悉的K标几乎成了标配。新需求一来大家第一反应往往是要不要换编辑器但换编辑器在政务场景里几乎是最不现实的选项存量模板、历史数据、用户习惯全都要推倒重来。我最近连续在两个项目里遇到同一个诉求就是标题里这个多格式文档智能填充。拆开看其实对应着三个扎心的日常场景。第一个场景是公告公示的重复誊写。业务科室在审批系统里录完项目名称、建设单位、审批文号、公示期限这些结构化数据再到CMS后台重新抄一遍。十几二十个字段复制粘贴加手动排版一小时能做完一篇就算手快。更麻烦的是同样一篇公示可能要在门户网站发HTML版、给上级部门报Word版、归档还要PDF版每发一个渠道就等于重新做一遍。第二个场景是公文格式的混乱。同一个单位的通知张三从Word复制过来是宋体五号李四带过来的是仿宋三号还有人直接把Word文件里的xml垃圾代码一起粘进来前端渲染出来段落间距五花八门。政务内容对格式规范是有明确要求的标题用什么字体、正文几号字、落款怎么对齐都有套路但纯靠编辑器里肉眼排版十个人能排出十种效果。第三个场景是模板数据的脱节。很多CMS的文档模板其实就是把样例文字复制一份再让人手动改内容。模板里没有任何数据映射关系系统也不知道这里应该填什么本质还是人肉填充。稍微进阶一点的做法是做个表单界面填完再拼接到文档里但表单和编辑器是两张皮数据的格式校验、字段联动、回显编辑全都处于裸奔状态。1.2 智能填充不是模板套壳是一条数据流水线智能填充这个词看着玄乎实际拆分下来就是一条数据流水线从业务系统或数据库取出结构化数据按照模板里约定的占位符规则把数据映射到文档中的指定区域最后再按需要输出成HTML、Word、PDF等不同格式。整个过程用户只在编辑器界面操作不需要中途切换到Excel、Word或者其他转换工具。我习惯把这条流水线分成四个环节缺一个都会在后期返工数据接入业务系统提供查询接口返回JSON格式的结构化数据字段命名规范、类型明确这是后面所有环节的地基。模板绑定每个文档模板声明自己需要哪些占位符比如${projectName}、${approvalNo}并处理好这些字段的展示样式。智能回填前端拿到数据后根据占位符规则把值替换进去。替换不是无脑的字符串拼接要处理转义、去脚本、特殊字符、空值兜底。多格式输出编辑器里完成的是HTML内容要把HTML稳定地转成Word和PDF而且排版尽量不乱。这四个环节里真正花时间的是后两个尤其是多格式输出政务环境里经常要跟公文排版规范较劲。后面我会单独展开。1.3 为什么在KindEditor上扩展而不是换掉它很多同行问过这个问题既然KindEditor这么多年没大更新为什么不干脆用TinyMCE或者国产的富文本编辑器我的答案很直接政务CMS的改造从来不是编辑器一个组件的事。首先是存量负担。一个用了八九年的CMS里可能有几千篇历史文章都是用KindEditor编辑和存储的。换编辑器意味着历史内容的HTML解析规则可能变化那种带span style...嵌套、p段落规范的内容新编辑器未必解析得完全一致。页面一旦出现历史文章批量显示异常这个责任谁都不好背。其次是兼容性要求。政务内网环境里Windows 7配IE11到现在都不稀奇更不用说各种国产浏览器。KindEditor的老代码本身就是为这种环境生的扩展它不用引入新的构建体系不用强迫用户换浏览器。这一点在政企项目里是实打实的硬约束。第三是插件机制。KindEditor的插件注册方式是KindEditor.plugin(name, fn)结构清晰、没有框架绑架加一个自定义工具栏按钮只需要写一个JS文件再把插件名灌进items配置里。这正好契合我们最小侵入扩展的思路。所以结论很明确不是KindEditor最好而是它最符合政务CMS现状。扩展它是在现有约束下性价比最高的路径。2. 方案设计插件、模板、转换三层怎么搭2.1 整体架构与数据流整个扩展方案我分成三层前端插件层、后端服务层、转换输出层。为了保证后面写代码不跑偏先把数据流理清楚。用户在编辑器工具栏点击智能填充按钮前端插件打开一个对话框对话框里做两件事选择文档模板、配置数据来源。数据来源有两种典型形态一种是直接输入业务流水号或项目编号由后端接口去关联数据另一种是通过查询条件筛选数据比如按部门、按时间范围拉一个待办公文列表选中一条再填充。我建议初期只做第一种交互最简单也最容易梳理数据权限。选定模板和数据后前端发请求到后端后端返回JSON数据。前端拿到数据后用模板填充器把编辑器里的占位符替换成实际内容替换过程中做HTML转义和安全过滤。填充完成后用户可以直接微调、走CMS已有的内容审批和发布流程。发布环节如果需要Word或PDF版本再调用转换服务把编辑器里的HTML内容转成目标格式。后端服务层需要三块接口模板管理接口负责模板的增删改查、占位符提取、分类维护数据查询接口负责对接业务系统返回填数所需的JSON转换接口负责接收HTML文本和转换参数返回生成的文件下载地址。如果有条件这三块建议做成独立的服务模块方便多个CMS站点共用。2.2 占位符规范机器能替换、人能看懂的约定模板填充最恨的就是占位符规则混乱。有的模板用{name}有的用{{name}}有的用[name]解析器写起来像在猜谜。我在项目里固定了一套规则用到现在没出过歧义。单值字段用${fieldName}表示嵌套数据用点号比如${project.name}。列表循环用{{#listName}}开头、{{/listName}}结尾中间包住一段包含单值占位符的HTML块。这样设计的好处是模板写出来像普通正文非技术人员看几眼也能理解哪里会被替换成什么。空值兜底也要在规范里定义清楚。我约定默认空值替换成空字符串但模板可以显式给出兜底文案${approvalNo|待补充}竖线后面就是空值时的显示内容。这种细节看起来不起眼实际用起来特别重要不然数据源漏了一个字段文档里出现一大片空白用户根本不知道是自己选错了数据还是接口漏了字段。还要考虑字面量冲突。如果文档正文里真的要出现剂量为${mg}这种文字不想被替换怎么办我留了一个转义写法\${mg}填充器先把转义符暂时替换成占位标记等全部替换完再还原成字面量${mg}。这个坑是我上线后一个月才补上的有次一个药品采购公示里出现了${mg}被解析器当成字段替换成空值差点造成公示内容缺失。2.3 模板库与数据源如何组织模板不能只存一份HTML字符串那样占位符信息全丢了。我在数据库里设计了一张模板表和一张字段映射表模板表存正文内容、分类、适用部门、状态字段映射表存每个模板用到的占位符列表和对应的数据源路径。这样用户选择模板时系统能提前校验当前数据源能不能填满这个模板缺字段直接提示而不是等填充完才发现一堆空值。数据源的组织也要分层。同一个业务系统可能有多个接口返回不同的数据形态有的返回单对象有的返回列表。我建议后端封装一层数据源适配器对外暴露统一的查询语义按业务主键查单条、按条件查列表。这样模板里写的数据路径就是相对稳定的底层业务表结构变化时只需要改适配器不用动模板和前端逻辑。3. 实操手写一个KindEditor的智能填充插件3.1 插件骨架注册工具栏按钮KindEditor的插件扩展其实挺简单核心就是KindEditor.plugin(name, function(K){...})。我在项目里叫它docfill注册之后只要在编辑器初始化时把docfill加进items数组工具栏就会出现对应按钮。KindEditor.plugin(docfill, function(K) { var self this; var name docfill; self.clickToolbar(name, function() { self.plugin.docfill.openDialog(); }); });初始化编辑器时把插件名加进itemsK.create(#content, { width: 100%, height: 520px, items: [ source, |, undo, redo, |, docfill, |, bold, italic, forecolor, |, fullscreen ], afterCreate: function() { // 编辑器创建完成后可以预加载模板列表 } });这里有个容易忽略的点clickToolbar绑定的是工具栏点击事件但如果插件名没有出现在items里按钮不会渲染。所以排查按钮为什么没出来的时候先看items配置别一股脑怀疑插件文件加载问题。对话框我直接用KindEditor自带的K.dialog不引第三方弹窗库。这样风格统一也不引入额外依赖兼容性最好。self.plugin.docfill.openDialog function() { var dialog K.dialog({ width: 720, height: 520, title: 多格式文档智能填充, body: div iddocfill-panel div classdocfill-row模板select iddocfill-template/select/div div classdocfill-row业务编号input iddocfill-bizid typetext placeholder输入业务流水号或项目编号 //div div classdocfill-row iddocfill-preview/div /div, closeBtn: { name: 取消, click: function() { dialog.remove(); } }, yesBtn: { name: 填充文档, click: function() { var tplId K(#docfill-template).val(); var bizId K(#docfill-bizid).val(); if (!tplId || !bizId) { alert(请选择模板并输入业务编号); return; } // 1. 请求模板内容 // 2. 请求业务数据 // 3. 执行填充逻辑 // 4. 结果写回编辑器 // 5. 关闭对话框 dialog.remove(); } } }); };我在多个项目里一直用这套对话框写法稳定、好调试还能兼容IE11下的显示。3.2 数据回填模板加载、数据请求与填充逻辑填充的核心逻辑是一段正则替换加递归。模板内容拿回来之后先做列表循环块的处理再做单值字段的替换。列表处理用递归是因为循环块内部可能还会嵌套其他字段甚至子循环。function fillTemplate(content, data) { // 先处理列表循环块 {{#list}} ... {{/list}} content content.replace(/\{\{#(\w)\}\}([\s\S]*?)\{\{\/\1\}\}/g, function(match, listName, block) { var items data[listName] || []; var result []; for (var i 0; i items.length; i) { result.push(fillTemplate(block, items[i])); } return result.join(); }); // 再处理单值字段 ${fieldName} 和 ${fieldName|兜底文案} content content.replace(/\$\{([^}])\}/g, function(match, expr) { var parts expr.split(|); var path parts[0].trim(); var fallback parts.length 1 ? parts[1] : ; // 将转义的 \${ 还原这里预先用哨兵标记处理过了 var value getByPath(data, path); if (value undefined || value null || value ) { return escapeHtml(fallback); } return escapeHtml(value); }); return content; } function getByPath(obj, path) { var keys path.split(.); var cur obj; for (var i 0; i keys.length; i) { if (cur null) return undefined; cur cur[keys[i]]; } return cur; } function escapeHtml(str) { return String(str) .replace(//g, amp;) .replace(//g, lt;) .replace(//g, gt;) .replace(//g, quot;) .replace(//g, #39;); }填充完成后写回编辑器。这里有个关键细节如果是一次性整体替换用editor.html(html)如果只是在光标处插入一段内容必须用editor.insertHtml(html)。很多新手把这两个混着用结果要么光标位置丢得莫名其妙要么整个文档被覆盖。写回之后还要记得editor.sync()把编辑器内容同步回原始textarea否则表单提交时后台拿到的是空值这个坑我踩过不止一次。3.3 多格式输出服务端转换链路编辑器里的内容是HTML要输出Word和PDF我试过几种方案。最省事的是前端直接调浏览器打印生成PDF但政务系统里打印设置五花八门页眉页脚、边距根本控制不住效果很难统一。后来我把转换收口到服务端统一用LibreOffice headless模式。soffice --headless --convert-to pdf --outdir /data/docfill/out /data/docfill/tmp/source.htmlJava侧这样调用ProcessBuilder pb new ProcessBuilder( soffice, --headless, --convert-to, pdf, --outdir, outDir, srcPath ); Process p pb.start(); int code p.waitFor();转Word我同样用LibreOffice转成docx或者odt再另存。这样一圈下来格式统一性比前端打印强太多。但服务端转换有两个前置条件必须处理好一是服务器必须安装中文字体否则中文全变豆腐块二是临时HTML文件必须带meta charsetutf-8声明不然会出现中文乱码。这两个问题我在下一节踩坑实录里详细展开。如果你的环境不允许装LibreOffice也可以考虑用Aspose.Words这类商业组件转换质量更好但是按服务器授权采购流程要提前走。政务项目我建议先确认部署环境的软件安装策略再定技术方案否则方案写得再漂亮到了现场装不上都是白搭。3.4 与CMS用户权限和审批流程整合插件只是工具真正落地的坑在流程整合。模板不是所有用户都能用的不同部门能看到的模板集合同样要做隔离。我在后端模板接口里接入了CMS的统一权限体系按角色返回可见模板列表。这一步不做等上线之后某个部门用了另一个部门的内部模板那才是真的麻烦。填充操作还要留痕。每次填充我都在后端记一条操作日志内容包括操作用户、IP、模板ID、业务数据主键、填充时间。更重要的是填充完成后文档里要嵌入一份数据快照。为什么做快照因为业务系统的数据是活的今天填进去的项目金额明天可能被修改如果文档最后被归档读者看到的却成了后来改过的数据追责时说不清楚。我的做法是把填充时的数据JSON序列化后存到附件的扩展字段里谁有疑问直接比对。整个流程走完之后文档回到CMS的草稿箱走原有的内容审批和发布流程不在编辑器这层单独搞一套发布逻辑。4. 踩坑实录这些坑比功能本身更值得记录4.1 编辑器内容与iframe不同步KindEditor的编辑区是iframe用户看到的内容是iframe里body的innerHTML。程序往编辑器写入内容或提交表单时最容易出问题的是同步。典型症状是填充完成后文章在编辑器里看着没问题一发布出去正文是空的。原因就是editor.html(html)只改了iframe里的body没同步回原来的textarea。KindEditor有个editor.sync()方法把所有编辑区内容写回textarea必须在填充逻辑和表单提交事件里都调用。另外一个和同步相关的坑editor.html(html)会把内容完全重置同时清空撤销历史。用户如果不满一次填充结果按CtrlZ是撤不回来的。所以我在填充前会先editor.saveRange()存一下选中区域填充后用editor.restoreRange()恢复并且对需要局部插入的场景优先用insertHtml而不是整体html()。// 正确的填充写回姿势 editor.saveRange(); editor.html(newHtml); editor.restoreRange(); editor.sync();4.2 特殊字符、XSS与公文安全政务系统的数据来自多个业务系统填充数据绝对不能直接拼进HTML。我曾经在测试环境遇到过一条包含scriptalert(1)/script的数据填进模板后编辑器里弹了窗。虽然内网系统风险相对可控但等保测评如果抓到这个整改单是少不了的。我的做法是双层过滤。前端填充时用escapeHtml把数据里的HTML特殊字符转义保证进入编辑器内容区的只是纯文本。后端在保存接口再过滤一遍用白名单方式只允许p、span、br、table这类常规标签其余标签和事件属性全部剥掉。两层都做不是为了性能而是为了防住绕过前端直发后端的情况。还有一类特殊字符是百分号、花括号和反斜杠。数据内容里如果带了${xxx}这种串填充时会被当成占位符二次解析造成内容错乱。我在填充器里做了一个哨兵替换先把所有\${替换成一个不可能出现在正文里的标记单值替换完成后再把标记还原为${字面量。这个逻辑必须放在列表循环递归处理之前顺序反了照样出错。4.3 中文乱码与字体缺失服务端用LibreOffice转换中文文档最经典的两个问题一个是中文变乱码一个是中文字体全部变成方块。乱码十有八九是临时HTML文件没声明字符集。我用Java写临时文件时默认是平台编码在Linux服务器上大多UTF-8没问题但有些政务服务器设置过GBK环境变量。稳妥做法是显式写文件时用OutputStreamWriter指定UTF-8并且在HTML的head里加上meta charsetutf-8两边统一。字体缺失更隐蔽。有次我在跳板机上转换正常放到正式服务器上PDF里中文全变成空心方块排查了半天才发现正式服务器是最小化安装根本没装中文字体。解决方案是给服务器安装CJK字体包比如fonts-noto-cjk或者fonts-arphic-uming装完重启LibreOffice进程让它重新加载字体缓存。如果公文对字体有硬性要求比如标题要小标宋体、正文要仿宋还得把对应字体文件放到服务器字体目录并注册。这里要提醒一句商业字体的授权问题必须提前确认很多政务项目直接用开源字体替代或者采购字体授权。4.4 老旧浏器兼容IE11与国产浏览器KindEditor的存量用户很多跑在IE11甚至更老的内核上所以我的插件JS刻意保持了老语法用var、用function、不用箭头函数、不用Promise、不用fetch网络请求全部走K.ajax或者jQuery.ajax。这在2024年听起来像是考古但真在政务内网环境里见过一次用户点填充按钮后白屏就是因为new了一个Map对象IE不认识。调试建议装一台干净的Windows 7虚拟机只装IE11把插件完整跑一遍。Chrome上没问题不代表IE上没问题尤其要注意正则表达式、字符串的startsWith、includes这些方法IE里统统没有。4.5 大数据量填充导致页面卡死有的模板带大表格比如项目清单、资金明细一填就是几十上百行。如果用editor.html(html)整体替换大文档浏览器渲染iframe内部DOM会有明显卡顿如果在循环里每次insertHtml追加一行那性能更是灾难。我优化后的做法是在循环拼接阶段把每行HTML推入数组最后join()一次性组装完成再调用editor.html整体写回。数组push加join的性能远好于字符串连续拼接这个优化在数据量大时体感特别明显。另外填充期间给对话框加一个正在填充的遮罩提示避免用户重复点击造成编辑器状态错乱。5. 上线之后权限、审计与后续扩展5.1 操作留痕与数据权限边界功能上线只是开始后面三件事一件比一件重要。第一件是数据权限。用户在填充框里输入业务编号后端查询数据时必须校验这个用户有没有权限看这条业务数据。这个校验绝对不能只靠前端隐藏选项后端接口要拿着用户身份信息跟CMS权限中心对一遍。我遇到过数据接口直接按主键查数据、不带权限校验的情况理论上任何人知道编号就能拉出来这在政务环境里属于事故级别的漏洞。第二件是留痕。前面说过填充日志和数据快照这里再强调一个细节日志里除了记录谁在什么时候填了什么还要记录模板版本号。模板是会改的同一个模板改了三版之后追溯历史文档是用哪版模板生成的就必须依赖版本号。5.2 模板版本与占位符变更管理政务系统的数据字段变化比你想象的频繁。去年叫项目类型今年叫事项类型模板里的占位符就得跟着改。如果不做版本管理字段一变动所有存量模板瞬间失效填充出来的文档全是空值。我的做法是模板每次修改都生成新版本占位符列表一并存档。填充器运行前会检查当前模板的字段列表是否都能在数据源里找到找不到的字段列出明细用户可以选择忽略或者换数据源。这样做的好处是把结果坏了才发现提前到动作之前就预警体验差别很大。5.3 扩展空间OFD、签章与审批流对接这套框架搭好之后后面加功能都顺了。现在政务电子文件越来越多要求OFD格式在我们这套架构里只需要在转换服务层增加一个OFD转换器前端逻辑完全不用动。电子签章同理转换完成后的文件去调用签章服务本质上是在转换输出链路末尾接一个处理器。再往后扩可以把智能填充做成独立的微服务同时服务门户CMS、OA系统、行政审批平台模板和数据源统一管理避免每个系统各做一套、模板规则越搞越乱。这个方向是我目前看到的比较靠谱的落地演进路径。我个人在实际项目里最深刻的体会是KindEditor扩展本身不难难的是你愿不愿意把模板规范、数据适配、转换链路、权限审计这些脏活累活一次性想清楚。这个插件我前后迭代了三版才稳定下来第一版只做了字符串替换第二版加了列表循环和转义第三版才把模板版本和数据快照补上。如果你也在做类似的功能建议一开始就把模板版本和数据快照纳入设计别等上线之后被业务方追着补。最后再分享一个小技巧在模板预览区放一个调试填充按钮专门输出当前模板所有占位符的实际解析结果这个排查工具在整个生命周期里都非常好用。