伪类顺序错误会导致选择器不匹配而非样式覆盖；正确顺序应为状态类（:disabled）在前、交互类（:hover/:focus）在后，且需兼顾特异性、浏览器兼容性与设备环境。
伪类顺序写错会导致样式不生效
浏览器按 CSS 选择器的「特异性」和「声明顺序」决定最终样式，而多个伪类连用时（比如 :hover + :focus + :disabled），顺序本身不影响特异性计算，但会影响「是否匹配成功」——因为伪类是逻辑与关系，一旦某个伪类在当前状态下不成立，整个选择器就失效。最典型的坑是把 :disabled 放在前面：button:disabled:hover 永远不会触发，因为禁用状态下的按钮无法获得 hover。
-
:hover、:focus、:active这类交互伪类必须放在:disabled或:read-only之后，否则禁用态下交互伪类无意义，整条规则被跳过 - 可访问性相关伪类如
:focus-visible建议紧接在:focus后面，避免被覆盖或逻辑冲突 - 伪类组合中，状态类（
:disabled、:checked）优先于交互类（:hover、:active），这是约定俗成的可读性和可靠性保障
CSS 里 :not() 和其他伪类混用时顺序更敏感
:not() 的参数本身是个选择器，如果里面嵌套了其他伪类，而外部又叠加了伪类，顺序一乱就容易误判匹配逻辑。比如 input:not(:disabled):hover 是对的，但写成 input:hover:not(:disabled) 虽然语法合法，语义却变成「先 hover 再判断是否禁用」——实际效果一样，但可读性差，且某些旧浏览器（如 Safari 15.4 之前）对这种写法解析不稳定。
-
:not()尽量包住整个状态判断，例如用button:not(:disabled):hover，而不是把:hover放外面 - 避免在
:not()里写复合伪类，比如:not(:hover:focus)是无效语法；CSS 不支持伪类逻辑或，只支持单个简单选择器 - Chrome 120+ 开始支持
:has()，但它不能和伪类共用于同一选择器链开头，这类新特性叠加时更要检查浏览器兼容表
伪类优先级不是靠顺序“压过”其他规则
很多人以为把 :hover 写在后面就能“覆盖”前面的普通样式，其实不是。伪类本身不增加特异性权重，button:hover 和 button 的特异性一样（都是 0,1,1），真正起作用的是「声明位置靠后 + 特异性相同」。所以问题常出在：你写了 button:hover { color: red; }，但另一处有 .btn-primary { color: blue; }，后者特异性更高（0,1,1 vs 0,1,0），hover 就赢不了。
- 检查是否被更高特异性的规则压制，而不是怪伪类顺序 —— 打开 DevTools 看 Styles 面板里哪条被划掉、为什么
- 不要靠疯狂加
!important解决，优先提升伪类选择器的特异性，比如改用button.btn:hover - 用
[disabled]属性选择器替代:disabled有时更可控，因为属性选择器和伪类特异性相同，但行为更稳定
移动端 touch 设备上 :hover 可能根本不触发
iOS Safari 和部分 Android 浏览器在非悬停设备上会延迟或忽略 :hover，尤其当页面没声明 viewport 或用了 touch-action: manipulation。这不是顺序问题，而是环境限制——你以为写了 button:hover:focus 就万无一失，结果用户点一下根本没反应。
- 真要兼容触控，优先用
:active做按下反馈，它在所有主流移动浏览器中都可靠 - 不要依赖
:hover实现关键功能（比如显示菜单），那应该用 JS 控制 class 切换 - 可以用
@media (hover: hover)包一层，把纯 hover 样式隔离，避免在不支持设备上浪费解析
事情说清了就结束。伪类顺序不是魔法开关，它背后是匹配逻辑、特异性规则和运行时环境三重约束。最容易被忽略的是：你以为在调样式顺序，其实是在调试 DOM 状态是否允许那个伪类成立。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
