加载状态管理核心是状态可见性与生命周期对齐：loading必须真实反映异步操作起止，按钮点击后需立即禁用并更新UI，消失时机应延至数据就绪、DOM可交互之时。
加载状态管理不是加个 spinner 就完事，核心是“状态可见性”和“生命周期对齐”——用户看到 loading，必须是因为真实异步操作在进行；loading 消失，必须对应到可交互或数据就绪的那一刻。
按钮点击后怎么同步设置 loading 状态
常见错误是先发请求、再改按钮文本，结果浏览器没来得及重绘就卡住了，用户点完毫无反馈。
-
button.textContent = "加载中"和button.disabled = true必须在事件回调最开头执行，不能放在fetch()后面 - 推荐用 class 切换：
btn.classList.add("is-loading")，配合 CSS 隐藏默认文案、显示 loading 文本或 SVG 图标 - 如果按钮里有
<svg>，记得在.is-loading下统一控制它的显隐，否则图标和文字错位 - 原生
<form>提交会刷新页面，JS 设置的状态瞬间失效；必须event.preventDefault()并手动提交
如何让 loading 状态真正匹配异步过程
loading 不是装饰，它得反映真实阻塞点。比如接口返回快但渲染慢，那 loading 应该持续到 DOM 更新完成，而不是 then() 一进就关。
- 对于
fetch+innerHTML场景，loading 要保持到targetElement.innerHTML = data执行完毕，尤其数据量大时 - 用
IntersectionObserver懒加载列表时，loading 状态应绑定在“占位节点是否进入视口”之后、请求发出前，而非响应返回后才显示 - 上传文件需监听
xhr.upload.onprogress，<progress>的value必须传数字（如progress.value = 65），传字符串会回退为 0 - 避免在
setTimeout里模拟 loading，这会让状态和真实流程脱钩，调试困难
为什么 document.readyState 不能当加载进度用
它只有 "loading"、"interactive"、"complete" 三态，无法映射百分比。从 interactive 到 complete 可能卡在某张图片或字体加载上，你根本不知道卡在哪。
立即学习“前端免费学习笔记（深入）”；
- 真要实现页面级进度条，得用
PerformanceObserver监听"resource"类型事件，自己累加已加载资源大小 -
<progress>标签本身不自动关联任何加载行为，它只是个被动控件，value 更新频率太高（如每 10ms）反而触发重排，影响性能 - 服务端渲染（SSR）场景下，首屏内容已存在，
document.readyState === "complete"触发过早，此时 JS 还没接管，loading 层可能被误删
localStorage 怎么辅助脚本加载状态协同
动态插入多个依赖脚本时，靠 async 或 defer 无法保证顺序，得用存储机制做协调。
- 每个脚本加载前查
localStorage.getItem("script:utils.js:loaded")，存在且为"true"就跳过 - 成功加载后，在
script.onload回调里写入：localStorage.setItem("script:utils.js:loaded", "true") - 失败时写
"error"，便于后续重试逻辑判断；注意键名要带路径或哈希，避免冲突 - sessionStorage 更适合单会话队列，比如存
["a.js", "b.js"]，每执行完一个就shift()并更新，页面刷新后仍可续跑
最容易被忽略的是 loading 的“消失时机”——它往往不在请求结束那一刻，而在数据可用、DOM 可交互、焦点可抵达之后。多一层判断，就少一次用户误点。
