HTML进度条不能替代加载状态提示
HTML进度条不是加载状态的替代品
我们经常看到这样的误区：把标签当作“加载中”的指示器来用。其实，这个标签的语义是表示一项**确定性任务**的完成比例，比如文件上传到百分之几，或者问卷调查填了多少。它天生就不是为表示“正在努力干活、但不知道啥时候干完”的异步加载场景设计的。浏览器可不会自动把AJAX请求或者图片加载的进度映射到这个标签的value属性上，一切都得开发者手动更新——问题在于，大多数加载场景根本没法提供一个精确的百分比。
结果呢？常常出现这种诡异的状况：一个挂在那里一动不动，或者更糟，为了“显得有进度”而硬编码成value="50"来回跳动，这种假动画除了让用户更困惑，没有任何好处。
- 所以，当你真正需要提示“加载中”时，第一选择应该是
配合CSS动画，比如一个旋转的图标，或者现在更流行的骨架屏效果。 标签应该留给那些你能获得真实进度数据的场合，例如利用XMLHttpRequest.upload.onprogress事件监听文件上传，或者通过fetch配合ReadableStream分块读取大文件。- 还有个常见的知识盲区：
标签本身并不支持indeterminate属性（那是加个加载图标更直白。
用 aria-busy 和 aria-live 告诉屏幕阅读器“正在加载”
视觉上做得再炫酷的加载动画，对使用屏幕阅读器的视障用户来说都是无效的。单纯摆上一个标签也不行——它默认的role="progressbar"（进度条角色）要求必须提供确定的value和max属性值，否则在很多无障碍检测工具里会直接抛出警告。
正确的无障碍实践是这样的：用一个普通的容器元素来承载你的加载状态，然后通过ARIA属性清晰地告诉辅助技术这里正在发生什么：
立即学习“前端免费学习笔记（深入）”；
加载中…
aria-busy="true"这个属性是关键，它告诉屏幕阅读器：“这个区域的内容马上就要更新了，你先别急着读。” 辅助技术会据此暂停对该区域的自动读取。aria-live="polite"则确保了当新内容（比如加载完成后的数据）插入到这个区域时，屏幕阅读器会以不打断用户当前操作的方式朗读出来。- 有个细节千万记得：加载结束时，一定要把
aria-busy设回"false"。否则，屏幕阅读器会一直认为这个区域还在忙，从而持续忽略其中的内容更新。
CSS 骨架屏比
如今，用户对那种从0%缓慢爬到100%的进度条已经近乎免疫了，甚至有些怀疑。但骨架屏（Skeleton Screen）效果就不一样了——当用户看到内容区块的灰色占位符轮廓时，他们会下意识地认为：“哦，页面的结构已经准备好了，只是数据还在路上。” 这种心理预期更加稳定，体验也更顺畅。
- 骨架屏完全可以用纯CSS实现（主要靠
background: linear-gradient配合animation），不依赖Ja vaScript，因此首屏渲染速度更快。 - 务必避免在
标签里套用骨架图的样式，这属于语义冲突。而且，Safari等浏览器对的样式限制非常多，比如很难自定义高度和圆角。 - 对于关键渲染路径上的内容（比如商品列表、文章正文），建议在服务端直接输出骨架屏的HTML结构，而不是等客户端的Ja vaScript加载执行后再去渲染。后者会导致更长的首屏空白时间，体验上的差距很明显。
fetch + AbortSignal 能否驱动
答案是：不能直接驱动。原生的 那么，到底哪些场景才真的适合用进度条呢？其实非常有限： 这里面的复杂性在于，进度感知和UI反馈其实是两层不同的事情：前者需要底层网络协议（如分块传输编码、自定义头部）的支持来获取真实数据；后者则属于界面设计范畴，只需要清晰、及时地告知用户状态即可。很多人容易掉进一个思维陷阱：试图用一个HTML标签去同时解决这两个问题。fetch API在设计上就没有暴露下载或上传的进度事件。除非你愿意配合ReadableStream
Content-Range头部。这样前端才能用response.body.getReader()逐块读取，累加知道总共有多少字节。XMLHttpRequest，因为截至目前，fetch依然不支持上传进度事件。。在绝大多数交互中，用户的核心诉求是“我的操作有没有被响应”，而不是“进度数字必须精确到小数点后两位”。一个清晰的“加载中”状态提示，往往比一个僵硬的假进度条更友好。
