Math.ceil不能直接用于骨架屏数量计算，因total=0时得0（应至少1个）、unitSize为0或负数会导致NaN/Infinity；须校验输入并设业务下限minCount=1，且需对齐前后端分页单位、处理apiTotal未返回等场景。
Math.ceil 为什么不能直接用在骨架屏数量计算上
直接写 Math.ceil(total / unitSize) 看似合理，但实际常出错——比如 total = 0 时结果是 0，而业务上通常至少要渲染 1 个骨架单元（哪怕没数据）；再比如 unitSize 是动态配置项，可能为 0 或负数，导致 NaN 或无限大。
常见错误现象：Math.ceil(0 / 12) → 0（页面空白）、Math.ceil(13 / 0) → Infinity（后续 map 渲染崩溃）
- 必须对
total和unitSize做前置校验 - 骨架单元数的下限通常是
1，不是数学意义上的“向上取整”结果 - 如果后端分页 size 与前端 unitSize 不一致（如后端每页 20 条、前端每行渲染 3 个骨架），需先对齐逻辑单位
带业务兜底的最小骨架单元数计算函数
核心是把「数学向上取整」和「业务最小展示要求」拆开处理，再合并：
function getSkeletonCount({ total = 0, unitSize = 1, minCount = 1 }) {
if (unitSize <= 0) return minCount;
if (total <= 0) return minCount;
return Math.max(minCount, Math.ceil(total / unitSize));
}
使用场景：
- 列表页加载中，已知总条数
total，每行渲染3个骨架，则unitSize = 3 - 网格布局卡片流，每屏最多显示
8张，但当前只拿到前5条数据，仍要撑满一屏 →getSkeletonCount({ total: 5, unitSize: 8 })返回1 - 搜索无结果页，
total = 0，但设计稿要求显示 1 行骨架占位 → 自动 fallback 到minCount
注意：Math.max 比条件判断更简洁，也避免嵌套 if；minCount 默认设为 1 覆盖绝大多数骨架屏场景。
和服务端分页对齐时的常见陷阱
前端 unitSize 和后端 page_size 不一致时，直接套用 Math.ceil(total / unitSize) 会误判。例如：
- 后端返回
{ total: 47, page_size: 20 } - 前端每行渲染
6个骨架，但按Math.ceil(47 / 6) === 8渲染，实际第 3 页才开始有数据，前两页骨架数应严格对应 page_size 的分布逻辑
此时正确做法是：
- 先算「需要几页才能覆盖 total」→
Math.ceil(total / page_size) - 再算「每页对应多少行骨架」→
Math.ceil(page_size / unitSize) - 最终骨架总数 = 页数 × 每页行数，而不是用 total 直接除
容易踩的坑：把服务端分页当成纯数据量，忽略其对骨架结构的约束力；或把 unitSize 错当成后端的 page_size。
React 中结合 loading 状态做骨架数派生的典型写法
不要在 JSX 里重复计算，尤其当 total 来自异步响应时：
const skeletonCount = React.useMemo(() => {
if (!isLoading && items.length > 0) return 0;
return getSkeletonCount({ total: apiTotal ?? 12, unitSize: 4 });
}, [isLoading, items.length, apiTotal]);
关键点：
-
apiTotal可能未返回（undefined），需提供 fallback（如默认 12） -
items.length > 0且不 loading 时，骨架数必须为0，否则会出现「数据已到但骨架还在」的闪烁 - 依赖项必须包含所有影响计算的变量，漏掉
apiTotal会导致缓存失效
复杂点在于：骨架数不是纯数学问题，它横跨 loading 状态、接口响应节奏、UI 布局规则三层逻辑。少一个条件，就可能在弱网或接口降级时暴露白屏。
