同套后端下，为何线上axios请求/products返回嵌套对象而非本地数组

这类「同套代码本地返回数组、线上突然返回数字键对象」的场景，核心原因是PHP json_encode()的固定编码规则，结合现有代码的写法隐患触发的：

• json_encode() 只有在待编码的PHP数组数字键是从0开始连续递增的完整序列时，才会输出标准JSON数组；只要索引出现断裂（比如跳过某个数字键），就会默认把数组编码为带数字字符串键的JSON对象。
• 现有接口代码存在天然的索引断裂隐患：

  $products = Product::all()
      ->where('is_available', '=', 1)
      ->toArray();
  

  这段代码是先把全表所有商品查出来生成模型集合，再在集合层面过滤不可用商品。集合做过滤时会保留原集合的索引值，比如原集合的索引是0、1、2、3、4，一旦过滤掉索引为2的不可用商品，剩下的索引就会变成0、1、3、4，属于非连续索引的数组，编码时就会被转成数字键对象。
• 本地正常、线上突发异常的原因：
  本地测试数据通常所有商品的is_available都是1，全量查询后过滤操作不会删掉任何项，索引始终保持连续的0、1、2...序列，编码结果就是正常数组；线上今早大概率是把列表中间某款商品设置为不可用，过滤后索引出现断裂，直接触发了编码规则的转换逻辑，不需要改动任何代码就会突然出现结构异常。

修复方案 #

根源修复（推荐） #

把过滤逻辑从集合层面移到数据库查询层面，保证返回的集合索引天然连续：

public function index()
{
    // 直接在SQL层加过滤条件，返回的集合索引从0开始连续递增
    $products = Product::where('is_available', 1)->get()->toArray();
    return response()->json($products, 200);
}

这种写法不仅不会出现索引断裂的问题，还能避免全表数据加载到内存的性能开销。

兜底修复 #

如果暂时不想调整查询逻辑，可以在集合过滤后强制重置连续索引，从编码层面规避问题：

$products = Product::all()
    ->where('is_available', '=', 1)
    ->values() // 重置集合索引为连续的从0开始的数字序列
    ->toArray();

加了values()方法后，不管之前的索引是不是连续，都会被重新整理成标准序列，json_encode就会正确输出JSON数组。

前端临时兼容 #

如果暂时无法调整后端逻辑，可以在前端拿到响应后做结构判断自动转换：

axios.get("/products").then((res) => {
    let prods = res.data;
    if (!Array.isArray(prods)) {
        prods = Object.values(prods);
    }
    setProds(prods);
})

内容的提问来源于stack exchange，提问作者Fer Toasted