根本原因是已选规格与sku组合不匹配被静默忽略，必须点击前用当前已选规格+待选值校验skus存在性，预建map索引、动态过滤可用值、computed返回新数组控制disabled，价格库存由currentsku实时计算并自动fallback可用组合。
uni-app 商品规格切换为什么点不动或选错组合
根本原因不是 UI 没响应，而是「已选规格和 SKU 组合不匹配」被静默忽略。用户点“红色”，再点“XL”，结果价格没变、库存显示 0——大概率是后端返回的 skus 里根本没有 "红色_XL" 这个组合，但前端没做校验，直接把“XL”设为已选，导致后续逻辑全错。
必须在每次点击前，用当前已选规格 + 待选值去查完整 skus 列表，只允许存在匹配项的值可点。不能靠 stock > 0 单字段判断，更不能把所有“XL”都标为可用。
- 后端返回的
spec_str必须严格按specs顺序拼接（如["颜色","尺寸"]→"红色_S"），否则索引错位 -
skus数量超过 50 条时，建议用Map预建索引：const skuMap = new Map(skus.map(s => [s.spec_str, s])) - 用户取消某个规格（比如清空“颜色”），其他规格选项要立刻还原为全量可用，不能残留上次过滤结果
getAvailableValues(specName) 函数怎么写才不卡顿
这个函数是动态过滤的核心，但它在 v-for 渲染中高频调用，写法不对会直接拖慢整个页面。别在每次渲染时遍历全部 skus，先预处理好维度索引。
推荐结构：this.skuIndex = { "颜色": new Set(["红色","白色"]), "尺寸": new Set(["S","M"]) }。生成方式：遍历一次 skus，对每个 spec_str 拆解后往对应 Set 里 add 值。
- 点击“红色”后，
getAvailableValues("尺寸")只需返回Array.from(this.skuIndex["尺寸"]).filter(v => this.skuMap.has(`红色_${v}`)) - 避免在 computed 里重复执行字符串拼接，提前缓存
currentKeyPrefix = 已选规格.join("_") + "_" - 如果规格维度超过 3 个（如颜色/尺寸/材质），拼接 key 时用
JSON.stringify(已选map)更安全，但性能略低，优先用下划线拼接
规格按钮 disabled 状态为什么不更新
直接给原始 specs 数组里的 values 加 disabled 字段没用——Vue 无法侦测数组内对象属性变化，v-for 不会重渲染。
必须用 computed 返回一个全新数组，每个按钮带 disabled 属性：
specButtons(specName) {
const available = this.getAvailableValues(specName);
return this.specs.find(s => s.name === specName)?.values.map(v => ({
value: v,
disabled: !available.includes(v)
}));
}
-
v-for绑定到这个 computed 数组，而不是原始specs - 不要用
splice或push修改原始values，会导致响应失效 - 微信小程序里，
disabled对button有效，但对view+tap无效，得靠 class 控制样式 + 逻辑拦截
价格和库存怎么同步更新才不跳变
价格和库存不是独立字段，它们属于当前匹配的唯一 SKU。用户选完“红色_S”，就该立刻从 skuMap.get("红色_S") 里取 price 和 stock，而不是分别维护 price/stock data 字段。
- 用
computed实时计算当前 SKU：currentSku() { return this.skuMap.get(this.selectedSpecStr) || null } -
selectedSpecStr是由已选规格按顺序拼成的字符串，必须保证顺序和后端一致 - 库存为 0 时，按钮状态要禁用，但 UI 上仍要显示“缺货”，不能隐藏——这是用户决策依据
- H5 端注意
rpx在 price 显示时可能因字体缩放错位，建议价格区域固定字号 +font-family: 'PingFang SC', sans-serif
最易被忽略的是：当用户从“红色_S”切到“白色_M”，中间没有“红色_M”这个组合时，selectedSpecStr 不能留空，得自动 fallback 到第一个可用组合（比如“白色_S”），否则价格库存显示为 null，体验断裂。
