访问传递数组length属性时JS代码终止，调试正常非调试异常

这个问题确实有点棘手——调试时一切正常，非调试模式就卡壳在访问length属性，而且你已经确认数组既非空也不是null。结合Firefox扩展的运行环境，我整理了几个最可能的原因和对应的解决方案：

1. 优先排查异步时序问题 #

最常见的情况是getParams(url)其实是异步函数，但你当成同步函数调用了。比如getParams用了async/await或者返回Promise，那arrParams实际是一个Promise实例，而不是你预期的数组：

• 调试时因为断点停留，Promise已经完成，调试器会显示Promise的结果值，让你误以为拿到了数组；
• 非调试模式下代码执行更快，Promise还没兑现，pv_arrParams是Promise对象，访问length时要么得到undefined，要么触发未捕获的错误导致代码终止。

解决方案：改成异步调用方式：

// 包裹成异步初始化函数
async function initExtension() {
  var arrParams = await getParams(url);
  var strRef = getRef(arrParams);
}
// 执行初始化
initExtension();

2. 确认参数是真正的数组 #

有时候某些API（比如DOM相关、自定义解析函数）返回的是类数组对象（比如NodeList、arguments或者自定义的伪数组），调试器会把它渲染成类似数组的样子，但它并没有原生数组的length属性（或者该属性是动态计算、不可枚举的），非调试模式下访问就会出问题。

解决方案：先转成真正的数组再操作：

function getRef(pv_arrParams) {
  // 转成原生数组
  const realArray = Array.isArray(pv_arrParams) 
    ? pv_arrParams 
    : Array.from(pv_arrParams);
  
  portFromCS.postMessage({greeting: 'before .length'});
  portFromCS.postMessage({greeting: realArray.length});
}

3. 捕获错误定位具体问题 #

非调试模式下，浏览器可能会静默某些未捕获的错误，导致你看不到具体原因。可以给getRef加上try-catch块，直接把错误信息通过postMessage传出来：

function getRef(pv_arrParams) {
  try {
    portFromCS.postMessage({greeting: 'before .length'});
    const len = pv_arrParams.length;
    portFromCS.postMessage({greeting: len});
  } catch (error) {
    // 把错误信息发送出来查看
    portFromCS.postMessage({greeting: `Error: ${error.message}`});
    // 同时在浏览器控制台打印错误（需要在扩展调试面板查看）
    console.error('getRef出错:', error);
  }
}

4. 检查postMessage的序列化限制 #

Firefox扩展中postMessage使用结构化克隆算法传递数据，如果pv_arrParams包含无法序列化的内容（比如函数、DOM元素、Proxy对象），虽然访问length本身没问题，但如果后续有传递整个数组的操作，可能会间接影响代码执行。不过从你的代码来看，这里只传递length数字，这个可能性相对较低，但也可以留意一下。

先从异步时序和类数组对象这两个方向排查，应该能快速定位问题！

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