display: contents 在低版本安卓系统（如 Android 4.4–6.0、WebView ≤114 及多数厂商定制内核）中完全不被识别，@supports 检测不可靠，需用 PostCSS 移除或 DOM 替代方案兜底。
display: contents 在低版本安卓系统上无法“兼容”——它根本不会被解析，不是效果差，是彻底无效。 Android WebView ≤114（即 Chromium ≤114）、所有 Android 4.4–6.0 原生浏览器、以及绝大多数厂商定制内核（如华为 EMUI 5.x/7.x、小米 MIUI 9–11 内置 WebView），均不识别 display: contents。写了等于没写，getComputedStyle(el).display 返回 "block" 或初始值，子元素也不会脱离父盒模型。
为什么 @supports (display: contents) 检测不可靠
@supports 在旧 Blink 引擎（Chromium 100–114）中对 display: contents 的检测会返回 true，哪怕该值实际未实现——因为引擎能识别语法结构，但跳过后续布局逻辑。结果就是：检测通过，样式却静默失效，DOM 结构看似正常，动画、事件委托、无障碍树全乱套。
- Android 5.1（WebView 39）、6.0（WebView 44）实测：
@supports (display: contents)返回true，但子元素仍被包裹在父盒中，margin不塌陷，flex项不直接受控 - 真机验证比 UA 字符串更准：直接运行
document.createElement('div').style.display = 'contents'; getComputedStyle(document.body).display，看是否生效 - 构建时移除更稳妥：用 PostCSS 插件（如
postcss-display-contents-fallback）在目标浏览器列表中自动剔除该声明
display: contents 失效时的 DOM 替代方案
不能靠 JS 模拟“语义抹除”，必须用真实 DOM 占位来维持布局流和可访问性。核心原则：不破坏 ARIA 属性继承、不切断事件冒泡链、不干扰屏幕阅读器顺序。
- 用空
<div class="contents-fallback"></div>替代原容器，设font-size: 0消除 inline 子元素间空白符撑开的间隙 - 若该容器是 flex 项，必须加
min-width: 0（IE/旧 Android 默认min-width: auto，会导致塌缩） - 绝对禁止
height: 0或overflow: hidden，否则子内容会被裁剪 - 对关键交互节点（如按钮、输入框），保留原始
role和aria-*属性到 fallback 容器上
哪些场景其实可以用 flex/grid 替代 display: contents
多数使用 display: contents 的真实诉求，其实是“去掉父容器盒模型干扰”，而非真正需要语义扁平化。这时改用现代布局容器更可控、兼容性更好。
立即学习“前端免费学习笔记（深入）”；
- 列表项想让
<li>下的<div> 直接参与外层 <code>display: flex布局？把<ul></ul>改成display: flex，<li>设为flex: 1，内部结构不动 - 表单字段想让
label和input同级对齐？用display: grid+grid-template-columns: max-content 1fr，不用动语义结构 - 避免
display: contents导致的animationend事件丢失：动画必须绑定在真实渲染的节点上，而不是它的contents父级
最易被忽略的一点：动态插入的 DOM 节点，如果依赖 display: contents 实现布局扁平，在旧安卓上会直接退化为嵌套盒子——此时 CSS 选择器优先级、:nth-child() 计数、甚至 focus 流都会偏移。不要等线上报错才补 fallback，从组件设计之初就按“无 contents”路径实现。
