navigator.clipboard.writetext()仅支持text/plain格式，无法保留超链接、加粗等样式，因外部应用（如word、notes）只解析text/html或cf_html；需用write()配合含text/plain与合法text/html（含startfragment等结构）的clipboarditem实现富文本复制。
navigator.clipboard.writeText() 只能写纯文本，富文本必须用 navigator.clipboard.write() + ClipboardItem；直接调用会失败，不处理 MIME 类型或 HTML 结构，粘贴到 Word 或 Notes 里就只剩白板。
为什么 navigator.clipboard.writeText() 无法复制超链接或加粗文字
它底层只写入 text/plain 格式，浏览器和外部应用（如 Word、备忘录、微信）读取时完全忽略 HTML 标签。哪怕你传入 "<b>加粗</b>和@#@#@#@#@#@#@#@#@#@0"，粘贴出来就是加粗和链接——纯字符，无样式、无跳转。
真正保留格式，得手动构造符合 Windows CF_HTML 规范的剪贴板数据，或让浏览器自动打包成多格式（text/plain + text/html）。
- 现代 API 不自动“升格”字符串为 HTML，必须显式提供
text/html类型数据 - Word、Outlook、Apple Notes 等只信任
text/html（或CF_HTML）里的结构，text/plain是 fallback，仅用于纯文本编辑器 - 直接
writeText()后粘贴进contenteditable元素，也可能丢失换行或缩进——因为没声明 HTML 语义
怎么用 navigator.clipboard.write() 写入带样式的 HTML
核心是创建 ClipboardItem，把同一段内容以不同 MIME 类型塞进去：一份纯文本兜底，一份 HTML 版本保格式。
注意：HTML 字符串必须包含完整片段头（<!--StartFragment-->）、<meta> 声明和合法包裹结构，否则某些应用（尤其是 Windows 端）会拒绝解析。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 不要直接传
<b>hello</b>—— 缺少CF_HTML头部，Word 会当纯文本处理 - 必须生成类似这样的最小合法 HTML 片段：
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><!--StartFragment--><b>hello</b><!--EndFragment-->
- 用
new ClipboardItem({ 'text/plain': new Blob(['hello'], {type: 'text/plain'}), 'text/html': new Blob([htmlString], {type: 'text/html'}) }) - 必须
await navigator.clipboard.write([clipboardItem])，不能漏掉数组包装
监听 paste 事件时如何安全读取富文本（含图片）
用户 Ctrl+V 粘贴混合内容（比如从网页复制一段带图文字），navigator.clipboard.readText() 只拿到纯文本，会丢图；要用 read() 拿 ClipboardItem 数组，再逐个检查 types。
但注意：不是所有浏览器都允许在任意 paste 事件中调用 read() —— Safari 直到 16.4 才放开，且必须 HTTPS/localhost；Chrome/Firefox 要求用户已触发粘贴动作（即事件本身是合法入口）。
- 务必先
event.preventDefault()，否则浏览器默认行为会覆盖你的解析逻辑 - 对每个
item，用item.types.includes('text/html')判断是否有 HTML 版本，优先取它；没有就退到text/plain - 读图片需
item.getType('image/png')或'image/jpeg'，返回Blob，再用URL.createObjectURL()转成可显示地址 - 别忘了
try/catch—— 用户可能粘贴了加密 PDF 或受保护内容，read()会直接 reject
contenteditable 是最省事的富文本粘贴方案，但有隐藏代价
给一个 <div contenteditable="true"></div>，用户 Ctrl+V 自动解析 HTML、插入图片、保持段落结构——这确实是零 JS 的最优解。但它绕过了你对内容的控制权。
问题不在“能不能用”，而在“用了之后你还能不能干预”。比如：你想过滤 script 标签、限制图片大小、自动转 base64、或统一 class 命名——这些都得在粘贴后 DOM 已渲染完再扫描修补，极易出竞态。
- 粘贴瞬间触发
input或DOMSubtreeModified（已废弃）不可靠；推荐监听mutationObserver+ 节流 - 移动端 Safari 对
contenteditable的图片粘贴支持不稳定，常出现空白或加载失败 - 部分国产信创系统（如统信 UOS、银河麒麟）的 WebView 内核对
contenteditable富文本粘贴兼容性差，仍需降级到read()手动解析
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
