Retina屏上box-shadow发光发虚，因高DPR导致亚像素插值；应改用小数模糊值（如3.5px）、微正扩展值、rgba低透明度色，并限制阴影层数与总模糊半径以保性能。
box-shadow 模拟 1px 发光在 retina 屏上为何容易糊成一团？
因为设备像素比（dpr）高，比如 iPhone 15 的 dpr=3，1px CSS 像素实际渲染为 3×3 物理像素。直接写 box-shadow: 0 0 4px #fff 会触发浏览器对模糊半径做亚像素插值，边缘发虚、光晕弥散、边界不清——不是“发光”，是“渗光”。
关键不在加多大模糊，而在控制光晕的起始密度和衰减节奏：
- 避免用整数模糊值如
4px或8px，改用带小数的3.5px、7.2px，让渲染引擎更倾向采样而非插值 - 扩展值（spread radius）设为
0或微正数（如0.3px），负值会裁剪光晕，尤其在圆角容器中易露白边 - 颜色必须用
rgba()，透明度控制在0.15–0.35区间；纯色如#ffffff在深背景上会“炸开”，失去层次
移动端适配 retina 的发光参数怎么调才不掉帧？
高模糊 + 多层阴影 + hover 动画 = 合成层压力飙升。Safari 和低端安卓 WebView 尤其敏感，滑动时明显卡顿。实测发现，只要满足两个条件，就能兼顾效果与性能：
- 单个元素最多用两层
box-shadow，三层及以上在 iOS 17+ Safari 中已触发强制 CPU 渲染 - 模糊半径总和不超过
22px（例如inset 0 0 12px rgba(100, 200, 255, 0.2), inset 0 0 10px rgba(255, 220, 100, 0.25)），超过后 DevTools 的 “Paint flashing” 面板会持续红闪 - 禁用
transition: box-shadow直接过渡，改用transform: translateZ(0)强制 GPU 层，再配合will-change: box-shadow（仅在悬停前一刻启用）
为什么在圆角容器里内发光只亮四角？
这是 Safari 对 inset 阴影的渲染限制：当 border-radius 与模糊半径不匹配时，内阴影会在圆角交界处断裂，中间区域光强骤降，形成“四角灯泡、中心发灰”的错觉。
解决方法不是加大模糊，而是做比例约束：
- 若
border-radius: 6px，则最大安全模糊值 ≈12px（即 2×radius） - 若需更强光晕，把
border-radius提到10px，再配inset 0 0 18px，边缘才自然连贯 - 必须加
background-clip: padding-box，否则阴影可能被 border 裁掉（哪怕 border 是transparent） - 慎用
overflow: hidden—— 它会裁掉伪元素实现的增强型内发光，改用clip-path: inset(0)更稳妥
filter: drop-shadow() 真的比 box-shadow 更适合发光吗？
只在一种场景下成立：目标元素有非矩形 Alpha 通道（SVG 图标、PNG 透明图、文字、带 clip-path 的 div）。box-shadow 永远按盒模型投射矩形光晕，而 drop-shadow() 基于像素 alpha 值计算，能紧贴图形边缘发光。
但代价明确：
-
drop-shadow()不支持inset，无法做内发光 - 不支持扩展值（spread radius），光晕厚度只能靠模糊半径硬控，缺乏精细调节
- 在 iOS 16–17 上，
drop-shadow()+ 圆角 + 动画组合极易触发闪烁，尤其配合backface-visibility: hidden时 - 真要换，优先试
box-shadow+mask-image: linear-gradient()混合方案，比全切drop-shadow()更可控
最常被忽略的一点：发光是否“真实”，取决于它和背景的交互关系。同一组 box-shadow 参数，在深色背景上是辉光，在浅灰背景上可能完全不可见——别死磕参数，先确认设计上下文里的明暗锚点。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
