SKU组合禁用状态通过交叉排除法实时计算：先建属性值映射表，再对已选规格ID集合求交集，为空则禁用；uni-app中用selectedSpecs对象统一管理选中态，点击时校验禁用、更新状态并清空后续规格；避免watch深度监听，改用事件驱动+防抖更新；后端应返回结构化specs与skuList，库存为0的SKU不参与交集运算。
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数据字段控制
示例片段：
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 才计入交集运算。
