user-select 是控制文本可选状态的提示属性，非绝对禁用开关；它对 input、textarea 无效，无法阻止 Ctrl+A 或 JS 全选，需结合 HTML、JS 及无障碍方案综合处理。
user-select 属性在现代浏览器中的实际行为
user-select 并不是“禁止选中”的开关，而是一个控制文本可选状态的提示属性。浏览器最终是否允许选中，还取决于元素类型、焦点状态、用户操作（如双击、拖拽）以及是否被其他样式或脚本覆盖。
常见错误是以为设置 user-select: none 就能彻底阻止所有选中行为——实际上它对 <input>、<textarea> 无效，也无法阻止通过开发者工具手动触发的 document.getSelection().selectAllChildren() 调用。
-
user-select: none：禁用鼠标拖选和双击选词，但键盘Ctrl+A仍可能生效（尤其在可聚焦容器内） -
user-select: text：显式恢复可选，常用于覆盖父级none -
user-select: contain：允许在该元素内选中，但不会跨出边界（Chrome/Edge 支持，Firefox 不支持） -
user-select: all：点击即全选内容（适合代码片段、token 类展示）
如何真正阻止用户选中文本（含兼容性兜底）
单靠 CSS 不够，必须配合 HTML 和 JS 才能覆盖全部路径。核心思路是：阻断触发源 + 清除已有选区 + 防止键盘全选。
- 给目标元素加
user-select: none，同时设置-webkit-user-select: none、-moz-user-select: none、-ms-user-select: none - 移除
tabindex或设为-1，避免键盘聚焦后触发Ctrl+A - 监听
selectstart事件并e.preventDefault()（注意：该事件不冒泡，需绑定到具体元素） - 在关键交互后调用
window.getSelection().removeAllRanges()清除残留选区
element.addEventListener('selectstart', e => e.preventDefault());
// 注意：不要写成 document.addEventListener('selectstart', ...) —— 它不会捕获到
哪些场景不该用 user-select: none
盲目禁用文本选择会损害可访问性和基础功能。以下情况应保持默认或谨慎评估：
立即学习“前端免费学习笔记（深入）”；
- 按钮、卡片等纯交互容器内嵌了需要复制的 ID、URL、错误码等文本
- 表格行使用
user-select: none后，用户无法复制整行数据做排查 - 富文本编辑器预览区禁用后，测试人员无法快速选中报错文案提交 issue
- 响应式页面中，移动端长按本应唤起「复制/搜索」菜单，
none会直接禁掉整个原生菜单
替代方案：比禁止更友好的交互设计
真正的问题往往不是“用户选中了”，而是“选中后误触发后续动作”或“视觉干扰”。这时候优先考虑降级体验而非封锁能力：
- 用
pointer-events: none配合user-select: none禁用点击+选中，但保留cursor: default视觉反馈 - 对代码块等需复制的内容，改用
user-select: all+ 点击自动复制（监听click后执行navigator.clipboard.writeText()） - 在 hover 状态下才显示「复制」图标，点击后高亮并复制，既减少干扰又提升可控性
最易被忽略的一点：禁用 user-select 后，屏幕阅读器（如 VoiceOver）可能跳过该文本节点，导致无障碍访问失败。如果内容有语义价值，必须用 aria-label 或 aria-hidden="false" 显式补全。
