应监听 form 的 submit 事件，用 document.querySelectorAll('input[name="xxx"]:checked').length 校验数量，失败时 preventDefault() 并聚焦首个同名 checkbox；服务端必须二次校验数组长度≥N，兼顾空值、字符串等异常情况。
用 JavaScript 监听 submit 事件做“至少选 N 个”的校验
浏览器原生 required 属性对复选框组无效——它只作用于单个 <input type="checkbox"> 元素，加在多个同名 checkbox 上会导致“全都要勾”，不是“至少一个”。真正能落地的方案是手动拦截表单提交。
常见错误现象：页面提交时没报错、直接发空数据；或用户点了提交按钮毫无反应（JS 报错但没暴露）。
- 必须监听
form的submit事件，不能只靠change或click - 用
document.querySelectorAll('input[name="tags"]:checked')获取已选项，比遍历querySelectorAll('input[name="tags"]')再判断.checked更简洁可靠 - 校验失败时调用
event.preventDefault()阻止提交，并聚焦第一个同名 checkbox（提升可访问性） - 别依赖
form.checkValidity()，它对 checkbox 组永远返回true，哪怕一个都没选
如何正确统计同名复选框的已选数量
关键陷阱在于：用 CSS 伪类 :checked 查询和用 JS 属性 .checked 判断，在事件触发瞬间可能不一致。比如在 click 中读 event.target.checked 是旧值，而 document.querySelectorAll(':checked') 已反映新状态——但仅限于已渲染完成的 DOM。
所以最稳的做法是：在校验逻辑里统一用 document.querySelectorAll('input[name="interests"]:checked').length，它不依赖事件目标，也不受事件触发时机干扰。
立即学习“前端免费学习笔记（深入）”；
- 避免写
Array.from(inputs).filter(i => i.checked).length，多一步转换且易漏掉动态插入的元素 - 如果复选框是 JS 渲染（如权限树、搜索结果），确保 querySelectorAll 范围覆盖到它们所在的容器，或用
form.elements['interests']（兼容性更好） -
name值含方括号（如hobby[]）不影响选择器，input[name="hobby\[\]"]:checked需转义，但通常直接用name="hobby[]"+querySelectorAll即可匹配
服务端必须二次校验，前端限制纯属体验层
任何通过 JS 实现的“最少选 N 个”都可被绕过：DevTools 直接改 DOM、禁用 JS 后提交、curl 手动发请求……这些操作下前端逻辑完全失效。
后端收到数据后，必须重新解析该字段（如 PHP 的 $_POST['tags'] 或 Node.js 的 req.body.tags），检查数组长度是否 ≥ N。否则会出现脏数据、权限越界、订单异常等生产问题。
- 不要假设前端传来的数组一定存在——
undefined、null、空数组、字符串"on"（IE 旧行为）都要兜底处理 - 如果字段允许为空（即“不选”是合法状态），需明确区分“用户主动不选”和“前端校验失败后未提交”两种语义
- API 返回的错误信息应与前端提示一致，比如返回
{"error": "至少选择2个标签"}，方便统一展示
要不要用单选按钮模拟“至少选一个”？
可以，但仅适用于“逻辑上单选”或“组合项可穷举”的场景。比如时间段选“上午”“下午”“全天”，用 radio + required 就够了；但若真实需求是“从 20 个兴趣标签里至少挑 2 个”，硬塞进 radio 就会失控。
强行用 radio 模拟多选，会导致 HTML 语义错乱、无障碍支持变差（屏幕阅读器会误读为单选组）、后期维护成本飙升。
- radio 的
name必须完全一致才能分组，跨表单或嵌套组件时容易冲突 - 无法原生支持“取消再重选”，用户点错只能刷新页面或额外加“清空”按钮
- 如果某项需要动态增删（如权限列表随角色变化），radio 的 DOM 更新和事件绑定比 checkbox 更难管理
