HTML多选仅是用户选择方式，批量操作是业务动作；二者不可混淆，否则导致事件错位、状态不同步、iOS兼容失效等问题。
HTML多选和批量操作不是同一类东西，前者是用户选择方式，后者是业务动作；混淆二者会导致事件监听错位、状态不同步、移动端失效等实际问题。
多选控件本身不触发任何批量逻辑
原生 <select multiple></select> 或 <input type="checkbox"> 只负责维护“是否被选中”这个 DOM 属性，不会自动调用删除接口、导出函数或提交表单。你看到的“批量删除”按钮，背后一定是 JS 显式绑定了 click 事件并读取了选中项。
- 常见错误：给
<select multiple></select>加了change监听，却在回调里直接发请求，结果 iOS 上读不到selectedOptions，返回空数组 - 正确做法：批量操作入口必须独立（如按钮），且 JS 主动收集数据，而非依赖事件自动带出
- 别指望表单 submit 自动完成“批量启用”，
form.submit()只会按 name 发送键值对，没有语义层的动作识别
selectedOptions 和 :checked 的行为差异直接影响兼容性
select.selectedOptions 是现代浏览器推荐方式，但 Safari 在 iOS 15 及更早版本中返回空数组；而 document.querySelectorAll('input[type="checkbox"]:checked') 虽通用，却容易漏掉 disabled 或动态插入未同步状态的元素。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- iOS 兼容方案：批量设置后加
await new Promise(r => setTimeout(r, 0))再读取，或改用Array.from(select.options).filter(opt => opt.selected) - checkbox 场景下务必过滤
el.disabled === false，否则权限受限项会被误计入操作总数 - 动态渲染的 checkbox（如通过
innerHTML插入）可能:checked匹配成功但el.checked === false，需手动同步属性
name 属性写法决定后端能否收到数组
前端选中 5 个项，后端收不到数组不是 JS 没传对，而是 name 命名不符合框架解析规则。PHP 要 name="ids[]"，Spring Boot 却要 name="ids"，Express 默认不支持方括号语法。
立即学习“前端免费学习笔记（深入）”；
- 调试关键：打开 Network → Form Data，看浏览器实际发出的键名，而不是猜后端怎么配
- Node.js 用户必须启用
app.use(express.urlencoded({ extended: true }))才能解析ids[]=1&ids[]=2 - 避免把所有 ID 拼成字符串塞进单个隐藏字段，超长或含特殊字符时极易截断或解析失败
真正卡住人的从来不是“怎么选”，而是“选完怎么稳”
批量操作失败时，前端提示“操作失败”毫无意义；用户勾了 200 条，其中 3 条因权限被跳过、2 条 ID 格式非法、1 条已被删除，这些细节全靠前端预校验和后端响应结构兜底。
- 前端必须做 ID 格式校验（如
/^[a-zA-Z0-9_-]{6,32}$/.test(id)）、去重（[...new Set(ids)]）、阈值确认（>50 条弹窗二次提醒） - 后端返回应包含成功/失败明细，而非笼统布尔值；前端据此高亮失败行并给出具体原因
- 操作完成后，必须重置所有
checked状态，不能依赖用户手动取消——否则下次点“导出”会混入上次残留项
