是单选评价场景首选，需确保 name 相同、id 与 label[for] 匹配或嵌套使用，配合 value 语义化取值，并通过 aria-label 或 aria-labelledby 补全无障碍支持。
怎么用 <input type="radio"> 实现单选评价标签
评价场景下最常用的是 1–5 星或「非常不满意」到「非常满意」的单选，<input type="radio"> 是语义正确、无障碍友好、无需 JS 就能提交的首选方案。
关键不是“怎么加标签”，而是“怎么让标签可点击且绑定准确”——很多人漏掉 for 和 id 的配对，导致点击文字没反应。
- 每个
<input>必须有唯一id，对应<label></label>的for属性 - 把
<input>包在<label></label>里也行（此时不用for/id），但要注意样式继承和焦点行为 - 必须设
name相同，否则浏览器当多个独立单选组处理 - 推荐用
value存语义值（如"5"或"very-satisfied"），后端/JS 更好解析
<label> <input type="radio" name="rating" value="5" id="rate5"> ⭐⭐⭐⭐⭐ 非常满意 </label> <label for="rate4"><input type="radio" name="rating" value="4" id="rate4"> ⭐⭐⭐⭐ 满意</label>
为什么不用 <select></select> 做快捷评价标签
<select></select> 看似简单，但在评价场景下有硬伤：移动端唤起下拉菜单打断操作流，视觉反馈弱，无法并排展示图标或文字描述，且默认样式难统一。
更实际的问题是：用户扫一眼要 3 步（点开 → 找选项 → 点击），而 radio 组点一次就完成；而且 <select></select> 的 value 和显示文本强耦合，改文案就得动代码逻辑。
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
立即学习“前端免费学习笔记（深入）”；
- 如果评价项少（≤5）、需强调层级感（如星级），
<input type="radio">+ CSS 排版明显更直接 -
<select></select>适合选项多（如 10+ 种反馈原因）、空间受限的后台表单 - 别为了“少写两行 HTML”牺牲可访问性——
<select></select>的键盘导航体验远不如 radio 组稳定
aria-label 和 aria-labelledby 怎么补全无障碍支持
纯图标（如只放 ★）或缩略文字（如只写「差」「优」）时，屏幕阅读器会读不出完整语义。光靠 CSS 隐藏文字不行，得用 ARIA 明确补全。
- 给整个评价组加
aria-label="请对本次服务打分"，适用于无可见标题的嵌入式场景 - 如果有可见标题（如
<h3>您的满意度？</h3>），优先用aria-labelledby="title-id"关联，比aria-label更利于上下文理解 - 每个 radio 选项本身一般不需要单独
aria-label，除非图标与文字不一致（比如显示「?」但语义是「5 分」） - 别滥用
aria-hidden="true"：隐藏了图标，但没补替代文本，等于直接砍掉信息
CSS 控制布局时容易忽略的交互细节
用 Flex/Grid 排成横排很常见，但几个细节一错，用户点不准、焦点跳失、甚至触屏误触：
- 确保
label或包裹容器有足够点击热区（最小 44×44px），尤其在移动端 - 别对
input[type="radio"]直接设display: none后只靠伪元素模拟——这样会切断原生 focus/checked 状态链，键盘 Tab 会跳过 - 用
:focus-visible而非:focus控制焦点样式，避免鼠标点击时出现多余轮廓线 - 如果用 CSS 变换（如 scale）放大选中项，记得加
transform-origin: center，否则动画偏移导致视觉错位
真正麻烦的从来不是“怎么让它看起来像评价标签”，而是“怎么让它在任意设备、任意交互方式下都可靠响应”。很多所谓‘快捷实现’，上线后才发现盲人用户无法操作，或 iOS Safari 上点击失效——问题往往出在 label 绑定或 focus 状态管理上。
