opacity作用于整个元素及其子元素，无法单独控制文字或边框透明度；应使用rgba()/hsla()替代，并注意其会创建层叠上下文、影响z-index，配合pointer-events才能禁用交互。
opacity 只能作用于整个元素，不能单独控制颜色透明度
很多人想用 opacity 让文字变半透但背景不透，或者只让边框透明——这行不通。opacity 是作用在整块渲染树节点上的，包括子元素、背景、边框、文字，全都按相同比例变透明。它不是“颜色属性”，而是“层叠上下文的透明度开关”。
常见错误现象：opacity: 0.5 后发现按钮文字和图标都发虚，点击区域也变弱（因为整个元素参与合成），甚至影响 z-index 层级行为。
- 如果只需文字或背景半透明，改用
rgba()或hsla()颜色值（比如background-color: rgba(0, 0, 0, 0.3)） -
opacity接受 0–1 范围的数字，0.0和0效果一致，但写成0.0并不会更“精确” - IE8 及更早版本不支持
opacity，需回退到filter: alpha(opacity=50)（已淘汰，仅作兼容性了解）
opacity 会触发新的层叠上下文，可能意外改变 z-index 行为
只要元素设置了 opacity 值不等于 1，浏览器就会为它创建独立的层叠上下文（stacking context）。这意味着它的子元素的 z-index 只在这个局部上下文中生效，不再和父容器外的其他元素直接比层级。
使用场景：做模态框遮罩层时，常对 .overlay 设 opacity: 0.7，但如果遮罩里嵌套了下拉菜单或 Tooltip，它们可能被遮罩自身截断——因为它们的 z-index 再高，也出不了这个新上下文。
- 检查是否意外触发层叠上下文：用浏览器开发者工具看“Computed”面板里的
transform、opacity、will-change等字段是否非默认值 - 若需保持原有层叠关系，优先用
background-color: rgba()替代opacity控制背景透明度 - 动画中频繁修改
opacity性能尚可，但搭配transform一起用时，注意不要无意中创建多层嵌套上下文
opacity 动画卡顿？试试 will-change 提前提示
opacity 本身是 CSS 中少数能硬件加速的属性之一，但浏览器不一定每次都主动启用 GPU 合成。尤其在旧版 Chrome 或移动端 WebView 中，连续动画可能出现掉帧。
性能影响：不加优化时，每帧都要重绘整个元素；加上 will-change: opacity 后，浏览器会提前把该元素提升为独立图层，减少重绘范围。
- 只在真正需要动画的元素上设置
will-change: opacity，动画结束立即移除（可用 JS 监听transitionend） - 别在大量元素上滥用
will-change，否则内存占用飙升，反而拖慢页面 - 现代浏览器（Chrome 90+、Firefox 85+）对
opacity的优化已很好，日常渐隐渐显无需额外干预
opacity 和 pointer-events 配合才能真正“禁用交互”
设了 opacity: 0.2 看起来很淡，但用户依然能点、能 hover、能 focus——视觉不可见 ≠ 交互失效。这是最常被忽略的一点。
使用场景：加载中按钮变灰透明，但没禁用点击，导致重复提交；弹窗关闭动画进行中，用户还能点背后的内容。
- 正确做法是同时加
pointer-events: none（禁止鼠标事件）和opacity: 0.2 - 若只想禁用点击但保留 hover 效果（比如 tooltip 淡入前的预热状态），则只用
opacity，不加pointer-events -
pointer-events: none不影响键盘焦点（tab仍可进入），如需完全禁用，还得加tabindex="-1"和aria-disabled="true"
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
