能，但需确保contenteditable元素已聚焦且选区在其内；否则静默失败。queryCommandState('bold')可判断状态，但仅支持二态，不区分标签或CSS样式。
document.execCommand('bold') 能不能直接封装成 toggleBold() 函数
能，但必须加两道防护：确保目标 contenteditable 元素已聚焦，且当前选区属于它。浏览器只对「有焦点 + 选区在 editable 内」的组合响应 execCommand。否则调用静默失败，不报错也不生效。
常见错误现象：execCommand('bold') 看似执行了，但文本没变化；或点击按钮后光标跳到页面顶部。
- 检查是否调用
element.focus()（不是click()）让编辑区获得焦点 - 避免在
blur事件中调用，此时选区已丢失 - 不要依赖
document.activeElement判断——它可能返回body或input，而非你的编辑容器
如何判断按钮该显示“已加粗”还是“未加粗”状态
document.queryCommandState('bold') 是唯一可用的判断方式，但它只返回 true / false，且有严格前提：
- 必须在调用前确认
document.hasFocus()为true - 选区必须完全落在一个
contenteditable区域内（不能跨多个 editable 元素） - 如果选区横跨加粗与非加粗文本（比如「hello world」中选中全部），它返回
false，这是设计行为，不是 bug - 它不区分
<strong>和<b>，也不识别font-weight: bold的 CSS 样式
所以按钮 UI 只能做二态（开/关），不能做三态（全加粗/部分加粗/无加粗）。
立即学习“前端免费学习笔记（深入）”；
为什么 execCommand('italic') 有时插入 <i>，有时插入 <em>
浏览器决定用哪个标签，不归你控制。Chrome、Edge 默认用 <em>，旧版 Safari 曾用 <i>，Firefox 行为随版本浮动。这不是 bug，是 spec 允许的实现自由度。
如果你需要统一语义（比如强制用 <strong> 和 <em>），execCommand 无法满足。此时必须放弃它，改用 getSelection() + Range.surroundContents() 手动包裹，或直接接入 ProseMirror/Lexical。
- 手动操作要处理边界情况：选区为空、跨 block、包含
img或input等不可包裹节点 -
execCommand的优势是自动处理这些——代价是失去标签控制权 - 兼容性上，
execCommand在所有现代浏览器中仍 100% 可用，包括 Safari 17+（2026 年实测）
封装时要不要 try/catch 捕获 execCommand 报错
不用。它从不抛异常，失败时静默返回 false。真正要 guard 的是前置条件：
- 目标元素是否存在且为
contenteditable - 是否已调用
.focus() - 是否在用户交互事件（如
click）中调用（否则 Safari 会拒绝执行）
最易被忽略的一点：Safari 要求命令必须由用户手势触发（click、keydown），不能由 setTimeout 或 Promise 回调触发——哪怕只延迟 0ms，也会失效。
