<blink>标签被标准组织明确定义为obsolete，现代浏览器完全无视其解析与渲染，且任何模拟闪烁行为均违反WCAG无障碍准则，易诱发光敏性癫痫、无法被屏幕阅读器识别，应以语义化、可访问的替代方案（如aria-live、prefers-reduced-motion）实现状态提示。
blink 标签已彻底失效，且任何模拟闪烁的行为都属于视觉无障碍违规行为——它不是“效果差”，而是根本不该存在。
为什么 blink 标签在现代浏览器里完全不工作
浏览器早在 2010 年代初就移除了对 <blink> 的支持。Chrome、Firefox、Safari、Edge 全部无视该标签，连解析都不做，直接当普通文本或忽略其语义。它不是“兼容性不好”，而是被标准组织（WHATWG）明确定义为 obsolete，连 HTML Living Standard 里都找不到它的定义。
常见错误现象：
- 写
<blink>Save</blink>，结果文字稳如泰山，毫无反应 - 用开发者工具检查，发现元素节点存在，但 computed styles 里根本没有动画相关属性
- 误以为是 CSS 没加载，反复加
!important或重写样式，徒劳无功
用 CSS @keyframes 模拟 blink 仍属无障碍违规
即使你用 @keyframes + opacity 实现了“完美闪烁”，它依然违反 WCAG 2.1 准则 2.2.2（暂停、停止、隐藏），因为：自动闪烁内容无法被用户控制；频率在 3–50 Hz 区间时，可能诱发光敏性癫痫（哪怕只闪 3 秒）；屏幕阅读器无法传达“正在闪烁”这一状态，对视障用户形成信息盲区。
立即学习“前端免费学习笔记（深入）”；
使用场景中真正需要的从来不是“闪烁”，而是：
- 表单错误提示 → 应用
aria-live="polite"+ 高对比色边框 + 焦点自动跳转 - 新消息提醒 → 使用
prefers-reduced-motion: reduce媒体查询降级为平滑淡入或图标 pulse - 操作进行中 → 显示骨架屏或进度条，而非“加载中…”文字来回闪
setInterval 切换 opacity 是最危险的实现方式
这种写法表面能动，实则埋下三重隐患：定时器未清理导致内存泄漏；页面切到后台时仍持续触发，切回时集中爆发造成卡顿；无法响应系统级动效偏好设置（prefers-reduced-motion）。
参数差异上，setInterval(() => el.style.opacity = el.style.opacity === '1' ? '0' : '1', 500) 和用 requestAnimationFrame 的区别不是“更流畅”，而是前者根本不可控，后者至少能随帧率同步、可中断、可检测页面可见性。
性能影响显著：每毫秒都强制触发重绘（repaint），若同时有多个 blinking 元素，GPU 合成压力陡增，在低端设备上直接掉帧至 30fps 以下，表现为肉眼可见的撕裂与抖动。
真正该做的不是让文字闪，而是让状态可感知
闪烁是懒惰的视觉捷径。替代方案必须满足三个条件：有明确语义（role="alert"）、可键盘导航（tabindex="-1" + focus()）、尊重用户偏好（@media (prefers-reduced-motion: reduce) 内关闭所有动画）。
最容易被忽略的是：即使你没写任何 blink，第三方 UI 库（比如某个 toast 组件）内部可能偷偷用了 animation: blink-anim 0.8s infinite ——务必用 DevTools 的 Rendering 面板开启 Paint flashing，盯着那些高频重绘区域，顺藤摸到对应 DOM 节点和 CSS 规则。
