aria-busy="true"仅在屏幕阅读器遇到已挂载、具明确语义角色（如role="region"）且提前设为"true"的动态内容容器时起作用，用于暂停对该区域变更的播报；必须配对切换、禁用混用aria-live，并由开发者手动补充视觉与交互反馈。
aria-busy="true" 什么时候真正起作用
它只在屏幕阅读器（NVDA、VoiceOver、JAWS）遇到一个正在动态更新的容器时，暂停对该区域内容变更的播报——前提是这个容器已挂载、有明确语义角色（如 role="region"），且 aria-busy 是在 DOM 更新**之前**设为 "true" 的。如果等 fetch() 的 .then() 里才设置，UI 可能已开始闪烁，读屏器早已开始读旧内容或中间态。
常见错误现象：aria-busy="true" 加了但 NVDA 还在读“加载中…”之后的半截列表；或者设完没恢复，整个区域后续永远不被朗读。
- 必须加在**直接承载动态内容的容器**上（如
<div id="search-results">），不能加在按钮、<code>或父级布局容器上 - 值只能是字符串
"true"或"false"，写成true（布尔）、"pending"或留空都无效 - 设为
"true"后，不会禁用点击、不触发 CSS 动画、也不改变视觉——这些全得你手动补 - 发起请求前立刻执行：
el.setAttribute('aria-busy', 'true') - 更新 DOM 后（无论成功失败），在
.finally()或useLayoutEffect/nextTick中执行：el.setAttribute('aria-busy', 'false') - 不要用
setTimeout模拟等待——延迟不可控，且与真实渲染脱节 - React 场景下，避免仅靠
useState触发重渲染来间接控制；应直接操作 ref 节点的属性 - 如果需要加载完成自动播报（如“找到 12 条结果”），应在设
aria-busy="false"后，再向容器内插入一个带aria-live="polite"的临时提示元素 - 容器本身可保留
aria-live="polite"，但必须始终存在且值不变；不能在 busy 期间移除或改值 - 绝对不要给按钮、图标等交互控件加
aria-busy——它只对内容容器有意义 - 配合 class 切换（如
is-loading）控制 spinner 显示、opacity或pointer-events: none - 视觉 loading 提示建议用带文本的
<span></span>，而非纯 CSS 动画；否则对读屏用户等于“此处空白” - 容器最好加上
role="region"和aria-label（如aria-label="搜索结果区域，加载中"），增强上下文 - 图表或复杂组件加载时，避免在设
aria-busy="true"前强制重排（如改height或visibility），否则拖慢初始化
怎么配对控制 aria-busy 的 true/false
关键不是“设一次”，而是确保每次请求开始就设 "true"，并在 DOM 真实更新完成后的**确定时机**设回 "false"。漏掉 .finally() 或异常未捕获，就会让 aria-busy="true" 残留，区域永久“失声”。
为什么不能和 aria-live 混用
aria-live="polite" 和 aria-busy="true" 语义冲突：前者说“有变化请播报”，后者说“先别播”。多数读屏器会优先尊重 aria-busy 并静音该区域，导致 aria-live 彻底失效。更糟的是，若子元素单独加了 aria-live，会绕过父级 aria-busy 控制，中间状态仍被意外朗读。
CSS 和交互逻辑必须自己补全
aria-busy 不提供任何 UI 反馈。用户看到的 loading 图标、背景变灰、指针禁用，全靠你手写：
最易被忽略的一点：aria-busy 不是“加载指示器”，它是“播报暂停开关”。设了 "true" 不代表用户就知道在加载——你还得同步提供视觉反馈和交互约束，否则健全用户和视障用户看到的是两个完全割裂的状态。
