你打开一个列表页，接口调试工具里数据显示正常，一条不少——34 条。但页面上什么都没有，白得让人怀疑人生。刷新、清缓存、换浏览器，全都没用。
现象
某个动态广场页面整页空白。打开浏览器开发者工具的网络面板，对应的接口返回了 34 条数据，结构看起来也正常。但页面上的列表区域什么都不渲染。
控制台没有明显的报错——这是最让人困惑的地方。没有报错就没有线索，你只能开始猜：样式问题？数据问题？组件挂载问题？
再仔细对比会发现"空列表"和"整页空白"还不一样：如果是数据为空，通常还会渲染出"暂无内容"的空状态；而现在连空状态都没有，说明渲染逻辑根本没被执行，页面停在初始状态。
根因
问题在前端对返回数据的类型判断上。
后端返回的是一个分页对象，结构大致是：
{
"records": [ "...34 条..." ],
"total": 34
}
而前端代码里的判断是这样写的：
if (Array.isArray(data)) {
// 渲染列表
}
Array.isArray(data) 对上面的响应求值为 false——因为 data 是一个对象，不是数组；数组在 data.records 里面。于是渲染分支根本没进去，列表保持初始状态（空），页面就是白的。
为什么这个 bug 特别隐蔽？因为 Array.isArray 不抛错，它只是安静地返回 false。再加上后端在数据为空时可能返回的是空数组（而不是分页对象），所以开发时表现为"有时正常、有时空白"，更难定位：
- 数据为空时，后端返回
[]→Array.isArray为真 → 进分支 → 显示"暂无内容"； - 数据非空时，后端返回分页对象 → 判断为假 → 不进分支 → 整页空白。
也就是说，恰恰是有数据的时候才白屏，这个反直觉的表现正是它骗过所有人的原因。
解决
第一步，先打印类型确认。 在取值之前加一行：
console.log(typeof data, Array.isArray(data), data);
// 输出：object false {records: [...], total: 34}
看到 object false 就对上号了。
第二步，改成兼容分页格式的取值：
const list = data?.records ?? data ?? [];
这样无论后端返回的是分页对象还是裸数组，都能拿到列表。注意 ?? 和可选链的配合，避免 data 为 null 时报错。
第三步，顺手做字段的多态容错。 同一个字段可能是 null、可能是 JSON 字符串、也可能已经是数组，写一个统一的解析函数：
function asArray(v) {
if (Array.isArray(v)) return v;
if (typeof v === 'string') {
try {
const p = JSON.parse(v);
return Array.isArray(p) ? p : [];
} catch {
return [];
}
}
return [];
}
第四步，把"列表数据源"的处理统一到一个地方，不要在多个组件里各写一遍 Array.isArray。用一个统一的取值函数，既能兼容历史遗留的各种格式，也能让你下次改结构时只改一处。
延伸与预防
这类问题的通用教训是："拿到的不是数组"是最常见的整页空白原因，先打印类型。
遇到"数据有、页面空"，第一件事就是打印类型，而不是去看样式、怀疑数据或者加日志到一半。排查顺序应该是：
- 数据到了吗？（网络面板）
- 数据是什么类型？（
console.log(typeof x, x)） - 渲染分支进去了吗？（在分支里打日志）
另外，前后端对接时把响应结构写进接口文档，前端用 TypeScript 定义好类型，让编译期就能发现 data 和 data.records 的区别——这是唯一能在写代码时就拦住这类 bug 的办法。
再往前一步：让后端在"空结果"和"有结果"时保持相同的响应结构（始终返回分页对象，而不是有时是数组有时是对象）。这类"结构随数据量变化"的接口是前端 bug 的温床，统一结构能从根本上消灭一整类问题。
这类"分页对象 vs 裸数组"的分歧在接口层非常普遍：有的后端用 records，有的用 list、rows、items、data。前端每对接一个新接口，都要先确认它的外层结构——最省事的办法就是第一次对接时把响应打印出来看一眼，而不是凭经验直接写 Array.isArray。