1. 问题根源：为什么Word内容一进浏览器就“变脸”
做前端的人，尤其是跟CMS后台、富文本编辑器、协同文档打过交道的，基本都遇到过一个让人抓狂的场景：客户或者运营同事在Word里排版排得漂漂亮亮，标题带色、段落缩进、表格有边框、字体字号全部调好，然后信心满满地复制粘贴到编辑器的富文本区域里。点击保存，前台页面一刷新——标题字体全变宋体默认值，段落间距挤成一团，表格边框消失，项目符号乱套，图片要么消失要么变形。第一反应是编辑器出Bug了，第二反应是浏览器兼容性问题，排查半天发现都不是。问题的真正根源，在于Word的排版体系和我们浏览器所理解的HTML/CSS排版体系，压根儿就是两套完全不同的语言。
先说清楚Word那一侧。Word文档的底层格式是OOXML（Office Open XML），一套基于XML的专有描述规范。这里面字体、字号、颜色、段落缩进、行距、表格列宽、边框样式，全部打包在若干独立的XML节点里，结构层级和CSS的盒子模型有着很大的差异。而用户从Word里执行复制时，Word会在剪贴板里同时写入好几种格式的数据：纯文本、HTML片段、RTF富文本格式，甚至图片位图。浏览器里的编辑器在接收粘贴内容时，默认情况下会优先读取剪贴板里的text/html字段，也就是那个HTML片段。问题就出在这个HTML片段上。
Word生成的HTML片段，和我平时手写的标准HTML完全不是一个路数。它在<span>标签里塞满了类似mso-ascii-font-family、mso-bidi-font-size这样的私有CSS属性，还有大段的注释标记，比如<!--[if gte mso 9]><xml><w:WordDocument>...。这些私有的mso-*前缀属性，浏览器的CSS解析引擎根本不认识，样式在解析层就被直接丢弃了。更麻烦的是，Word会把段落格式用<p class="MsoNormal">来标记，但那个类名对应的样式定义并没有随粘贴内容一起传给浏览器，于是整个段落回落到了编辑器的默认样式。这就是为什么很多人粘贴完之后发现不是完全没样式，而是只有最基础的换行、加粗这些，其他精细排版统统丢失。
以最典型的表格为例。Word里的表格列宽，是用<w:tcW>这类OOXML节点描述的，转成HTML片段时，会变成<td style="width: 98.5pt">这种带pt单位的内联样式。如果编辑器自带的样式清洗规则比较激进，直接把所有的内联style属性都删掉，那表格就会变成一列宽度均等的“僵尸表格”，列宽完全脱离原始布局。用户到前台发现列宽对不上，想拖拽调整，结果又发现表格框线都没有——因为Word表格的边框样式也是通过OOXML描述的，转换出来的HTML里通常只会有一层淡淡的边框属性，很容易被编辑器当成“非白名单属性”给过滤掉。热搜词里的“word 表格列宽无法拖动”，很多时候就是这么来的。
除了格式描述差异，还有一个非常关键的技术点是剪贴板的MIME类型优先级。从Word复制内容时，剪贴板中至少存在以下几种数据：
text/plain：纯文本，所有格式信息全部丢失text/html：Word生成的HTML片段，含有大量mso-*私有属性和注释text/rtf：RTF格式，保留更多排版细节，但解析成本高image/png或image/bmp：整个选区被渲染成图片，所有文本都不可编辑
大多数主流富文本编辑器，比如TinyMCE、CKEditor、Quill，默认都是优先读取text/html。而一些轻量级编辑器或者自行封装的contenteditable组件，可能只处理了text/plain，那结果就是用户粘贴过来之后连换行都变成了一段话——这是另一个极端，但本质原因相同，都是没有处理好剪贴板数据格式的优先级和清洗逻辑。
理解了这个底层原因，你就能明白单纯的“换个编辑器”解决不了问题。编辑器只是载体，真正要做的是在粘贴进入编辑器的那一刻，拦截、解析、清洗、重排这整个管线。这也是这篇博文要完整讲清楚的核心内容。
2. 整体方案设计：搭建一条可复用的粘贴处理管线
要解决Word内容转存编辑器样式丢失的问题，不能靠零敲碎打地补丁式处理。我经过好几个项目的折腾，最终沉淀下来一套比较通用的处理管线，核心思路是四个字：拦截、解析、清洗、重建。也就是在粘贴事件触发时，先拦截浏览器的默认行为，拿到原始剪贴板数据，然后自己解析出干净的HTML结构，再按照当前项目维护的样式映射表和清洗白名单做处理，最后把重建好的内容插入编辑器。
2.1 方案选型：三种主流路线的对比与取舍
第一类方案是纯前端处理，也就是在编辑器原有的粘贴处理机制之上做增强。这种方式的好处显而易见，不需要增加后端服务，不依赖网络请求，粘贴的响应速度最快，用户几乎没有感知。缺点是前端代码要处理的情况比较多，尤其是老版本的Word和WPS生成的HTML结构差异很大，清洗规则很难一次性覆盖全面。
第二类方案是将Word文件整个上传到后端，用开源库解析Office Open XML格式，再输出为编辑器和前端页面可用的HTML或者Markdown。比如Java后端用过Apache POI，Node后端用过mammoth.js，Python后端也做过python-docx加自定义转换器。这种方案的解析质量最高，表格、图片、分页符都能比较完整地还原，但问题也很明显：用户的原始场景是从Word里复制粘贴，而不是上传文件。如果需要用户先把内容存成.docx再上传，操作链路变长，很多非技术用户根本不接受。
第三类方案是混合方案，也就是前端优先做粘贴内容的即时清理，如果检测到剪贴板里只有图片没有文本结构，再提示用户上传原始文档走后端解析。这种思路用户体验最好，但开发和维护成本也最高，适合中大团队。
从我个人的项目经验来说，如果没有强制的文档还原精度要求，建议优先做纯前端方案。理由主要有三个：
- Word粘贴出来的HTML虽然脏，但结构上还是有规律可循的，清洗规则可以持续迭代积累
- 纯前端方案不需要额外的服务器资源和文件存储，部署成本低
- 编辑器的粘贴链路本来就支持自定义处理器，不需要改架构
具体的选型上，如果你用的是TinyMCE，它有自带的paste_preprocess回调，在这个回调里修改粘贴的HTML内容是最常规的做法。CKEditor 5也有对应的paste事件。Quill的话需要自行监听clipboard模块的事件，相对灵活一些。如果是自己封装的contenteditable编辑器，那一切都可控，直接在paste事件里做文章就好了。
2.2 核心处理链路：从剪贴板到编辑器内容的完整路径
我在实际项目中把整条链路的处理顺序固定了下来，每一步都有明确的输入和输出，调试起来非常清晰。
整个链路的第一步是监听剪贴板的paste事件，调用event.clipboardData获取数据。这里要注意，clipboardData里能拿到的数据取决于浏览器的安全策略，在开发环境用localhost没问题，但如果你的站点是HTTP协议，线上环境可能会被浏览器限制剪贴板的访问，必须确保站点是HTTPS。
第二步是把拿到的text/html内容传入一个专门的解析函数。这个函数要做的事情很机械但也很关键：把<!--[if gte mso 9]>...<![endif]-->这类条件注释全部删除，把<xml>,</xml>,<o:p>,</o:p>这些Word特有的XML标签全部剥掉，只保留标准的HTML标签。完成这一步之后，内容看起来依然是“Word风格”的，但已经变成了一个语法合法的HTML片段。
第三步是样式映射。Word的mso-*属性需要被翻译成浏览器认识的CSS属性，比如mso-ascii-font-family对应font-family，mso-bidi-font-size对应font-size。这个翻译过程可以采用“查表+正则提取”的方式，从style属性中解析出关键键值对，替换成标准CSS。这一步做完，大部分基础排版样式就能保留了。
第四步是安全清洗。这一步需要结合项目的实际需求做取舍，比如只允许白名单内的标签存在，不允许<script>和<iframe>，把onerror、onclick这类事件属性一律删掉，防止XSS风险。同时要考虑样式属性的白名单，mso-*之外还有一些高风险的CSS属性，比如behavior、expression、-moz-binding，脏HTML里要是混入了这些，也会带来安全隐患。
第五步是把清洗后的HTML交给编辑器。如果你用的是TinyMCE，这一步尤其注意：TinyMCE对粘贴的内容会再次走一遍自己的过滤规则，所以你在paste_preprocess里处理得再干净，它还可能按照自己的valid_elements和valid_styles配置再做一次“二次清洗”。如果你的配置项没有把相关标签和样式加进白名单，前面所有的努力都可能白费掉。这是很多人反复调试没用、看代码逻辑又没错的经典原因。
最后一步，如果用户粘贴的是从WPS或者其他国产办公软件复制的内容，还要考虑一个兼容性分支。WPS生成的HTML片段和Word有差异，最典型的表现是不再遵循MsoNormal类名规范，而是直接用类似<p style="...">的内联样式。这种情况反而更好处理，因为内联样式比类名更容易解析，但麻烦在于WPS会带上一些自己的私有前缀属性，需要单独做一轮清理。
我把这套链路的责任边界划分清楚之后，再复杂的粘贴问题也能快速定位到具体是哪个环节出的问题。哪怕以后换了编辑器，只要链路不变，核心解析代码就能复用，这是我推荐大家沉淀独立处理模块的原因。
3. 核心代码实现：一张样式映射表搞定80%的样式还原
下面直接进入重点，给出我在真实项目中验证过的核心实现。整个模块我倾向于独立成一个wordPasteHandler.js，不依赖特定的编辑器，方便在多个项目间复用。
3.1 粘贴拦截与数据读取
先写一个最基础的事件拦截，所有后续处理都在这里启动。
document.addEventListener('paste', function (event) { const clipboardData = event.clipboardData || window.clipboardData; if (!clipboardData) { return; } const html = clipboardData.getData('text/html'); const plainText = clipboardData.getData('text/plain'); // 判断是否来自Word/WPS：html片段中存在mso前缀或class=MsoNormal if (html && /mso-|MsoNormal|WordDocument|w:WordDocument/i.test(html)) { event.preventDefault(); const cleanedHtml = processWordHtml(html); insertHtmlToEditor(cleanedHtml); return; } // 如果只有纯文本，走默认行为 if (!html && plainText) { return; } }, false);这里有一个细节值得注意：正则判断我在实际项目中用的是/mso-|MsoNormal|WordDocument|w:WordDocument/i，而不是只检测mso-前缀。原因是有些精简版Word或者部分邮件客户端复制出来的HTML片段，并不包含完整的mso-前缀，但会带有WordDocument的XML声明位置标记。多几个匹配条件，能显著提升识别准确率，减少“该走Word处理流程却没走”的情况。
3.2 样式映射表：mso前缀与标准CSS属性的转换
样式映射是整个方案的核心。我在项目里维护了一个映射表，把Word的私有属性批量翻译为浏览器认识的CSS属性。
const MSO_STYLE_MAP = { 'mso-ascii-font-family': 'font-family', 'mso-hansi-font-family': 'font-family', 'mso-bidi-font-family': 'font-family', 'mso-fareast-font-family': 'font-family', 'mso-ascii-theme-font': 'font-family', 'mso-hansi-theme-font': 'font-family', 'mso-bidi-font-size': 'font-size', 'mso-font-charset': 'font-charset', 'mso-spacerun': 'letter-spacing', 'mso-bidi-font-weight': 'font-weight', 'mso-ansi-font-size': 'font-size', 'mso-ansi-language': 'language', 'mso-fareast-language': 'language', 'mso-bidi-language': 'language' };这里的映射逻辑是，遍历元素的style属性中的所有键值对，如果键名命中映射表，就把键名替换为标准CSS属性。比如mso-ascii-font-family: 'Times New Roman'会被替换为font-family: 'Times New Roman'。
但在实际项目中，我很快发现一个问题：Word经常同时设置mso-ascii-font-family和mso-hansi-font-family，这两者的值在大多数情况下是一致的，但如果用户混用了中西文字体，两个值会不一样。这时候直接映射成同一个font-family属性，后者会覆盖前者，字体丢失一半。解决方案是在映射前做一次合并判断，如果检测到多个mso字体属性值相同，直接映射为一个font-family，如果值不同，就合并成font-family: 'Ascii字体', 'Hansi字体'这种回退格式。
3.3 HTML清洗函数完整实现
下面是整个处理模块的完整核心代码，我逐段解释每个函数的作用。
function processWordHtml(html) { // 第一步：剔除Word的XML声明与条件注释 let cleaned = html.replace(/<!--\[if[^]*?<!\[endif\]-->/g, '') .replace(/<xml>[\s\S]*?<\/xml>/g, '') .replace(/<o:p>\s*<\/o:p>/g, '') .replace(/<o:p>/g, '<span>') .replace(/<\/o:p>/g, '</span>') .replace(/<w:[^>]+>/g, '') .replace(/<\/w:[^>]+>/g, '') .replace(/xmlns:[a-z]+="[^"]*"/g, ''); // 第二步：利用DOMParser将字符串解析为DOM，方便做结构遍历 const doc = new DOMParser().parseFromString(cleaned, 'text/html'); const body = doc.body; // 第三步：遍历所有元素，清洗style属性 const allElements = body.querySelectorAll('*'); allElements.forEach((el) => { cleanStyleAttr(el); removeUnsafeAttrs(el); }); // 第四步：清理Word特有的类名 body.querySelectorAll('[class]').forEach((el) => { const classList = el.className.split(/\s+/); const filteredClasses = classList.filter((cls) => { return !/^Mso/i.test(cls) && cls !== 'MsoNormal'; }); if (filteredClasses.length === 0) { el.removeAttribute('class'); } else { el.className = filteredClasses.join(' '); } }); // 第五步：移除空元素，但保留有意义的p、br body.querySelectorAll('*').forEach((el) => { if (el.children.length === 0 && el.textContent.trim() === '') { const tag = el.tagName.toLowerCase(); if (!['br', 'img', 'hr'].includes(tag)) { el.remove(); } } }); return body.innerHTML; }cleanStyleAttr函数负责样式属性的迁移和映射：
function cleanStyleAttr(el) { const styleVal = el.getAttribute('style'); if (!styleVal) { return; } // 分号分割，冒号分割，逐个处理 const styleParts = styleVal.split(';'); const standardStyles = {}; const msoFontFamilies = []; styleParts.forEach((part) => { if (!part.trim()) return; const colonIndex = part.indexOf(':'); if (colonIndex === -1) return; const prop = part.slice(0, colonIndex).trim(); const value = part.slice(colonIndex + 1).trim(); if (!prop || !value) return; // 剔除危险属性 if (/^(behavior|expression|-moz-binding|position|left|top)$/i.test(prop)) { return; } // 收集mso字体属性 if (/^mso-(ascii|hansi|bidi|fareast)-font-family$/.test(prop)) { msoFontFamilies.push(value.replace(/^['"]|['"]$/g, '')); return; } if (MSO_STYLE_MAP[prop]) { standardStyles[MSO_STYLE_MAP[prop]] = value; } else if (!/^mso-/.test(prop)) { // 非mso前缀的标准CSS属性，保留 standardStyles[prop] = value; } }); if (msoFontFamilies.length > 0) { const uniqueFonts = [...new Set(msoFontFamilies)]; standardStyles['font-family'] = uniqueFonts.join(', '); } const newStyle = Object.entries(standardStyles) .map(([k, v]) => `${k}: ${v}`) .join('; '); if (newStyle) { el.setAttribute('style', newStyle); } else { el.removeAttribute('style'); } }removeUnsafeAttrs函数负责移除事件属性和危险链接：
function removeUnsafeAttrs(el) { const attrs = el.attributes; for (let i = attrs.length - 1; i >= 0; i--) { const attrName = attrs[i].name.toLowerCase(); if (attrName.startsWith('on') || ['style', 'class', 'id'].includes(attrName) === false && attrName.startsWith('data-') === false && /^mso-/.test(attrName)) { el.removeAttribute(attrName); } } // 对于a标签，校验href协议 if (el.tagName.toLowerCase() === 'a') { const href = el.getAttribute('href') || ''; if (!/^(https?:|mailto:|tel:|#)/i.test(href)) { el.removeAttribute('href'); } } }3.4 表格样式专项处理：还原Word表格的边框与列宽
Word表格在转HTML时有个特点，Table的边框样式不会写在标准border属性里，而是写在每个单元格的<td>上。而且不同版本的Word生成的HTML，边框属性差异很大。我处理表格的方式比较直接，在cleanStyleAttr执行完之后，再单独把没有边框样式的table补一层默认边框。这么做的好处是前台页面不会出现“表格没线”的尴尬场面，缺点是如果你要完全复刻Word表格的细线样式，还得再细化。
function normalizeTableStyles(root) { root.querySelectorAll('table').forEach((table) => { table.setAttribute('border', '1'); table.setAttribute('cellspacing', '0'); table.style.borderCollapse = 'collapse'; table.style.width = table.style.width || '100%'; table.querySelectorAll('td, th').forEach((cell) => { cell.style.border = cell.style.border || '1px solid #dddddd'; }); }); }这里我踩过一个坑：直接给table加border="1"属性，在一些浏览器里会产生双线边框，所以一定要同时设置border-collapse: collapse。另外，Word表格的列宽通常写在<td>的style里，但我们在清洗过程中可能把包含width: 98.5pt的样式保留了，这个pt单位在页面渲染时会被当成绝对长度。为了排版稳定，我建议把单元格宽度统一转成百分比或者像素值。
3.5 接入编辑器：以TinyMCE和Quill为例
如果你用的是TinyMCE 5或者6，接入方式非常简单：
tinymce.init({ selector: '#editor', paste_preprocess: function (plugin, args) { const cleaned = processWordHtml(args.content); args.content = cleaned; } });这里需要提醒你两个比较隐蔽的坑。第一，paste_preprocess里拿到的args.content已经是TinyMCE从剪贴板读取并做了一轮初步转换后的HTML，并不一定是原始剪切板内容。如果你希望拿到最原始的text/html，要在paste事件更早期介入。第二个坑是TinyMCE自带的过滤规则非常强大，paste_preprocess处理完之后，它还会用valid_elements和valid_styles再次扫描。所以如果你的配置里没有允许table和tr、td这些标签，或者没有允许border、width这些样式，表格依然会被过滤掉。我用TinyMCE时还会额外加一段配置：
valid_elements: '*[*]', valid_styles: { '*': 'font-family,font-size,color,background-color,text-align,vertical-align,' + 'line-height,margin,padding,border,border-collapse,width,height,' + 'list-style-type,font-weight,font-style,text-decoration,letter-spacing' }如果你用的是Quill，就要监听clipboard模块的事件，然后通过clipboard.convert()处理内容：
quill.clipboard.addMatcher('p', function (node, delta) { // 对Delta结构做样式映射和清洗 return delta; });Quill的addMatcher是按标签匹配的，它的编程模型和TinyMCE完全不同，其实更灵活但更容易出错。我的建议是不要在addMatcher里做太重的HTML清理，而是先做全局的粘贴拦截，统一清洗完之后再交给Quill。这样逻辑清晰，调试也方便。
4. 把方案落地到不同编辑器与业务场景
前面给的代码是一套独立的清洗模块，实际项目中它还面临两个问题：一是不同编辑器的内部机制差异会导致同样的代码表现不同，二是不同业务场景对“样式保留度”的要求不一样。这一节专门讲怎么把方案适配到实际业务里。
4.1 针对TinyMCE、CKEditor、Quill、wangeditor的差异化适配
先说说CKEditor 5。它跟TinyMCE的最大差异是，CKEditor 5的粘贴处理走的是ViewDocument模型，粘贴的HTML会先被转换成它内部的视图模型，再经过Downcast和Upcast机制转换回HTML。这意味着你在paste事件里拿到的event.content不一定能完全控制最终插入内容。CKEditor 5处理Word内容有官方推荐的Word插件路径，同时也支持自定义editor.plugins.get('ClipboardPipeline')的监听。实践下来，最有把握的方式是直接监听原始DOM事件，通过editor.editing.view下手，将清洗后的HTML设置成view的片段。
Quill的情况前面说过，核心在于它的Delta数据结构，所有的样式都必须通过attributes字段来表达，比如{ color: '#ff0000' }。所以如果你希望Word里的文字颜色保留，必须把清洗后HTML的color样式映射到Delta的attributes.color里。Quill默认不识别很多CSS属性，像line-height、letter-spacing这些，你在HTML里保留了也没用，Quill展示时不会用。所以Quill场景下，要么接受“排版样式降级”，要么就要在Quill的主题里自行扩展渲染能力，这是一个比较大的坑。
如果你用的是国内用得比较多的wangeditor，它的原理其实比较类似TinyMCE，是典型的contenteditable模式下字符串HTML输出。可以直接监听编辑器的text-change或者before-upload相关事件，但更简单的做法是直接重写它的handlePaste方法。wangeditor源码里有handlePaste函数的实现，你可以把它替换成自己的逻辑，先克隆原始函数，清洗完再调用原方法。
4.2 不同业务场景对样式保留的不同取舍
我在对接不同类型的项目时发现，对样式保留度的要求完全不一样，处理策略也得跟着变。
如果是公司内部OA系统的公告编辑器，用户从Word复制来的内容大多数是红头文件、通知公告，这类内容的排版相对固定，重点要保留标题居中、首行缩进两个字符、加粗下划线、表格框线。此时样式映射表可以做得非常激进，把这些样式全部映射到标准CSS，以求最大限度还原。
如果是面向C端用户的社区发帖编辑器，情况完全不同。C端用户从Word复制来的内容比较随意，而且可能存在大量带颜色的文字、花哨的字体、嵌套表格，强行保留会让社区页面的排版乱成一锅粥。这时候的处理策略应该是“保内容，弃样式”，只保留标题层级、段落分隔、列表结构，把复杂样式降到最低。一般做法是清洗时把mso-*属性和大部分字体、颜色样式都去掉，只保留<h1>～<h6>、<p>、<ul>、<ol>、<li>、<table>这些基础结构。
如果是知识库Wiki系统，内容往往需要二次编辑，所以保留语义化的结构比保留视觉样式更重要。这种情况下建议把Word内容转换成Markdown格式，再存到文档库里。这里顺便提一句，热搜词里大家总在讨论“markdown转word工作流coze”，其实是反向操作；如果你需要的是Word转存到富文本编辑器，还可以考虑用一些现成的开源转换库，比如mammoth.js在前端解析.docx文件、turndown把HTML转Markdown，组合起来也能做一个半自动的转换管线。
4.3 多端兼容性：Windows、macOS、移动端的粘贴差异
还有一类问题容易被忽略，就是不同操作系统、不同浏览器下，剪贴板数据内容本身就不同。同一个Office文档，在Windows的Chrome里复制和在macOS的Safari里复制，剪贴板里的text/html片段长度和结构可能差异巨大。Windows下Word复制的HTML带有完整的<o:p>标签和XML声明，macOS下复制的内容反而更“干净”一些，更接近标准HTML。移动端从WPS复制内容到浏览器，很多情况下剪贴板只有text/plain，没有text/html，那前面的处理流程全都不会触发，只能退化为纯文本粘贴逻辑。所以说，做这一块的测试，一定要覆盖Windows Chrome、Windows Edge、macOS Chrome、macOS Safari、iOS Safari、Android Chrome这六种最常见的组合，测试用例至少包含“带表格的文章”“多级标题混排”“图文混排”“带复杂列表”四种类型。
5. 常见问题与排查：那些年踩过的坑
这一个章节来自我和团队在项目中反复踩坑总结出来的实战经验，按问题现象、原因、解决方案、排查思路四段式给出，方便你遇到问题的时候直接对着查。
5.1 内容全程丢失，粘贴后编辑器空白
这个问题的现象是用户复制了Word里的内容，粘贴到编辑器，结果编辑器里空空如也，连纯文本都没进来。排查顺序一般是先看控制台有没有报错——如果你用了我前面写的event.preventDefault()，但后面insertHtmlToEditor执行抛异常了，那内容会丢失且没有任何提示。重点检查两个地方：第一，clipboardData.getData('text/html')是否返回空字符串，有些浏览器在用户没有授权剪贴板读取权限的情况下，返回空字符串，此时应该回退到不做处理，让浏览器走默认粘贴；第二，DOMParser解析HTML时，如果传入了大段包含畸形标签的字符串，解析器可能不会抛错，但生成的DOM节点比预期少很多。所以我在解析后都会加一个节点数量的判断，如果清洗后的HTML长度比原始HTML短得离谱，就放弃自定义处理，回退到默认粘贴。
5.2 Word里的图片粘贴后无法显示
Word里的图片复制到剪贴板后，图片数据是独立的二进制块，并不会被一起编码到text/html里，而是在HTML片段里留下一个<img>标签，src指向一个file://协议的本地路径，或者一个类似blob:https://...的临时地址。浏览器出于安全策略，不允许页面访问file://协议，所以图片显示不出来。TinyMCE默认会把图片转成Base64存储，但用户图片太大时，Base64字符串过长会导致性能问题。
我的处理方案是监听图片的加载失败事件，检测<img>的src前缀，如果是file://，就把Word图片从剪贴板的File列表中读取出来，转成Base64替换src。ClipboardData的items属性里有一个getAsFile()方法，可以拿到Word复制时写入的原始位图文件。
function handlePastedImages(event, root) { const items = event.clipboardData && event.clipboardData.items; if (!items) return; const imageFiles = []; for (let i = 0; i < items.length; i++) { if (items[i].type.indexOf('image') === 0) { const file = items[i].getAsFile(); if (file && file.size > 0) { imageFiles.push(file); } } } root.querySelectorAll('img').forEach((img, index) => { const src = img.getAttribute('src') || ''; if (src.startsWith('file://') && imageFiles[index]) { const reader = new FileReader(); reader.onload = function (e) { img.setAttribute('src', e.target.result); }; reader.readAsDataURL(imageFiles[index]); } }); }这里还有一个坑：Word粘贴时剪贴板的图片是BitMap格式，用FileReader读出来转Base64之后，src前缀不再是JPG或者PNG，而是image/bmp，现代浏览器基本都支持显示，但数据量很大。如果编辑器有图片压缩功能，建议顺手做一次Canvas压缩，把BMP转换成压缩后的JPEG，可以有效降低最终内容的体积。
5.3 表格列宽乱成一团，调整宽度没有反应
前面分析过，Word表格的列宽是以pt单位写入单元格内联样式的。如果你的清洗逻辑保留了这些内联样式，理论上列宽应该能还原。但有一个特殊情况，就是Word里用户通过“自动调整”生成的表格，html里面多个<td>的width值加起来小于表格总宽度。浏览器渲染时就会按内容自行分配列宽，造成“列宽乱掉”。解决方案是在表格清洗完成之后，把所有单元格的宽度读取出来，重新按比例计算百分比的列宽值，然后统一写入。这样做的好处是保证表格在各端渲染的一致性，不依赖用户浏览器的默认分配逻辑。
另外，关于“word 表格列宽无法拖动”，单独说一下。如果你清洗后的表格本身没有table-layout: fixed，浏览器默认的table-layout: auto会让列宽随内容自动伸缩，用户手动拖拽表头时浏览器可能不响应。要给表格加上table-layout: fixed属性，并且给第一行的每个单元格设置百分比宽度，这样才能保证用户在前台拖拽列宽时行为可预期。
5.4 字体大小变成大得离谱或小得看不清
Word里的字号是以“磅”为单位的，比如小四号字是12pt，三号字是16pt。转换成的HTML里通常会写成font-size: 16.0pt这样的样式。但有些编辑器会忽略pt单位，直接读取数字，然后当成像素值来用，16pt就会渲染成16px，视觉效果明显偏小。反过来，如果编辑器把pt当成em来解析，字号又会大得离谱。
解决方案是标准化字号单位。我在清洗函数里会把所有的pt单位统一转换为px，转换公式是1pt = 4/3 px，也就是fontSize * 1.333。同时要注意Word还有一套中文字号名称，比如“小四”“五号”“一号”，这些中文名称在HTML中有时会直接写进去，不转成标准CSS数值的话，浏览器无法识别。我在映射表里加了一份中文字号到像素值的映射：
const CHINESE_FONT_SIZE_MAP = { '初号': '42pt', '小初': '36pt', '一号': '26pt', '小一': '24pt', '二号': '22pt', '小二': '18pt', '三号': '16pt', '小三': '15pt', '四号': '14pt', '小四': '12pt', '五号': '10.5pt', '小五': '9pt', '六号': '7.5pt', '小六': '6.5pt', '七号': '5.5pt', '八号': '5pt' };当然，这个映射是精简化版本，实际上不同字体在Word中的真实显示像素会有细微差别，但作为Web端还原来说已经足够。
5.5 粘贴后出现大量o:p残留，或者段落间距被吃掉
<o:p>是Word段落标记的XML标签，正常清洗时应该被移除。如果你用的编辑器清洗规则比较简单，或者清洗顺序不对，这个标签会残留在内容里，前台页面渲染时表现出奇怪的间距或者空白。我在清洗流程中强制把<o:p>替换成空字符串，但如果<o:p>内部有内容，比如Word的批注文字或者脚注数字，直接删掉会导致内容丢失。所以更稳妥的是处理成<span>标签，保留内部内容，后续再通过样式清洗把Word的私有类名去掉。
段落间距被吃掉，是另一个常见问题。Word里的段落间距写在<p>的margin-top和margin-bottom属性里，但很多清洗规则会把margin属性一律删掉——理由是防止用户通过编辑器的样式注入来破坏页面布局。从安全角度这个理由成立，但从产品角度，段落间距全丢会导致大段文字挤成一团，可读性很差。我的建议是在清洗时不删除margin属性，而是做一次数值兜底：如果清洗后的段落没有设置margin-top和margin-bottom，就补上默认的段落间距，比如margin: 0 0 1em 0，保证段落之间有呼吸感。
6. 扩展思路：这里有一条更省力的新路径
如果你正在做一个全新的项目，还没有被历史代码绑定，可以考虑跳出现有编辑器，直接用支持Markdown的编辑器搭配转换库来规避这个问题。我在最近的一个知识库项目里做了这样的尝试，效果出乎意料地好：编辑器选用支持Markdown的VDitor或者ByteMD，用户粘贴Word内容时，先把HTML清洗成标准HTML片段，再用turndown服务把HTML转换成Markdown，存入文档库的时候存储的就是Markdown源文件。这样不仅彻底绕开了编辑器样式丢失的问题，还大大降低了内容格式的维护成本。前台页面的渲染则由Markdown渲染引擎统一输出样式，视觉上是完全可控的。
这个方案唯一的痛点是表格。Markdown原生不支持复杂表格的合并单元格，用户粘贴一个有合并单元格的表格，转换成Markdown之后会丢失合并信息。针对这个问题，我在当前项目里做了一层增强：表格在转换阶段先走一次行列信息的解析，如果是普通表格，正常转Markdown；如果检测到合并单元格或者列宽信息复杂，就保留原始HTML作为“富文本块”单独存储，渲染时原样嵌入。这样既保证了表格的完整性，又让常规内容享受了Markdown的简洁和可控。
如果你是做后端方向的，也可以考虑让后端直接接收用户上传的.docx文件，用mammoth.js在Node端解析成HTML或者ODT格式，精度比前端拼正则高得多。mammoth对Word的样式还原做得相当好，尤其是列表、标题、表格这类结构，解析出来的HTML干净整洁。缺点是它不解析复杂CSS样式，比如带背景色、内边距的单元格，这些还是得靠前端二次清洗。所以最理想的分工是：后端负责把.docx解析成干净的HTML，前端负责在进入编辑器前做一轮安全清洗和样式白名单过滤。
根据我踩坑后的经验，如果你要搭一条Word转存编辑器的处理链路，建议按照“前端拦截清洗为主、后端文件解析兜底、最终存储格式看场景”这个原则来设计。前端能处理掉的，绝对不丢给后端；后端负责精度还原的，前端不做二次过滤。这条链路跑顺之后，你会发现用户报“样式丢失”的工单量会肉眼可见地降下来。
最后再分享一个测试技巧。你可以准备一个固定的“压测Word文档”，里面包含多级标题、加粗倾斜、各种颜色文字、首行缩进段落、有序列表、带合并单元格的表格、插入的图片、以及域代码。每次调整完清洗规则或者升级编辑器内核之后，就把这个文档从头到尾复制粘贴一遍，截几张关键截图做对比。我在团队里把这个压测文档命名为“魔鬼文档”，每次回归测试只要跑一遍它，就能快速暴露八成以上的样式还原问题。这套方案本身并不神秘，真正值钱的是你在反复调试中积累下来的那些映射规则和异常分支，一定要记得沉淀到项目的共享文档里，而不是留在某个人的脑子中。
