uni-app实现商品规格SKU选择 uni-app多维属性筛选逻辑-uni-app-PHP中文网

多维规格联动应通过已选规格反向过滤SKU列表并提取可用值，而非穷举组合；isAble需全字段比对、深拷贝selectAttr、用every而非includes；禁用矩阵法，v-for中disabled须用computed或$set更新。

uni-app实现商品规格sku选择 uni-app多维属性筛选逻辑

直接说结论：多维规格联动不是靠“穷举所有组合”，而是用已选规格去反向过滤 SKU 列表，再从剩余 SKU 中提取各维度的可用值 —— 这个逻辑一旦写错，就会出现“点完颜色后尺寸全灰”或“库存为 0 的选项还能点”这类问题。

uni-app 中 `isAble` 函数怎么写才不漏判

核心是：每次点击一个规格项（比如“红色”），都要拿当前已选的所有规格（包括刚点的这个）去匹配 sku_list，看哪些 SKU 完全满足这些条件；再从这些匹配的 SKU 中，把其他未选维度的取值集合抽出来，作为下一步可选范围。

常见错误现象：

只用 some() 判断是否存在匹配 SKU，但没做“全字段比对”，导致部分规格被误认为可用
没深拷贝 selectAttr，导致后续点击污染上一次状态
把 sku_name_arr 当字符串直接 .includes()，实际它是个数组，应使用 .every() 或逐项比对

实操建议：

用 JSON.parse(JSON.stringify(this.selectAttr)) 深拷贝当前选择对象
给刚点的项赋值后，遍历 sku_list，对每个 sku 调用 Object.keys(copyselectAttr).every(key => !copyselectAttr[key] || sku.sku_name_arr.includes(copyselectAttr[key]))
匹配成功后，用 new Set() 收集该维度下所有出现过的值，避免重复

为什么不能用二维矩阵预计算所有组合

矩阵法在初始渲染时看似清晰，但真实场景中会快速失效：SKU 表里可能只有 3 个组合（红+S、红+M、蓝+S），但规格维度有 4 个（颜色、尺寸、网络、内存）。矩阵一铺开就是 2×3×3×3=54 格，其中绝大多数根本不存在对应 SKU。

后果很直接：

用户点过一次“红”之后，再点“蓝”，矩阵里残留的旧状态没清空，导致“内存:256G”仍显示可选，尽管 蓝+256G 组合根本没上架
库存变更后无法局部更新矩阵，必须重算整个二维表，性能差且容易出错
后端返回的 sku_list 是扁平结构，硬套矩阵要额外做归类聚合，徒增复杂度

所以别碰矩阵。每次点击都走“过滤 → 提取 → 更新视图”三步，代码更短、逻辑更稳、调试更容易。

`v-for` 渲染规格按钮时 disabled 怎么动态生效

uni-app 的 v-for 绑定的是原始数组，直接改数组里某个对象的 disabled 字段，Vue 不会触发响应式更新 —— 这是很多开发者卡住的关键点。

uni-app

uni-app 是基于 Vue 的跨端开发框架，适合开发 H5、App、小程序、鸿蒙和多端业务应用。

下载

正确做法只有两个：

用 computed 生成带 disabled 字段的新数组，每次依赖 selectAttr 和 sku_list 重新计算
或在 watch 里监听 selectAttr 变化，手动调用 this.$set() 更新每个规格项的 disabled 状态

示例片段（computed 方式）：

computed: {
  specListWithDisabled() {
    return this.attrList.map(spec => ({
      ...spec,
      list: spec.list.map(val => ({
        name: val,
        disabled: !this.isAble(spec.title, val)
      }))
    }))
  }
}

注意：isAble 必须是纯函数，不依赖外部副作用，否则 computed 缓存会出错。

后端返回的 `spec_info` 是 JSON 字段，前端怎么安全解析

数据库里 ec_product_sku.spec_info 是 JSON 类型，存的是类似 {"color":"red","size":"M"} 的结构。但 uni-app 运行在多个平台（微信小程序、H5、App），某些环境下 JSON.parse() 可能抛错或返回 undefined。

实操要点：