HTML进度条<progress>不能替代加载状态提示，它仅语义化表示确定任务的完成比例；真正加载中应使用CSS动画、骨架屏配合aria-busy和aria-live实现无障碍反馈。
HTML进度条不是加载状态的替代品
用 <progress> 标签展示“加载中”，本质上是错的。它语义上表示任务完成比例（如文件上传进度、表单填写完成度），而非异步操作是否正在进行。浏览器不会自动把 AJAX 请求或资源加载映射到 <progress> 的 value，你得手动更新——而多数场景根本拿不到精确的百分比。
常见错误现象：<progress value="0" max="100"></progress> 静止在 0，或者硬写成 value="50" 做“假动画”，用户反而更困惑。
- 真正需要“加载中”提示时，优先用
<div class="loading">+ CSS 动画（如旋转、骨架屏） - 只有当你能获取真实进度（如
XMLHttpRequest.upload.onprogress、fetch配合ReadableStream）时，才用<progress> -
<progress>不支持 `indeterminate` 属性（那是<meter>的常见误用），想表达“不确定时长”，得靠 CSS 模拟或换用<span>+ loading 图标
用 aria-busy 和 aria-live 告诉屏幕阅读器“正在加载”
视觉上的旋转图标对视障用户完全无效。单纯加 <progress> 也不行——它的默认 role="progressbar" 要求必须有确定的 value 和 max，否则会触发无障碍校验警告。
正确做法是：用普通容器承载加载状态，并通过 ARIA 明确声明行为：
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
<div aria-busy="true" aria-live="polite"> <span>加载中…</span> </div>
-
aria-busy="true"告诉辅助技术“当前区域内容即将变化”，暂停对该区域的读取 -
aria-live="polite"确保新内容（如加载完成后的数据）插入后会被朗读，且不打断用户当前操作 - 加载结束时，务必设回
aria-busy="false"，否则屏幕阅读器会持续忽略该区域
CSS 骨架屏比 <progress> 更可信
用户对“进度条从 0% 跳到 100%”已经免疫，但看到内容区块的灰色占位符（骨架屏）会下意识认为“结构已知，只是数据未到”，心理预期更稳。
- 骨架屏用纯 CSS 实现（
background: linear-gradient+animation），无 JS 依赖，首屏渲染快 - 避免用
<progress>套骨架图——语义冲突，且 Safari 对<progress>的样式限制极多（比如无法改高度、圆角） - 关键路径（如商品列表、文章正文）建议服务端直出骨架 HTML，而不是等 JS 加载完再渲染，否则首屏空白时间更长
fetch + AbortSignal 能否驱动 <progress>？
不能直接驱动。原生 fetch 不暴露下载/上传进度事件，除非配合 ReadableStream 手动分块读取响应体——这对 JSON 接口几乎没意义（整个响应体才几 KB），反而增加解析复杂度。
真正可用的场景极少：
- 大文件下载（>10MB）且后端支持
Content-Range，前端用response.body.getReader()逐块读取并累加字节数 - 上传大文件时，用
FormData+XMLHttpRequest（因fetch仍不支持上传进度） - 别为“看起来有进度”强行加
<progress>：用户更在意“操作是否被响应”，而不是“进度数字准不准”
复杂点在于，进度感知和 UI 反馈是两层事：前者需要底层协议支持（如分块传输、自定义 header），后者只需清晰的状态提示。很多人卡在试图用一个标签解决两个问题。
