contentEditable属性仅启用元素可编辑状态，不提供格式化功能；真正实现加粗、列表等操作需配合document.execCommand或Selection/Range API。
contentEditable 本身不提供格式化命令，它只是让元素可编辑；真正执行加粗、列表等操作的是 document.execCommand 或现代的 Selection/Range API。
为什么直接写 contenteditable="true" 没反应
常见错误是只加了属性，却没处理焦点和交互逻辑：
- 没设
tabindex="0"，键盘无法聚焦（尤其在<div>上） - 没监听点击或回车，导致光标不出现或插入
<div>而非<p> - 父容器用了
display: flex或overflow: hidden，意外截断光标渲染 - 移动端点一下就失焦，需额外加
touchstart阻止默认行为并手动focus()
document.execCommand 还能用吗？参数怎么填
能用，所有主流浏览器（Chrome 120+、Firefox、Safari）仍支持，但 MDN 已标记为 deprecated。基础命令稳定，关键在参数写法：
-
'bold'必须全小写，'Bold'或'BOLD'静默失败 - 第二个参数恒为
false（浏览器忽略，但必须传） - 第三个参数按命令类型填：
null（如'bold'）、颜色字符串（'foreColor'）、HTML 字符串（'insertHTML'）、块级标签名（'formatBlock'传'<h2>'） - 空选区触发
'insertUnorderedList'会生成空<ul></ul>，建议先用getSelection().toString()判断是否为空
工具栏按钮点击后没生效的典型原因
按钮只是触发器，真正起作用的是三步链路：聚焦 → 获取选区 → 执行命令。漏掉任一环都会失效：
立即学习“前端免费学习笔记（深入）”；
- 没提前调用
editor.focus()，尤其在弹窗、Tab 切换后，焦点可能在别处 - 用户没选中文本，但代码直接执行
execCommand('bold')—— 它会在光标处插入格式标签，而非包裹文字 - 编辑区被
iframe或 Shadow DOM 包裹，document.execCommand作用域错乱，需确保调用时document是目标上下文 - 用了
<pre>或<code>作为编辑容器，它们默认禁用换行和样式，execCommand对其无效
想长期维护，现在就得避开哪些坑
不是所有问题都能靠 execCommand 解决，越早考虑降级路径越省事：
- 不要依赖它插入链接：
execCommand('createLink', false, url)在 Chrome 中会把整个块级元素转成<a>，应改用Range.surroundContents()手动包裹文本节点 - 避免混合使用
<font>和<span style>，两者语义冲突且清理困难；统一用<strong>、<em>、<mark>等语义化标签 - 粘贴富文本时，
paste事件拿到的 HTML 可能含script或onerror，必须用正则或DOMParser清洗，否则 XSS - 移动端 iOS Safari 的
execCommand对'formatBlock'支持极差，建议检测navigator.platform.includes('iPhone')后 fallback 到纯文本换行
最麻烦的其实是“看起来正常但语义崩坏”——比如用 <b> 代替 <strong>，或让编辑区输出带内联样式的 <span style="font-weight:bold">。这些在视觉上没问题，但对屏幕阅读器、SEO、后续 DOM 解析全是隐患。动手前先想清楚：你要的到底是“能显示加粗”，还是“能被正确理解的强调”。
