无限滚动必须用异步逻辑而非同步while循环，核心是事件监听+异步请求+状态标记（hasMore/isLoading/isAtBottom）协同控制，辅以防抖、超时、重试等兜底机制。
在无限滚动加载场景中，不能直接用同步 while 循环来“等待数据”或“轮询加载状态”——因为 JavaScript 是单线程的，同步阻塞会导致页面卡死、无法响应滚动事件、无法更新 DOM，也根本没法安全退出。
真正该用的不是 while(true)，而是异步驱动的加载逻辑
无限滚动本质是“用户滚动触底 → 触发加载 → 数据返回 → 渲染 → 更新可加载状态”，整个过程天然异步。强行套用 while 循环只会制造陷阱。
- ❌ 错误做法：用
while (!dataLoaded) { /* 空转 */ }或while (loading) { }—— 这会锁死主线程，浏览器无响应 - ✅ 正确思路：用事件监听（如
scroll）+ 异步请求（fetch）+ 状态标记（isLoading/hasMore）协同控制
核心边界条件必须是可变、可观测、非阻塞的状态
安全退出的关键，不在于“循环怎么写”，而在于“哪些状态能真实反映是否还能继续加载”：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
hasMore：后端返回的分页字段（如
response.hasNext === true），明确标识是否还有下一页 -
isLoading：当前是否有请求正在进行，防止重复触发（
if (!isLoading && hasMore && isAtBottom) { loadNextPage() }） -
isAtBottom：通过
scrollTop + clientHeight >= scrollHeight - threshold计算，每次滚动实时更新，不是静态值
用递归 + await 替代 while，保持控制流清晰
如果业务需要连续拉取多页（比如预加载 3 页），可用带终止条件的异步函数递归，而非 while：
示例：安全拉取最多 3 页，或遇到 hasMore: false 时停止/api/items?page=${loaded + 1}
手动干预与防抖是实际项目中的必要兜底
用户可能快速滚动、网络延迟、接口失败——仅靠自动逻辑不够，需主动控制：
- 滚动事件加
throttle（如 100ms 一次），避免高频触发 - 提供“加载更多”按钮，点击才触发下一页，绕过自动滚动逻辑
- 设置请求超时（
AbortController）和失败重试次数，超限后设hasMore = false - 记录最后成功加载的页码，异常恢复时可续传，而非从头 while
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
