必须将styleWithCSS设为true，否则foreColor会生成废弃的<font>标签；它应前置调用一次，确保输出style="color: #rrggbb;"格式，且仅支持小写十六进制颜色值。
document.execCommand 在现代富文本编辑中已弃用，但仍是当前绝大多数 contenteditable 编辑器实际依赖的底层机制；若你正做颜色功能开发，得先接受这个现实——不是“要不要用”，而是“怎么用得稳、不翻车”。
为什么 styleWithCSS 必须设为 true
默认情况下，document.execCommand('foreColor', ...) 会生成 <font color="#ff0000"> 这类 HTML 标签。而 <font> 是 HTML5 废弃标签，不仅语义错误，还会在 SSR、无障碍读屏、Lighthouse 审计中触发警告或失败。
设 document.execCommand('styleWithCSS', false, true) 后，同个 foreColor 命令才会输出 style="color: #ff0000;" ——这是唯一能被现代 CSS 规则继承、覆盖、调试的格式。
- 必须在调用
foreColor前执行一次，且只需一次（不是每次都要） - Chrome/Firefox/Edge 都支持，但 Safari 16.4+ 才稳定支持
styleWithCSS的true模式 - 别写成
document.execCommand('styleWithCSS', true, true)——第二个参数是showUI，传true会弹原生对话框（已废弃，实际无效）
foreColor 参数只认十六进制，不认 RGB/HSL
即使你用 <input type="color"> 拿到的是 #ff6b35，也得确保传给 foreColor 的值严格符合 #RRGGBB 或 #RGB 格式。传 rgb(255, 107, 53) 或 hsl(14, 100%, 60%) 会静默失败：文字不变色，控制台也不报错。
立即学习“前端免费学习笔记（深入）”；
- 用户选色后，可用
input.value直接取值，它始终返回 7 位十六进制（如#ff6b35） - 如果后端或配置里存的是 RGB 字符串，务必先转成十六进制再传 —— 浏览器不帮你自动转换
- 注意大小写：
#FF6B35和#ff6b35都行，但#FF6B35在某些旧版 Android WebView 中偶有解析异常，统一小写更稳妥
颜色生效但立刻被清空？检查 selection 是否丢失
富文本编辑中常见现象：点一下颜色按钮，文字闪红一下就变回默认色。根本原因不是命令没执行，而是执行完后浏览器重置了 selection，导致后续输入或光标移动时样式被“冲掉”。
- 调用
foreColor后，立即用getSelection()+range.cloneRange()保存当前 range，再在必要时 restore - 更简单做法：在
contenteditable元素上监听input事件，一旦检测到内容变化，立刻重新 apply 最近一次选中的颜色（需缓存颜色值） - 别依赖
focus或blur事件来恢复 selection —— 它们触发时机不可控，尤其在移动端软键盘弹起时
暗色模式下文字看不清？别只改 color
富文本区域常嵌在深色背景容器中（比如暗色主题面板），此时若用户选了浅灰 #999，在深灰背景上几乎不可读；反之亦然。仅靠前端 JS 设置颜色无法感知系统偏好。
真正可控的做法是：给 contenteditable 容器加一个 class（如 rich-editor），然后在 CSS 中用 @media (prefers-color-scheme: dark) 主动约束可选色域：
.rich-editor {
color: #333;
}
@media (prefers-color-scheme: dark) {
.rich-editor {
color: #e0e0e0;
}
/* 强制限制用户选色按钮的默认值 */
.color-picker { filter: brightness(0.8); }
}关键点在于：富文本的颜色逻辑不能脱离宿主环境独立存在；所谓“用户自定义”，前提是定义空间本身已被上下文安全围栏限定过。
