opacity 本质是为父元素创建独立合成层并整体 alpha 混合，子元素无法通过 opacity:1 恢复，需用 rgba 控制颜色/背景透明或伪元素隔离。
因为 opacity 不是颜色属性，而是对整个渲染盒（painting box）做 Alpha 混合——它把父元素及其所有后代当作一个整体压暗，子元素写 opacity: 1 也拉不回来。
opacity 的本质是“整层压暗”，不是“颜色变淡”
浏览器在绘制时，只要父元素的 opacity 小于 1，就会为它创建一个独立的合成层，并将该层内所有内容（文字、边框、子元素、伪元素）统一按该透明度混合输出。这不是继承，而是底层绘制行为。
- 父级
opacity: 0.4→ 整个盒子以 40% 不透明度渲染 - 子元素即使设
opacity: 1，也只是在已压暗的画布上再画一次，最终仍是 0.4 - Inspector 里看到的
color计算值可能是rgba(0,0,0,0.4)，但你写的其实是#000—— 这说明透明度已被强制注入到颜色通道中
为什么子元素无法“逃出”这个透明层
子元素没有自己的渲染上下文边界，除非它自己触发新的层叠上下文（比如通过 position: absolute + z-index、transform、filter 等），否则它就天然属于父元素的绘制树分支。
-
opacity是 CSS 规范明确定义的层叠上下文触发条件之一：只要值 ≠ 1，就建立新上下文 - 这意味着子元素的
z-index只在该上下文内部有效，无法和外部同级元素比高低 - 你看到按钮被导航栏盖住，往往不是
z-index写得不够大，而是它根本不在同一个上下文里
常见误判点：你以为没设 opacity，其实祖先已经设了
很多“子元素莫名发灰”的问题，根源不在当前元素，而在 DOM 树更上层——比如全局遮罩层、布局 wrapper 或 body 的某个父容器悄悄加了 opacity 或 backdrop-filter。
- 用 Chrome DevTools 选中问题元素，在 «Computed» 面板搜
Stacking context：如果显示This element establishes a stacking context，就说明它或它的某个祖先触发了上下文 - 临时注释掉疑似祖先的
opacity声明，看文字是否立刻变清晰 - 别只盯着当前元素查
opacity，要往上逐层 inspect «Computed» 中的opacity和filter
真正可控的替代方案只有三种
想让背景透、文字不透，必须把透明意图从“整层控制”下沉到“属性级控制”：
- 纯色背景 → 改用
background-color: rgba(0, 0, 0, 0.4)（IE9+ 支持） - 文字/边框半透 → 直接写
color: rgba(0, 0, 0, 0.8)或border-color: rgba(100, 100, 100, 0.3) - 含复杂背景（图片+渐变+模糊）→ 用
::before伪元素隔离：position: absolute+background: rgba(0,0,0,0.4)，真实内容保持z-index: 2且不设opacity
最容易被忽略的是：哪怕你只改了一行 opacity，也可能同时破坏透明表现和层叠顺序——这两个问题总是成对出现，查的时候得一起看。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
