user-select: none 在 contenteditable 区域无效是浏览器规范行为，因编辑态选择逻辑由编辑引擎接管，CSS 控制被绕过；需用 contenteditable="false" 或外置 DOM 配合 pointer-events: none 实现禁选。
user-select: none 在 contenteditable 区域里为什么无效
它根本不会生效——contenteditable="true" 的元素（包括富文本编辑器的根容器或内部 div、span）会直接忽略 user-select 声明。这不是 bug，是浏览器规范行为：编辑态下选择逻辑由编辑引擎接管，CSS 层面的控制被绕过。
常见错误是给整个编辑器容器加 .editor { user-select: none }，结果用户照样双击选中标题、拖拽高亮段落。真正起效的前提是：目标必须是普通静态文本容器，而非处于编辑上下文中的节点。
- 若需保护某段文字（如水印、版权提示），应将其放在编辑器外层 DOM，用
pointer-events: none+user-select: none双重包裹 - 若必须嵌入编辑器内部（比如只读区块），得用
contenteditable="false"显式声明，并确保父级没意外继承contenteditable="true" - React/Vue 中动态渲染的编辑器内容，若 class 切换后样式不更新，检查是否因虚拟 DOM 复用导致 style 未重置；可加
key强制重建节点
如何让编辑器里部分区域“视觉不可选”但保持功能正常
核心思路是分离「可编辑性」和「可选中性」：禁选 ≠ 禁编辑。对需要保留编辑能力但阻止误选的区域（如工具栏按钮、浮动菜单文字），不要碰 user-select，而是用更稳妥的组合：
- 按钮文字、图标用
span或button标签，本身默认不可选；若用了div，加user-select: none即可，不影响点击 - 编辑器内嵌的只读说明块（如“请输入标题”提示），用
contenteditable="false"+user-select: none，并确保其不在contenteditable="true"的子树内被继承覆盖 - 避免给
input、textarea设置user-select: none——它不起作用，还可能干扰光标定位；改用readonly或disabled控制输入行为
移动端长按弹窗绕过 user-select 的真实对策
iOS Safari 和部分 Android 浏览器在长按时仍会触发系统复制菜单，哪怕已设 user-select: none。这是因为长按事件发生在 selection API 之前，CSS 无法拦截。
立即学习“前端免费学习笔记（深入）”；
必须叠加以下两层防护：
- 加
-webkit-touch-callout: none抑制 iOS 长按气泡菜单（仅对非表单元素有效） - 监听
touchstart并调用e.preventDefault()，但仅限非输入区域——否则会废掉所有文本框聚焦 - 注意：Chrome 90+ 中，
contenteditable内部的selectstart事件常被忽略，此时user-select: text是唯一保底手段，别依赖 JS 拦截
别把 user-select 当权限开关用
它只是交互层的视觉限制，不是安全边界。用户删掉这行 CSS、禁用样式、或直接从 Network 面板扒 HTML，内容立刻暴露。真要防复制，得靠服务端权限控制 + 敏感内容延迟加载 + 水印叠加（非 CSS 实现）。
最易被忽略的一点：无障碍支持。屏幕阅读器不依赖选中行为，但键盘用户靠 Tab 导航时，若你用 user-select: none + pointer-events: none 一起封死，会导致焦点丢失、语义断裂。该区域必须保留 tabindex="0" 和明确的 role。
