应使用PCRE的(?(DEFINE)…)定义命名子模式再引用，而非单行硬编码；伪类需单独定义如nth-child([^)]*)等，主模式用(?&selector)(?&pseudo_class)组合，配合/x修饰符提升可读性。
PHP正则怎么匹配含伪类的完整CSS选择器
直接用 preg_match() 匹配带 :hover、::before 这类伪类的选择器，不能靠简单分组硬套——伪类本身有语法层级和嵌套规则，而 CSS 规范里伪类/伪元素是选择器的“修饰部分”，不是独立 token。
常见错误现象：写 /^[a-zA-Z][\w.-]*(\.[a-zA-Z][\w.-]*)*(#[a-zA-Z][\w.-]*)?(:[a-zA-Z][\w-]*)?$/，结果 div:hover 能过，但 a:nth-child(2n+1) 或 input::placeholder 全挂掉。
- 伪类名本身允许括号（如
:nth-child()）、连字符（:first-of-type）、双冒号（::），且括号内还可嵌套表达式 - 一个合法选择器可能含多个伪类，如
button:hover:disabled，中间无空格，但不能跨伪类断开匹配 -
[:]在正则中是特殊字符，不转义会破坏模式；而伪类括号里的内容（如2n+1）不是固定格式，无法穷举
用 PCRE 的 (?(DEFINE)…) 提前定义伪类子模式
与其试图一行写完，不如把伪类部分拆出来单独定义，再在主模式里引用。PHP 的 PCRE 支持条件子组和命名子组，配合 (?(DEFINE)…) 可以提升可维护性。
示例：只覆盖常用伪类，不追求 100% CSS spec 兼容，但能稳定识别结构
立即学习“PHP免费学习笔记（深入）”；
$pattern = '/
^(?&selector)
(?:\s*[\+>\~]\s*(?&selector))*
(?:\s*:\s*(?&pseudo_class))*
(?:\s*::\s*(?&pseudo_element))*
(?<DEFINE>
(?<selector>[a-zA-Z][\w.-]*(?:\.[a-zA-Z][\w.-]*)*(?:#[a-zA-Z][\w.-]*)?)
(?<pseudo_class>hover|focus|active|visited|disabled|checked|nth-child\([^)]*\)|not\([^)]*\))
(?<pseudo_element>before|after|first-letter|placeholder)
)/x';
-
x修饰符启用空白忽略和注释，让长模式可读 -
(?<DEFINE>…)不参与匹配，只做命名子模式声明 - 真正匹配时用
(?&xxx)引用，避免重复书写和逻辑耦合 - 括号内容用
[^)]*粗略兜底，不解析内部结构，防崩溃即可
为什么不用 preg_match_all 逐段提取再拼接
有人想先用 preg_match_all('/[a-zA-Z#.\[][^{]+/', $css, $matches) 拆出所有“疑似选择器片段”，再人工合并——这在实际项目里容易翻车。
- CSS 选择器里可能含属性选择器，如
input[type="submit"]，其中的引号和等号会被误切 - 伪类括号嵌套时（如
:not(:hover)），正则不支持递归匹配，[^)]*会提前截断 - 选择器组合符（
+、>、~）前后空格不固定，靠空格分割不可靠 - 真实 CSS 文件里还有注释
/* … */、换行、缩进，简单正则根本没法 clean
真要解析完整 CSS，该上 scss 或 postcss 的 AST 解析器，而不是硬扛正则。
实际项目中更推荐的替代路径
如果你只是想从 CSS 字符串里抽取出“所有顶层选择器”（比如用于构建 class 白名单或做样式隔离），别死磕正则——用现成工具更稳。
- 用
symfony/css-selector组件，它专为解析 CSS 选择器设计，支持全部伪类、组合符、属性选择器，返回结构化数组 - 若仅需轻量级，可用
vlucas/php-css-parser，它能 tokenize 并保留原始结构，比手写正则少踩 80% 的坑 - 自己写正则只适合明确边界场景：比如只匹配
.btn-*类名前缀，或提取所有#id，这时用/#[a-zA-Z][\w-]*/就够了
伪类语法的复杂度不在正则能力之外，而在它本就不是正则该解决的问题——就像不用正则去 parse JSON。
