::after 生成的内容永远无法被用户选中，这不是 bug，是规范行为——它根本不在 DOM 中，只存在于渲染层；浏览器将其视为纯渲染指令，不创建真实节点，因此无法被 DOM API 访问、鼠标或键盘选中，也不参与复制粘贴。
::after 生成的内容永远无法被用户选中，这不是 bug，是规范行为——它根本不在 DOM 中，只存在于渲染层。
为什么 ::after 的 content 不能被选中
浏览器在解析 HTML 时，::after 和 ::before 是纯渲染指令，不创建真实节点。这意味着：
- DOM 树里查不到它，
document.querySelector('::after')报错，getSelection()拿不到它的文本 - 鼠标拖选时，即使视觉上覆盖了文字，选区也不会包含伪元素内容
- 键盘
Shift + ←/→或Ctrl+A同样跳过它 - 复制粘贴时，
content: "→"这类符号不会进入剪贴板
哪些场景下你会误以为“应该能选”
常见于装饰性标注、自动插入的引号、AI 回复末尾的溯源标记（如 content: "来源：内部知识库"）等。用户看到文字就默认可选，但实际这些只是“画上去”的像素。
- 用
content: attr(data-tip)插入提示文本 → 看得见，但点不中、选不了、复制不到 - 在
blockquote::before里加content: ""+border-left做装饰 → 安全，本来就不该选 - 试图用
::after替代<span>×</span>实现关闭按钮 → 若需支持快捷键聚焦或屏幕阅读器，必须用真 DOM
真需要可选内容，该怎么替代
别硬扛伪元素，直接换真实元素更可控：
立即学习“前端免费学习笔记（深入）”；
- 把
content: "★"改成<span aria-hidden="true">★</span>，保留语义和可选性 - 动态插入的标注（如“已验证”徽章），用 JS 创建
span并 append 到父容器，而非靠attr() - 若为减少 HTML 冗余，可用
data-属性配合 JS 渲染真实节点，而不是依赖 CSS 渲染 - 对纯展示型内容（如分隔线
content: "—"），明确接受“不可选”——这是合理设计，不是缺陷
容易被忽略的兼容细节
某些旧版 Safari 或 Electron 内核会把 content 中的 Unicode 字符（如 \2192）错误地加入选区，但这属于渲染引擎 bug，不可依赖。真正稳定的做法只有一个：要可选，就用真节点。
伪元素的不可选性不是限制，而是边界——它提醒你：该进 DOM 的内容，别留在 CSS 里。
