多选题需用v-model绑定空数组，value设为字符串或数字唯一标识；用uni-checkbox-group包裹并验证selected.length≥N。
uni-app里多选题怎么绑定选中状态
多选题本质是数组操作，不是单个布尔值。用 v-model 绑定到一个空数组，选项的 value 必须是字符串或数字（避免用对象，否则无法正确匹配）。uni-app 的 uni-checkbox 和原生 checkbox 都支持这种绑定方式，但要注意组件是否真正触发了双向更新。
常见错误：把 v-model 指向一个布尔变量，导致只能记住最后一个勾选项；或者 value 写成 {id: 1, label: 'A'}，结果数组里存的是对象引用，后续校验或提交时比对失败。
- 每个选项的
value设为唯一标识，比如"option_a"、"2" - data 中初始化为
selected: []，不要设为null或undefined - 使用
uni-checkbox-group包裹多个uni-checkbox，确保 group 的v-model指向该数组 - 若用原生
checkbox，需手动处理change事件并用push/splice更新数组
提交前如何验证多选题至少选了 N 项
问卷逻辑常要求“至少选 2 项”，不能只靠前端 UI 约束。验证必须在提交前执行，且要区分「必答」和「选填」题型。直接取 selected.length 最可靠，别用 checked 属性或 DOM 查询——uni-app 跨端渲染下 DOM 状态可能滞后。
容易踩的坑：在 onSubmit 里直接写 if (this.selected.length 却没加提示，用户无反馈；或者把验证逻辑写在 computed 里却没在提交时主动调用，导致校验失效。
- 把最小选项数作为题目配置项传入，比如
minSelect: 2，避免硬编码 - 验证函数返回布尔值，并配合
uni.showToast提示具体规则，例如“请至少选择 2 个答案” - 若题目允许不答，
minSelect设为 0；若必答且不限数量，设为 1 - 注意小程序端
uni.showToast的duration默认 1500ms，太短易错过，建议设为 2000
多选题数据如何结构化提交给后端
后端通常期望接收形如 {"question_id": "q3", "answer": ["option_b", "option_d"]} 的结构，而不是扁平的 key-value 对。如果问卷含单选、多选、填空混排，必须按题型归类，否则解析混乱。
典型问题：把所有答案拼成一个大对象提交，导致后端无法区分哪题是多选；或把数组转成逗号字符串（如 "option_b,option_d"）再传，增加后端解析负担且易出错。
- 每道题单独构造一个提交对象，统一用
answer字段存答案值 - 多选题的
answer值保持为数组，不 join、不 stringify - 提交前用
JSON.stringify整体序列化没问题，但不要在字段值里提前做字符串转换 - 若后端要求 answer 是字符串数组（如 Java 后端接收
List<string></string>），前端仍传数组，Spring Boot 默认能自动映射
跨端兼容性要注意 checkbox 的样式和事件触发时机
微信小程序、H5、App 三端对 uni-checkbox 的点击响应速度和 touch 区域表现不一致。H5 下可能点中文字才触发，小程序则整个 checkbox 区域都响应；App 端某些 Android 版本存在 change 事件延迟触发的问题。
最常被忽略的一点：在 H5 页面里，如果 checkbox 外层套了 label 标签又没加 for 属性，点击文字不会触发选中——但 uni-app 的 uni-checkbox 组件默认不生成 label，得自己包一层或改用 click 事件兜底。
- 优先用
uni-checkbox-group+uni-checkbox组合，它比原生checkbox跨端一致性更好 - 避免在 checkbox 上直接写
@change，改用 group 的@change事件统一捕获，防止事件重复或丢失 - 若需点击文字区域也响应，给
uni-checkbox加class="checkbox-item"并设置padding: 12rpx扩大热区 - 真机测试重点看 Android App 和 iOS 微信，这两个环境 checkbox 的 touchend 响应最不稳定
