优先用 document.execCommand('fontName', false, 'Microsoft YaHei') 控制字体，需确保选区有效、字体名完整准确，Firefox 已禁用该命令须降级处理，框架中避免 v-model 绑定 contenteditable 并手动同步状态。
用 contenteditable 时如何实时改字体样式
HTML5 可视化编辑最常用的方式是给元素加 contenteditable="true"，但它本身不提供字体控制 UI，必须配合 document.execCommand() 或现代替代方案。注意：该 API 已废弃，但目前仍是多数轻量编辑器的实际选择。
常见错误是直接操作 DOM 样式（比如改 style.fontFamily），这会导致选区丢失、嵌套标签混乱，或在 Chrome 中触发不可预测的 HTML 结构重写。
- 优先用
document.execCommand('fontName', false, 'Microsoft YaHei')控制字体族，它会自动包裹选中文本为或插入（取决于浏览器） - 若需支持中文字体，务必在参数里传完整字体名（如
'SimSun'、'Noto Sans SC'），不能只写'sans-serif'—— 否则用户看不到变化 - 执行前必须确保有焦点且存在有效选区：
if (window.getSelection().rangeCount > 0)，否则命令静默失败
为什么 execCommand 设置的字体在 Firefox 里不生效
Firefox 自 2020 年起默认禁用大部分 execCommand 样式类命令（包括 fontName、fontSize），仅保留基础格式（如 bold、insertUnorderedList）。这不是 bug，是主动限制。
绕过方法只有两个：
立即学习“前端免费学习笔记（深入）”；
- 改用
Selection+Range手动包裹：获取当前选区，创建，设置style.fontFamily，再用range.surroundContents() - 引入
iframe+designMode = 'on'模式（兼容性更好，但维护成本高，且无法和现代 CSS-in-JS 生态无缝集成）
别指望加 about:config 开关解决 —— 用户环境不可控，生产环境必须降级处理。
用 CSS @font-face 加载自定义字体后怎么让编辑器识别
即使你已通过 @font-face 正确声明了字体，execCommand 仍不会自动列出它；编辑器 UI 的字体下拉菜单需要手动维护字体列表，不能依赖系统枚举。
- 把可用字体写死在 UI 下拉项中：
['Arial', 'SimHei', 'Noto Sans SC', 'LXGW WenKai']，每个选项对应一个execCommand调用 - 若字体文件较大（如思源黑体 > 10MB），避免在初始化时就加载全部，应按需
new FontFace()+load()，再更新下拉菜单状态 - 注意字体名称大小写敏感：CSS 中定义的是
font-family: 'LXGW WenKai'，JS 里就必须传完全一致的字符串，多空格或单双引号不匹配都会回退到默认字体
React/Vue 项目里绑定字体下拉框的坑
框架的响应式绑定（如 Vue 的 v-model 或 React 的 useState）容易掩盖原生编辑行为。典型现象：选中文字 → 点击下拉 → 字体变了，但光标跳到开头，或刚设的字体被框架 diff 覆盖。
- 不要用
v-model绑定contenteditable元素的值 —— 它不是表单控件，没有value属性 - 下拉框
change事件中，先调用document.execCommand，再手动同步状态（如setFontFamily('Noto Sans SC')），而不是反过来 - 如果用了
dangerouslySetInnerHTML或v-html渲染内容，字体样式会被清空 —— 必须从 HTML 字符串里解析并重建style或font标签
可视化编辑的字体控制从来不是纯前端样式问题，它卡在 DOM 操作、浏览器差异、框架生命周期和字体加载时机四者的交界上。少一个环节对齐，用户就会看到字体闪一下又变回去。
