标签在现代浏览器中完全不工作，因其被标准组织明确定义为obsolete，仅作无语义容器存在；用css动画或javascript实现闪烁均违反无障碍规范，应改用aria-live、高对比边框等可感知状态提示。
<blink></blink> 标签在所有现代浏览器中完全不工作——不是“失效”，而是被标准组织明确定义为 obsolete，Chrome、Firefox、Safari、Edge 全部跳过解析，连样式计算都不触发。
为什么<blink></blink>标签在页面里稳如泰山
它从来就不是 HTML 标准的一部分，Netscape 1990 年代实验性引入后即被 WHATWG 和 W3C 弃用。你在 Elements 面板里看到的 <blink></blink> 节点，只是个无语义的普通容器，computed styles 里找不到任何动画属性。试图加 !important 或重写 CSS 动画，改的也不是 <blink></blink> 的行为，而是你后来补的规则。
常见错误现象包括：
- 写
<blink>Save</blink>，文字毫无反应 - 用开发者工具检查，元素存在但 animation 相关属性全为空
- 误以为是 CSS 加载失败，反复调试样式表，浪费大量时间
CSS @keyframes 实现闪烁仍属无障碍违规
即使你用 @keyframes + opacity 做出“完美闪烁”，它依然违反 WCAG 2.1 准则 2.2.2（暂停、停止、隐藏），因为：
- 自动播放无法被用户控制；
- 频率落在 3–50 Hz 区间时，可能诱发光敏性癫痫（哪怕只闪 3 秒）；
- 屏幕阅读器完全无法传达“正在闪烁”这一状态，对视障用户形成信息盲区。
真正需要的从来不是“闪烁”，而是可感知的状态提示：表单错误 → aria-live="polite" + 高对比边框 + 自动聚焦；新消息 → @media (prefers-reduced-motion: reduce) 降级为平滑淡入；操作进行中 → 骨架屏或进度条。
setInterval 切换 opacity 是最危险的实现方式
这种写法表面能动，实则埋下三重隐患：
- 定时器未清理导致内存泄漏；
- 页面切到后台时仍持续触发，切回时集中爆发造成卡顿；
- 无法响应系统级动效偏好设置（
prefers-reduced-motion）。
参数上，setInterval(() => el.style.opacity = el.style.opacity === '1' ? '0' : '1', 500) 和 requestAnimationFrame 的区别不是“更流畅”，而是前者根本不可控；后者至少能随帧率同步、可中断、可检测页面可见性。性能上，每毫秒强制重绘，多个 blinking 元素同时运行会让低端设备掉帧至 30fps 以下。
真正该做的不是让文字闪，而是让状态可感知
多数场景下，“闪烁”只是设计者对“引起注意”的懒惰解法。它掩盖了更本质的问题：提示是否出现在用户当前焦点路径上？错误信息是否足够明确？交互反馈是否有足够的时间窗口供用户响应？prefers-reduced-motion 已成主流操作系统标配，而硬编码的闪烁逻辑永远无法适配这个现实。最常被忽略的一点是：一旦用了闪烁，你就必须提供等效的非闪烁替代方案——这不是锦上添花，而是合规底线。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
