真正控制文本能否被选中的是 user-select 属性和真实文本节点的存在性；伪类如 :hover 不影响选择能力，::selection 仅对已可选文本生效且需三份前缀并列声明。
伪类本身不选中文本节点，它只是匹配元素并应用样式——真正决定“哪些字符能被选中”的，是 DOM 结构和 user-select 行为。
伪类（如 :hover、:focus）根本不参与文本选择流程
它们只在满足条件时给元素添加样式规则，和鼠标拖选、键盘选区计算完全无关。比如 p:hover::selection 能改颜色，但前提是 p 里的文本本来就能被选中；如果父元素设了 user-select: none，再多个 :hover 也救不回来。
常见误判场景：
- 以为
span:nth-child(2):hover能让第二个 span 的文字“变可选”——其实 hover 只触发背景色变化，不影响 selection 能力 - 在
div:has(> .highlight)上写user-select: text，却忘了该属性不继承，子元素仍可能被默认值或上级none覆盖
::selection 生效的前提：文本必须先能被选中
这个伪元素不是“让内容可选”，而是“对已选中的内容重绘样式”。它连生效门槛都卡得严：
立即学习“前端免费学习笔记（深入）”；
- 父级任意一层设
user-select: none→ 整块内容不可选，::selection彻底失效 - 用了
<input>或<textarea></textarea>→ 浏览器强制接管选中逻辑，自定义::selection基本被忽略（Chrome 99+ 对textarea有极有限支持） - 在 Shadow DOM 或 Vue
<style scoped></style>里声明 → 规则作用域隔离，::selection不会穿透到内部文本
写法上还必须三份并列：::-moz-selection、::-webkit-selection、::selection，顺序不能错，否则旧版 Safari 直接不认。
真正控制“能否选中”的，是 user-select 和 DOM 节点类型
可选性由两个底层机制决定：
-
user-select属性：只作用于**真实元素节点**，且不继承（需显式设置到含文本的容器或文本节点父级） - 文本节点存在性：伪元素（
::before/::after）生成的内容根本不在 DOM 中，浏览器选区引擎压根看不到它——哪怕视觉上紧贴文字，Shift+→也会跳过
所以当你发现某段文字“看起来像能选但点不动”，优先检查：
- 用 DevTools 的 Elements 面板确认目标文字是否包裹在真实
span、p等节点里，而不是靠content: attr(data-tip)渲染 - 右键「检查元素」后，在 Styles 面板搜索
user-select，看是否被某层父元素设为none - 如果是动态插入内容，确认 JS 没有在渲染后意外覆盖了
user-select值
最常被忽略的一点：伪类和伪元素是两套东西。:hover 是状态匹配，::before 是渲染指令，而文本可选性只取决于“那里有没有一个真实的、未被禁用的文本节点”。想让内容可选，就得让它进 DOM；想让它样式可控，再叠加伪类也不迟。
