:not(:empty)多数情况下无效，因其依赖的:empty要求元素完全无子节点（含空格、换行），而模板或框架常注入不可见空白，导致误判；应改用JS检测textContent.trim()或显式类控制。
为什么 :not(:empty) 在多数情况下根本不起作用
因为 :empty 的定义极其严格：元素必须**完全不包含任何子节点**（包括文本节点、空格、换行符）。只要 HTML 里写了 <div> </div> 或 <div>\n</div>，它就不是 :empty，:not(:empty) 就会误判为“非空”——而你看到的背景却没显示，是因为样式压根没被触发。
- 常见错误现象：
<div class="card">{{title}}</div>中{{title}}渲染为空字符串，但模板里留了换行或空格，:not(:empty)仍匹配 - 真实使用场景：服务端渲染或 SSR 模板中，变量插值前后存在不可见空白；Vue/React 的 JSX 中写成
<div>{title}</div>但title === ""，JSX 不会移除换行符 - 兼容性影响：所有现代浏览器都支持
:not(:empty)，但语义陷阱比兼容性问题更致命
:not(:empty) 的替代方案：用 JS 控制类名更可靠
纯 CSS 无法判断“视觉上是否为空”，只能靠 JS 做一次轻量检查。核心逻辑是：取 textContent 去空格后判断长度。
- 实操建议：给容器加 data 属性标记，如
data-empty-aware，再用脚本批量处理 - 示例代码：
document.querySelectorAll('[data-empty-aware]').forEach(el => { el.classList.toggle('has-content', el.textContent.trim().length > 0); }); - 注意点：避免在
DOMContentLoaded后立即执行，若内容由异步数据填充（如 API 返回），需在数据写入 DOM 后再调用该逻辑 - 性能影响：单次遍历开销极小；若区域频繁增删，可用
MutationObserver监听变化，但多数场景没必要
如果坚持用 CSS，:has() 是目前唯一可行的兜底方式
:has() 允许你基于子元素是否存在来选中父级，配合伪内容或占位元素，可绕过 :empty 的语义限制。
- 使用前提：仅 Chromium 105+ / Safari 15.4+ / Firefox 121+ 支持，且需确认目标环境覆盖范围
- 典型做法：在模板中插入一个隐藏的占位节点，如
<span aria-hidden="true" class="content-marker"></span>，然后写.container:has(.content-marker) - 更稳妥的写法（避免依赖额外 DOM）：
.container:has(*):not(:has(:empty > *))—— 这种写法依然脆弱，不推荐用于生产 - 关键提醒：
:has()不能出现在选择器开头（如:has(...) .target是非法的），且不支持在@keyframes或媒体查询中嵌套
真正容易被忽略的细节：空格来源往往不在你写的 HTML 里
服务端模板（如 EJS、Nunjucks）、构建工具（如 Vite 的 HTML 插件）、甚至 Prettier 自动格式化，都会在标签间注入不可见空白。这些空格让 :empty 失效，而你根本没在源码里“看见”它们。
立即学习“前端免费学习笔记（深入）”；
- 调试方法：打开 DevTools，右键元素 → “Edit as HTML”，把光标放在起始和结束标签之间，按方向键看是否能跨过空白字符
- 临时规避：对容器设置
font-size: 0+ 子元素重设字体大小，可消除空格占位，但会影响内联文本布局，慎用 - 最简实践：放弃
:not(:empty)，改用显式类控制，比如后端/框架层输出class="card card--has-title"，CSS 只响应这个类
