uni-app实现复杂的SKU商品属性选择器 uni-app规格算法实现-uni-app-PHP中文网

sku组合禁用状态通过交叉排除法实时计算：先建属性值映射表，再对已选规格id集合求交集，为空则禁用；uni-app中用selectedspecs对象统一管理选中态，点击时校验禁用、更新状态并清空后续规格；避免watch深度监听，改用事件驱动+防抖更新；后端应返回结构化specs与skulist，库存为0的sku不参与交集运算。

uni-app实现复杂的sku商品属性选择器 uni-app规格算法实现

SKU组合数据如何生成并标记可选/禁用状态

核心在于「交叉排除法」：不能简单预存所有有效组合，而要实时计算当前已选属性下，其他属性还有哪些值可选。uni-app里通常用 computed 或 watch 做响应式推导，但要注意避免循环依赖和性能抖动。

常见错误是把后端返回的 skuList 直接 flatten 后去重取值——这会导致禁用逻辑失效。正确做法是先建一张「属性值映射表」：

const specMap = {}
skuList.forEach(sku => {
  sku.specs.forEach(spec => {
    const key = `${spec.name}_${spec.value}`
    if (!specMap[key]) specMap[key] = new Set()
    specMap[key].add(sku.id)
  })
})

再对每个待选规格项做交集判断：Array.from(specMap[当前规格键]).filter(id => 已选其他规格对应的所有 skuId 集合是否包含该 id)。为空则禁用。

uni-app中点击规格项时如何更新选中状态与联动禁用

不要用 v-model 绑定多个规格，而是统一维护一个 selectedSpecs 对象（如 {颜色: '红色', 尺寸: 'L'}），每次点击只更新一个键值对，然后触发重新计算。

关键点有三个：

点击某规格前，先检查它是否已被禁用（即当前已选条件下无任何 SKU 覆盖它）
点击后清空「后续未选规格」的所有选中态，防止出现非法组合
禁用态样式不能仅靠 disabled 属性（小程序不支持原生 disabled 样式穿透），要用 class + isDisabled 数据字段控制

示例片段：

uni-app

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

下载

handleSpecClick(specName, specValue) {
  if (this.isSpecDisabled(specName, specValue)) return
  this.selectedSpecs = { ...this.selectedSpecs, [specName]: specValue }
  // 清除后续规格
  const allSpecNames = this.specList.map(s => s.name)
  const currentIndex = allSpecNames.indexOf(specName)
  Object.keys(this.selectedSpecs).forEach(name => {
    if (allSpecNames.indexOf(name) > currentIndex) {
      this.$delete(this.selectedSpecs, name)
    }
  })
}

为什么 uni-app 的 `watch` 在规格联动中容易卡顿或漏更新

因为 selectedSpecs 是对象，深度监听开销大；且小程序 setData 有频率限制，频繁触发会排队、丢帧。

解决方案分两层：

用 watch 的 immediate: false + deep: false，只监听对象引用变化，内部用 JSON.stringify 做浅比较（适合规格数 ≤ 5 的场景）
更稳的做法是放弃自动监听，改用「事件驱动」：每次点击都显式调用 updateAvailableSpecs()，并在该函数里批量计算所有禁用态，最后一次性更新 availableSpecs 响应式数据
务必加防抖，特别是 H5 端用户可能连点，setTimeout 延迟 16ms 再执行计算逻辑，能明显缓解卡顿

后端返回的 SKU 数据结构怎么设计才利于前端算法处理

别让前端拼字符串做 key。后端应返回标准化的二维数组结构，例如：

{
  "specs": [
    { "name": "颜色", "values": ["红色", "蓝色"] },
    { "name": "尺寸", "values": ["S", "M", "L"] }
  ],
  "skuList": [
    {
      "id": 1001,
      "specs": [{ "name": "颜色", "value": "红色" }, { "name": "尺寸", "value": "M" }],
      "price": 99,
      "stock": 5
    }
  ]
}

这样前端无需解析字符串、正则匹配或约定分隔符，直接用 findIndex 和 every 就能完成组合校验。如果后端坚持返回扁平化 spec_key: "颜色-红色|尺寸-M"，前端必须在 onLoad 阶段就做一次格式归一化，否则后续所有逻辑都会变脆弱。

最易被忽略的是库存为 0 的 SKU 是否参与禁用计算——应该参与。否则用户可能选到「理论上存在但实际无货」的组合，导致提交时报错。禁用逻辑里，只要 sku.stock > 0 才计入交集运算。