真正可用的多选应使用 <div> + <input type="checkbox"> 模拟，而非依赖原生 <select multiple>；若必须用原生，需加 click 事件聚焦修复 iOS 兼容性，并注意动态元素、disabled 状态及 indeterminate 情况下的选中项获取。
怎么让 <select> 真正支持多选
浏览器默认的 <select multiple> 能多选，但用户必须按住 Ctrl（Windows）或 Cmd（macOS）才能点选多个——这在实际业务中几乎没人记得，导致“多选”形同虚设。
真正可用的多选，得靠 JavaScript 拦截点击行为，自己维护选中状态。常见做法是用 <div> + <input type="checkbox"> 模拟，而不是依赖原生 <select>。
- 原生
<select multiple>无法自定义样式，移动端体验差，且不支持搜索、分组折叠等扩展功能 - 用 checkbox 列表时，记得给每个
input设置相同的name和唯一的value，后端才能正确接收数组（如ids[]=1&ids[]=3&ids[]=5） - 如果必须用原生
<select>（比如表单校验强依赖form.checkValidity()），至少加一句select.addEventListener('click', e => e.target.focus())，避免 iOS 上点击无响应
querySelectorAll 批量获取选中项时容易漏掉什么
很多人写 document.querySelectorAll('input[type="checkbox"]:checked') 就以为完事了，但实际常漏掉三类情况：
- 动态插入的 checkbox（比如通过
innerHTML或appendChild添加），没绑定事件监听，:checked伪类能匹配上，但 JS 里elem.checked可能还是false（因为 DOM 更新未触发属性同步） - 被
disabled的 checkbox，:checked仍会匹配，但通常业务逻辑里不该计入“有效选中”，需额外过滤：Array.from(els).filter(el => !el.disabled) - 使用了
indeterminate状态的父级 checkbox（如树形选择器），它本身没被勾选，但子项有选中，此时仅靠:checked会漏掉整个分支
批量操作前，为什么一定要做「ID 预校验」
用户勾了 200 个项，你直接发个 POST /api/delete 带 200 个 ID？出错时根本没法定位是哪个 ID 导致失败。更糟的是，如果其中混入了非法格式（比如 "abc" 或空字符串），后端可能 500，前端却只显示“操作失败”。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 前端应先用正则或
Number.isInteger(+id)过滤非数字 ID；字符串 ID 则用/^[a-zA-Z0-9_-]{6,32}$/.test(id)校验长度和字符集 - 对重复 ID 去重：
[...new Set(ids)]，避免数据库误删或接口幂等性被破坏 - 超过阈值（比如 > 50）要弹窗确认：“即将操作
78条数据，确认继续？”——不是防手滑，是防误触“全选”后没取消某几项
用 fetch 批量提交时，body 怎么组织最稳妥
别一股脑把几百个 ID 拼成 URL 参数（?id=1&id=2&...），URL 长度超限会静默截断；也别用 application/x-www-form-urlencoded 发大数组，部分老网关会拒绝解析。
- 推荐用
application/json，body 写成{ "ids": ["1", "2", "3"], "action": "archive" }，后端统一收req.body.ids - 如果后端只认表单格式（比如 Django 的
request.POST.getlist('ids')），就用FormData：const fd = new FormData(); ids.forEach(id => fd.append('ids', id))，然后fetch(url, { method: 'POST', body: fd }) - 注意：
FormData提交时，Content-Type会被自动设为带 boundary 的 multipart，后端必须能处理；若用fetch+FormData却收不到数据，大概率是后端没读request.body而是去查request.json
批量操作真正的难点不在“怎么选”，而在“选完之后怎么让每一步都可追溯、可中断、可重试”。比如删除操作，前端发请求前记下当前选中的 ID 列表快照；失败后展示具体哪几个 ID 报错，而不是只说“部分失败”。这些细节，往往比多选 UI 本身更消耗开发时间。
