最稳做法是先用preg_replace('//*\s\S?*//s', '', $css)清除所有注释（含跨行），再用preg_match_all('/([a-z-]+)\s*:\s*([^;{]+)(?=;|$)/i', $clean_css, $matches)提取属性；需注意BOM头干扰及复杂值的后续解析。
PHP正则怎么安全匹配CSS属性而不被/* ... */注释干扰
直接用preg_match_all()提取property: value时，如果CSS里有/* color: red; */这种注释块，很容易把注释里的属性也抓出来——这不是你想要的。核心思路不是“跳过注释”，而是“只在非注释区域匹配”，否则正则会误判换行、嵌套或不闭合注释。
- 别试图用负向先行断言（如
(?）去“避开”注释开头——CSS注释可能跨多行，且<code>/*和*/之间内容不可预测，正则无法可靠回溯 - 先用
preg_replace()移除所有/* ... */块（包括跨行），再提取属性，是最稳的做法 - 注意
.*默认不匹配换行，必须加s修饰符；同时要非贪婪匹配，否则/\*.*\*/会吞掉两个注释之间的全部内容
示例清理代码：
$clean_css = preg_replace('/\/\*[\s\S]*?\*\//', '', $css);这里[\s\S]比.*更可靠，能覆盖换行符；?确保非贪婪，避免吃掉多个注释之间的合法规则。
为什么不能用preg_match()边匹配边排除注释
因为PCRE不支持“在匹配过程中动态跳过某段文本”的语法。你写/(?!\/\*)[^{};]*/这类断言，只能检查当前位置是否紧邻/*，但无法感知当前是否已处于注释块内部——而CSS注释可以嵌套在选择器、值甚至URL里（虽然标准不推荐，但真实文件常见）。
- 真实场景中，
background: url("data:image/svg+xml;utf8,<svg xmlns="http://www.w3.org/2000/svg">/* not a comment */</svg>");这种写法会让任何试图靠/*定位注释起始的正则崩溃 -
preg_match_all()的PREG_OFFSET_CAPTURE模式也无法帮你判断某个匹配位置是否落在已知注释区间内——你需要额外维护一个注释位置数组，成本远超预处理
提取属性时color:\s*[^;]+够用吗
够用，但有陷阱。这个模式会漏掉带空格的值（如font-family: "Times New Roman"）、带分号的值（如content: "a; b"），以及缩写属性里含冒号的情况（如filter: drop-shadow(0 0 2px #000);）。
立即学习“PHP免费学习笔记（深入）”；
- 更健壮的写法是匹配整条声明：用
/([a-z-]+)\s*:\s*([^;{]+)(?=;|$)/i，靠(?=;|$)确保停在分号或行尾，而不是盲目截断 - 如果CSS含
@media或@supports等规则，建议先按{}层级切分块，再对每个块做属性提取，避免匹配到规则体外的孤立声明 - 注意
border: 1px solid #000这种多值属性，[^;{]+能完整捕获，但后续还需按空格/逗号进一步解析，这不是正则该干的事
实际项目里要不要自己写正则解析CSS
除非你只处理极简、可控的输入（比如构建工具里自动生成的内联样式），否则不建议。CSS语法比表面复杂得多：自定义属性（--foo: bar）、calc()表达式、var()函数、Unicode转义、IE条件注释（/*\*/.../**/）都会让正则迅速失控。
- 用现成库如
scssphp或spatie/css-to-inline-styles的解析器，它们已处理好注释剥离和token边界 - 若只是提取关键属性（如
width、color），先preg_replace()清注释，再用简单正则扫一遍，足够应付90%的运维脚本场景 - 最易被忽略的一点：BOM头和UTF-8 BOM字符（
\xEF\xBB\xBF）可能让/*匹配失败，清理前最好先trim($css, "\x00..\x08\x0B\x0C\x0E\x0F\x10..\x1F\x7F")
