1. 从Word复制出来的内容，比你想的更复杂
1.1 剪贴板里的数据不止是“文字”
最近做后台内容管理系统，被一个听起来很简单的需求卡了两天：用户从Word复制一段图文，图片上还带着超链接，粘贴到富文本编辑器里，图片大概率能显示（如果走base64转存），但超链接属性十次有九次丢。查了编辑器文档、贴了一堆断点之后，我发现这事得从剪贴板的数据形态说起。
当你在浏览器里监听粘贴事件，会拿到一个ClipboardEvent对象，里面有个clipboardData属性。这个家伙同时装着好几份数据：纯文本、HTML、RTF，甚至可能还有图片文件。我用过一段最简单的代码来观察它到底装了啥：
document.addEventListener('paste', (e) => { const types = Array.from(e.clipboardData.types || []); console.log('types:', types); if (types.includes('text/html')) { console.log('html:', e.clipboardData.getData('text/html')); } });从Word里复制一段“图文混排且图片带链接”的内容，然后粘贴到自己的页面看看输出。你会发现这条路一开始就不好走：这份text/html不是干干净净的<p>文字</p><img src="...">，而是一大坨带命名空间的HTML，里面塞满了大量mso-开头的内联样式，图片还可能被表示成VML结构而不是普通<img>。
这里有一个容易踩的坑：很多人在拿到HTML后直接用正则去抠<img src="...">，但Word粘贴过来的图片压根未必是<img>标签。如果页面里正好是VML结构（<v:shape>包着<v:imagedata>），正则就匹配不到，图片自然就丢了。要做的是先承认“格式很脏”，再用完整DOM解析去处理。
1.2 Word版HTML的特征：命名空间、mso样式与VML图片
Word生成的HTML一眼就能认出来，因为它带了一组别处几乎见不到的命名空间。典型的有：
xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml"v:是VML（矢量标记语言），o:是Office通用命名空间，w:是Word专有标记，m:是OMML公式标记。看到这组东西，基本可以断定内容来自Microsoft Office。你可以不背它们的含义，但得知道它们存在，因为后面做“内容是否来自Word”的判定，这些是重要依据。
除命名空间外，class="MsoNormal"、样式里的mso-spacerun:yes、mso-pagination:none、mso-list:l0 level1 lfo1这些特征也特别明显。它们表达的是Word自己的排版语义，浏览器不识别，编辑器更不识别，反而会在粘贴时被当垃圾处理。很多编辑器默认“自动清洗”就是这么把好端端的排版搞乱的。
图片部分有两副面孔。一副是已经被浏览器解析成的普通<img>，src是一长串data:image/png;base64,...；另一副是保留VML原貌：
<v:shape id="图片_x0020_1" o:spid="_x0000_s1026" type="#_x0000_t75" style="width:180pt;height:120pt;visibility:visible;mso-wrap-style:square;"> <v:imagedata src="data:image/png;base64,iVBOR..." o:title="图片"/> </v:shape>两种情况我都处理过。用DOMParser把HTML解析成DOM再遍历，远比正则硬抠可靠——VML属性顺序一变，正则就废了。
还有一种无解的情况：Word里存的是“图片占位符”，复制出来后HTML里只有<img src="file:///...">这种本地引用，数据源根本不在剪贴板里。遇到这种情况神仙也救不回来，只能在产品里提示用户重新插入图片。这个边界最好在需求阶段就跟业务说清楚，否则上线后会被当成bug反复提。
1.3 那“超链接属性”为什么总会被吃掉
Word里给图片设置超链接，复制出来的HTML应该是<a href="目标地址">包裹着<img>或者<v:shape>的结构。链接属性丢在编辑器的原因，我归纳下来就三条：
第一，编辑器接管粘贴后按自己的schema过滤“不合法”的标签和属性。TinyMCE、Quill、CKEditor都有合法的元素/属性配置，target、rel，甚至某些场景下的href都可能被当成不安全属性删掉。看起来只是少了几个属性，图片的点击跳转功能整个就没了。
第二，即使编辑器本身没删，HTML清洗器也会动手。现代编辑器普遍内置DOMPurify类似的XSS过滤，javascript:协议会被擦除，过严的配置下普通外链也容易被误伤。这些清洗器对显示类标签很宽容，但对<a>的额外属性相当严格。
第三，我们自己的处理流程有责任。网站上一般不允许直接用base64图片，需要先转存服务器再替换<img>的src。这个替换是异步的，操作顺序一错，图片上传完成后外层<a>已经被编辑器处理掉，链接就彻底没救了。
三个原因叠一起，用户看到的现象就是：从Word粘贴图文，图片时有时无，链接永远丢。下面这部分我把每一步的解决方案和翻车点都拆开讲。
2. 三个“凶手”：图片不见、链接变没，逐一排查
2.1 编辑器的粘贴预处理，第一个动手
先拿TinyMCE举例。TinyMCE官方建议用paste_preprocess回调来干预粘贴内容，在这个回调里你可以拿到args.content并直接修改。很多团队就是在这个环节把Word内容里的样式删得稀里哗啦：
tinymce.init({ selector: '#editor', paste_preprocess: function(plugin, args) { args.content = args.content.replace(/<style>[\s\S]*?<\/style>/gi, ''); // 继续删样式、删标签 } });问题在于，paste_preprocess执行时，VML、mso-样式、命名空间这些已经堆在args.content里。如果你的清洗规则是“把所有含mso-的样式全删”，那图片的外层包裹结构也很容易被一起删掉。我亲眼见过一个同事写的清洗逻辑，处理之后<a href="..."><v:shape><v:imagedata/></v:shape></a>变成了一个孤立的光秃秃图片，链接自然没了。
Quill的机制不太一样，它提供的clipboard.addMatcher(NodeType, callback)允许你针对特定标签做处理。但如果在匹配器里只返回了img标签、丢掉了外层a，那链接同样保不住。CKEditor也有类似问题，它的paste事件和专门的过滤器会把Word内容拆解得支离破碎。
所以一个原则很重要：不是拿到HTML就开始删，而是先理解哪些是“该留的”，尤其图片和链接，必须在清洗前就摘出来保护。
2.2 XSS过滤与属性白名单，悄悄删链接
内容安全是个硬需求，我完全支持XSS过滤，但很多编辑器默认的过滤规则对“带链接的图片”极不友好。拿DOMPurify举例，它默认允许<a href>，但target="_blank"往往会被去掉，理由是你打开新窗口时最好带上rel="noopener noreferrer"，否则有安全风险。这个我认可，但不能因此把链接给砍了。
TinyMCE更直接，extended_valid_elements不写明白，schema里没有的属性一概不留。比如你需要在编辑器里保留图片的超链接，至少要配成：
extended_valid_elements: 'a[href|target|rel],img[src|alt|title|width|height]'否则粘贴时<a href="https://example.com"><img src="..." /></a>里的href都好说，但target、rel大概率被删。用户看到的就是图片无法在新标签页打开，反馈“超链接属性不保留”。
这里需要注意：不同编辑器、不同版本，schema的默认值差别很大。不要依赖记忆，改完配置一定要在开发环境实际从Word复制一次，打开F12看最终DOM长什么样。
2.3 上传回填的时机不对，图和链一起翻车
网站一般不能一直用base64图片，需要把图片传到服务器，拿到URL后替换<img>的src。我见过一种错误做法，效果类似于这样：
// 错误示范：先插入再异步替换 pasteContent = pasteContent.replaceAll('<img', '<img>document.addEventListener('paste', (e) => { const html = e.clipboardData.getData('text/html'); if (!html) return; // 这里先把原始html暂存到一个队列里 window.__rawPasteQueue = html; }, true);但拦住事件不等于接管流程。真正要做的，是在检测到Word内容后阻止默认行为，自己加工完再插入编辑器。以TinyMCE为例，也可以用paste_preprocess改args.content，但那样编辑器的schema过滤仍然会发生。我更推荐在处理函数里全流程接管：
document.addEventListener('paste', async (e) => { const html = e.clipboardData.getData('text/html'); if (!isWordHTML(html)) return; // 非Word内容，交给编辑器默认处理 e.preventDefault(); const processedHTML = await processWordHTML(html); editor.insertContent(processedHTML); }, true);从这个角度你会发现：识别是不是Word内容，变得非常关键。识别对了才接管，识别错了会干扰用户从网页、从其他文档的正常粘贴。
3.2 识别Word与WPS，三个特征串就够
我在实际项目里用的检测逻辑很简单，三个特征里有任何一个命中，就按Word内容处理：
function isWordHTML(html) { if (!html) return false; return /xmlns:o=|xmlns:w=|xmlns:v=|class="MsoNormal"|mso-/.test(html); }WPS也走这条路。WPS生成的HTML会带上类似的命名空间，虽然细节有差异，但mso-这个前缀特征基本跑不掉。实测下来，用这个正则识别Word和WPS的准确率相当高。
不过有个反例要注意：有些网上复制的文章，本身就是从Word导出后传到网页上的，内容里也可能带mso-样式。对这种内容我们按词内容处理也没毛病，因为结构确实具备Word特征，处理流程反而能整理得更干净。
另外，别用“包含<img且src是base64”当作Word的识别依据——网页上拖拽上传的图片同样是base64。识别依据必须聚焦Word的特征标记，而不是图片格式。
3.3 清理之前，先把图和链接“摘出来”
识别为Word内容后，下一步是把“该留的”先存好，再动清洗刀。我的做法是用DOMParser解析出DOM，然后先遍历，提取所有有效图片和它们各自的超链接信息，存到一个结构里：
function extractImagesAndLinks(doc) { const items = []; const imgs = doc.querySelectorAll('img, v\\:imagedata, *[type="#_x0000_t75"]'); imgs.forEach(node => { const src = node.getAttribute('src') || node.getAttribute('data-src') || ''; if (!src) return; const parentA = node.closest('a'); items.push({ node, src, href: parentA ? parentA.getAttribute('href') : null, target: parentA ? parentA.getAttribute('target') : null }); }); return items; }注意querySelectorAll里的v\\:imagedata这种写法，在部分浏览器里对XML命名空间支持不好，可能匹配不到。更保险的做法是通用遍历所有元素，通过node.tagName.toLowerCase() === 'v:imagedata'或者node.getAttribute('src')来判断。
摘出来的图片信息，后面清洗HTML时不会被动；上传完成后，按这份记录回填src并重建超链接包裹。这个“先摘出来，再清，再放回去”的顺序是整个方案的核心思路。
4. 图片保留下来的完整链路：从base64到服务器URL
4.1 Word图片的两种存在形态，以及取图顺序
图片在Word粘贴HTML里的形态，我概括成两种：一种是已经解析成<img>标签的，src就是base64或外链；另一种是VML结构，v:imagedata的src才是真正的图片数据。有些文档两种结构同时出现，<img>有值，旁边的v:shape也在，处理顺序错了容易重复上传。
我的策略是：先收集所有<img>，把src里包含data:或http(s)://的视为候选图；然后处理v:shape里面的v:imagedata，如果它存在且没有被前面任何<img>引用，就补一条候选图。实际操作中，我会以“这个src最终要渲染成一个<img>”为目标，把VML结构在DOM里原地替换成<img>，避免重复。
如果VML的v:imagedata里src为空，再看它有没有o:title——这种情况多数是占位符，直接标记为不可上传，让前端显示一个“图片无法自动粘贴，请手动插入”的提示占位即可。
4.2 提图、上传、回填，顺序一步都不能乱
确定候选图后，把base64转成Blob上传。这一步网上代码很多，我贴一版我实际用的：
function dataURLtoBlob(dataurl) { const arr = dataurl.split(','); const mime = arr[0].match(/:(.*?);/)[1]; const bstr = atob(arr[1]); let n = bstr.length; const u8arr = new Uint8Array(n); while (n--) u8arr[n] = bstr.charCodeAt(n); return new Blob([u8arr], { type: mime }); }上传接口自己定，但要注意接口的耗时。一次粘贴可能带好几张图，并发上传还是串行上传要看你们服务器的承压能力。我一般用Promise.all+ 3~5个并发控制，避免一次粘贴把服务器连接数打爆。
所有图片上传完成拿到URL后，才算真正具备条件：把处理后的HTML里的<img>的src统一替换成服务器URL，再交给编辑器插入。这里面有个细节——上传途中如果用户又做了别的操作（比如切走了），原来的粘贴上下文可能已经失效，回填时要判断目标编辑器是否还处于可插入状态，否则容易插错位置。
4.3 回填src时，顺手给a标签“体检”
替换src时我必须同时处理外层<a>，不然图片是传上去了，链接却还悬在半空。
我通常的做法是：在上一步提取图片信息时就把href记录好；拿到新URL后，遍历这些记录，找到对应节点，重建外层链接：
function restoreLinks(editorDoc, items, newUrls) { items.forEach((item, index) => { const imgNode = item.node; const newSrc = newUrls[index]; if (imgNode && imgNode.parentElement) { imgNode.setAttribute('src', newSrc); if (item.href) { const a = imgNode.closest('a') || document.createElement('a'); a.setAttribute('href', item.href); if (item.target === '_blank') { a.setAttribute('target', '_blank'); a.setAttribute('rel', 'noopener noreferrer'); } if (imgNode.parentElement !== a) { a.appendChild(imgNode); } } } }); }注意这里有个“体检”的含义：<a>可能已经被清洗器扒掉了一层，也可能被编辑器的schema重新调整过。所以不能假设item.href存在就一定是好的，还要看现在这个<a>还在不在DOM链上。如果不在，就新建一个；如果在，就把关键属性重新设置一遍。这套代码跑下来，我实测了Word、WPS、网页复制三种来源，图片和链接的保留率基本都在100%。
5. 抢救超链接：VML、外层a与编辑器schema的三方角力
5.1 链接藏在Word HTML的哪几个位置
Word的图片超链接，我实际遇到的位置有三个：
第一，最标准的情况：<a>直接包裹<img>或包裹VML结构。这种最好办，顺着节点往上找closest('a')就能拿到href。
第二，VML结构里的<v:shape>有自己的href属性。老版本Word导出时会这样表达，虽然现在逐渐少见，但我还是会在代码里兜底判断：
const href = node.parentElement?.href || node.closest('a')?.getAttribute('href') || node.getAttribute('href') // v:shape可能自带 || node.parentElement?.closest('a')?.getAttribute('href');第三，超链接藏在“图片的上一级容器”外面，比如图片在表格单元格里，真正的<a>包着整个表格或者单元格。这种结构一旦清洗器把表格结构清理掉，链接跟着没了。处理原则是：检测到<a>包着的内容主体是表格或图片时，不要急着拆<a>。
这里要强调一个反直觉的点：链接属性不一定在<img>身上。很多人写代码时只找<a href>，忽略了Word会把链接挂在表格、文本框甚至SmartArt图形上。只处理<img>外层<a>的方案，能解决80%场景，但剩下20%会变成“个别用户反馈链接又丢了”。把位置判断写全，后面少很多麻烦。
5.2 内部书签链接与外部链接分开处理
Word里还有一类链接很特殊：页内跳转书签。复制出来后，href可能是#_bookmark_123这种片段，指向的就是粘贴后的HTML里某个锚点。如果编辑器没保留那个锚点，这个链接就是“死链”。
我碰到的处理方式是分两类：href以#开头的，先检查目标锚点是否存在，存在就保留，不存在就转成无链接的普通文本。这样至少不会出现用户点击后滚动到空白位置的迷惑行为。外部http/https链接则统一补上target="_blank"和rel="noopener noreferrer"，防止当前编辑页被跳走。
mailto:、tel:这类协议也要允许，但必须在最终提交后端前再过一轮协议白名单，避免被滥用。安全过滤这层永远不能省，哪怕它偶尔会误伤个别链接。
5.3 让编辑器允许“带链接的图片”存在
就算我们在处理层把<a>包图片的结构重建好了，编辑器如果不放行，一切白搭。不同编辑器要配的地方不一样：
TinyMCE要在初始化项里显式声明：
tinyMCE.init({ extended_valid_elements: 'a[href|target|rel],img[src|alt|title|width|height]', schema: 'html5', paste_data_images: true });Quill的配置稍微绕一点，需要登记一个自定义blot或通过clipboard.addMatcher手动处理：
quill.clipboard.addMatcher('A', (node, delta) => { // 在delta保留a的href属性，再交给后面的img处理 return delta; });CKEditor则涉及htmlSupport配置。这些配置细节不同版本有差异，写代码前先查当前版本的schema文档比我直接贴配置更可靠。
但配置只是让编辑器“允许”，真正要让链接数据进入最终数据结构，还是要在编辑器自带的粘贴处理器里留一条口子。以TinyMCE为例，paste_preprocess阶段args.content是我们洗净、上传、重建过完整链接的HTML，不要在这个回调里再做一轮破坏性清理。很多团队恰恰是在最后一步又把target、rel删了，前功尽弃。
6. 上线后我遇到的那些边界情况
6.1 从Excel/Word复制整页内容，差点卡死浏览器
需求一开始只要求“从Word粘贴图文”，但真实用户会把Excel表格、PDF转Word的内容、甚至整个网页全选后复制进来。有一次测试人员从Word复制了一份上百页的文档粘贴，clipboardData.getData('text/html')拿到的字符串有快3MB，DOMParser解析、遍历、上传全链路跑完，页面直接卡了十几秒。
后来我加了两道保险：一是对HTML长度做限制，超过2MB直接提示“内容过大，请分段粘贴”；二是对图片数量做限制，超过20张或总大小超过10MB时，走后台分片处理而不是在前端一把梭。不要觉得限制体验不好，等用户浏览器崩了才是更大的体验问题。
6.2 多图并发上传的竞态，导致链接回填串位
并发上传时有个隐蔽bug：我用Promise.all等待所有上传完成，但如果某张图上传失败，Promise.all会直接抛错，导致后面所有图片都不回填，用户看到一堆碎图。后来改成Promise.allSettled，失败的图保留base64，插入时显示一个“图片上传失败”的占位，用户还可以手动点重传。这样至少不打断粘贴主流程。
另外，上传返回URL的顺序和请求发起的顺序不一定一致。回填时绝对不能按“谁先返回先替换谁”的方式处理，必须以之前记录的下标对应。我踩过一次：两张图同时上传，第二张先返回，我把它的URL填到了第一张图头上，结果图文错乱，用户数据全糊了。后来回填代码统一用items数组下标映射，彻底杜绝了错位。
6.3 插入后还会被编辑器二次处理，需要MutationObserver兜底
有些编辑器（尤其是带图片懒加载、自动居中、自动宽度适配的封装版本）会在插入内容后对图片做二次处理。比如TinyMCE的image_list、image_advtab插件，或者你们在editor.insertContent之后又跑了一遍代码美化。这些处理有时会把我们已经重建好的<a>包图片结构拆开。
我的兜底手段是在编辑器完成渲染后用MutationObserver观察，发现图片被重新渲染时，用之前存好的href映射再恢复一次链接。代码不多，但能救很多不知道从哪冒出来的“又丢链接”问题。不过也不要无脑恢复，判断一下目标编辑器内部是否已经有正确的href了，避免循环覆盖。
6.4 图片“上传成功但裂图”的防盗链问题
最后一个很现实的坑是：从Word复制来的图片除了base64，也会带一些外链地址，比如用户在Word里引用了网上图片。上传流程只处理了base64，外链图直接保留原样。结果页面一上线，这些外链图片由于目标站点防盗链策略，全都返回403，用户看到的是一片裂图。
处理方式无非两种：要么在上传前把所有外链图片也抓取转存到自己的服务器（推荐，但要注意外链图片商家的使用协议），要么给外链<img>加上referrerpolicy="no-referrer"碰运气。我自己倾向抓取转存，而不是依赖referrer策略——你永远不知道别人家的防盗链规则什么时候收紧。
这个边界在需求评审里很少被提出来，但线上遇到一次就是数据质量事故。处理链路里加一条“外链图转存”分支，比上线后被人当bug提交要划算得多。
实际操作中还有一个我一直在用的小技巧：整个流程处理完的HTML，在提交给编辑器插入前，先塞进一个不可见的iframe里做一次最终检查，确认每个图片都有正常src、每个链接都有href，再真正插入。多这一步，肉眼可见地降低了线上“粘贴出问题”的工单数量。
