纯HTML无法实现规格联动选择，必须用JavaScript驱动；select不适合因无法动态过滤选项、移动端兼容差、value与后端specs结构不匹配、禁用状态样式难统一、不支持自定义交互及无障碍缺陷。
纯 HTML 无法实现规格联动选择，必须用 JavaScript 驱动；但 HTML 结构设计不合理，JS 就会写得又长又脆，改一个颜色就得重写半页逻辑。
为什么 select 不适合做商品规格选择器
很多人直接用 套 ，结果发现：选完“红色”后，“XL”选项不能自动过滤掉缺货的组合；禁用某个 后，移动端还是弹出原生选择框；更麻烦的是，select 的 value 是字符串，和后端返回的 specs 对象结构对不上，每次都要手动映射。
-
select无法批量控制单个选项的启用/禁用状态（disabled只能作用于整个控件或单个option，但视觉样式难统一） - 它不支持自定义高亮、多规格并排布局、hover 效果等基础交互需求
- 无障碍方面，
aria-disabled在option上支持差，读屏器常跳过被禁用项而不提示原因
fieldset + input[type="radio"] 的结构怎么搭才不翻车
核心是让每个规格独立可查、状态可溯、数据可比。不要把“颜色”和“尺码”塞进同一个 form 而不加区分。
- 每个规格用一个
包裹，name值必须和后端返回的specs键名一致（比如后端是{"color": "red", "size": "xl"}，那name就得是"color"和"size"） - 每个选项用
，不用中文文本做判断依据（避免el.textContent === "红色"这种脆弱匹配） - 禁用无效选项时，用
aria-disabled="true"+ CSS 控制样式（如[aria-disabled="true"] { opacity: 0.4; cursor: not-allowed; }），别用disabled—— 它会让表单提交时直接忽略该控件 - 所有 radio 必须有
name，否则无法自然互斥；同时确保同一组内value或data-value不重复
JS 怎么快速查到当前选中的完整规格组合
别每次点击都遍历所有 radio，也别拼字符串再 split('|')。用 Map 做预计算，性能和可读性都更好。
- 后端返回的 SKU 列表建议是扁平数组，每个对象带
specs字段，例如：{ specs: {"color": "red", "size": "xl"}, price: 299, stock: 3 } - 前端初始化时建一个
const skuMap = new Map()，key 是Object.values(specs).join('|')（如"red|xl"），value 是整个 SKU 对象 - 用户操作后，用
document.querySelectorAll('input[type="radio"]:checked')拿到所有已选项，再用Array.from(checked).map(el => el.dataset.value)提取值数组，.join('|')得 key，直接查skuMap.get(key) - 没查到说明组合无效，此时应清空其他规格的选中态，或高亮提示“该组合暂无库存”
容易被忽略的细节：状态同步与边界反馈
很多人只管“点一下变色”，却漏掉价格、库存、按钮状态、URL 参数这些必须同步的环节。
- 选中变化后，
price元素内容要更新，且小数位建议用.99单独包裹，方便 CSS 精确控制字号 - “加入购物车”按钮必须带
data-sku-id，禁用时加aria-busy="false"和aria-disabled="true"，不能只靠opacity或pointer-events - URL 中应反映当前规格，比如
?color=red&size=xl，方便分享和刷新后还原；用history.replaceState()更新，别直接改location.search - 首次加载时，如果 URL 里已有参数，JS 要主动触发一次“模拟点击”，把对应 radio 设为
checked并触发状态更新逻辑，否则页面就卡在默认状态
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
