结论：必须用后端返回的spec_value_ids字段精确匹配，禁用逻辑需每次点击重算，缓存中间状态必翻车；因spec_str拼接顺序受规格增减、sku维度不一致、多语言影响，不可靠。
直接说结论：不能靠前端硬拼字符串推断组合，必须用后端返回的 spec_value_ids 字段做精确匹配；禁用逻辑每次点击都要重算，缓存中间状态必翻车。
为什么 spec_str 拼接顺序会出问题
很多团队拿到后端返回的 sku_list 里只有 sku_name_arr: ["红色", "S"] 或 spec_str: "红色_S"，就默认“第一个值是颜色、第二个是尺寸”。但实际中：
- 后端可能动态增减规格项（比如新增“材质”），顺序一变，前端所有映射全错
- 同一商品不同 SKU 可能规格维度不一致（如部分 SKU 不含“印花”项），
sku_name_arr长度不固定 - 用户语言切换时，“Red”和“红色”顺序可能被本地化打乱
正确做法是要求后端补全 spec_value_ids 字段，格式统一为 "color:red|size:s" 或数组哈希（如 ["color:red", "size:s"]），前端只做字符串包含判断，不依赖位置。
点击一个规格值后，怎么算其他规格哪些该禁用
不是“当前已选下还剩哪些组合”，而是“筛出所有含当前值的 SKU，再看这些 SKU 覆盖了哪些其他规格值”。这个过程必须每次点击都完整执行：
- 先合并当前已选 key，例如
"color:red" - 遍历全部
skus，用sku.spec_value_ids.includes("color:red")筛出可用 SKU 子集 - 对每个未选规格（如
"size"），提取子集中所有size:开头的值，去重得可用集合["s", "m"] - 把
specs中size下不在此集合里的值（如"l"）标记为disabled: true
注意：v-for 绑定的数组不能直接改 item.disabled，得用 computed 生成新数组，否则视图不更新。
uni-app 里怎么避免 onReachBottom 触发太猛影响 SKU 选择器
SKU 选择器常嵌在商品详情页滚动区域里，onReachBottom 在某些安卓机上会连发 3–5 次，导致重复请求或清空已选规格。关键处理点：
- 加节流：用
setTimeout+isLoading标志位，500ms 内只执行一次 - 真到底部才触发：用
uni.createSelectorQuery().select("#detail-content").boundingClientRect()拿容器高度和scrollTop，比对真实位置 - 更稳方案：把列表包进
<scroll-view></scroll-view>，监听其scrolltoupper事件，比页面级onReachBottom更可控
别信“uni-app 自带防抖”，它只管触发时机，不管业务是否重复执行。
使用插件时最容易忽略的兼容细节
像 vk-data-goods-sku-popup 这类主流插件虽省事，但有三个硬伤常被跳过：
-
localdata.spec_list必须是数组，且每个list项必须是对象数组（[{name:"红"},{name:"蓝"}]），传字符串数组会静默失败 -
sku_list中的sku_name_arr必须与spec_list的name顺序严格一致，否则联动价格/图片错位 - 插件内部用
Array.find查找 SKU，iOS 低版本不支持，得手动降级为for循环，否则白屏
最麻烦的是：当商品支持会员专享或白名单时，sku_list 里得带 is_vip_buy 和 buy_white_list 字段，插件默认不读——得自己 patch getSkuBySelected 方法，否则权限控制形同虚设。
