批量操作确认页应为独立页面而非弹窗，用form包裹hidden输入项实现原生提交，服务端渲染带上下文的确认页并重定向至结果页。
批量操作确认页面不是弹窗，而是独立页面；用纯 HTML + 少量 JS 就能实现，关键在表单结构和提交逻辑的隔离。
确认页必须用 form 包裹所有选中项
浏览器原生表单提交是唯一可靠、无需额外鉴权或防重放的批量执行方式。把每个待操作项转为 <input type="hidden">，name 统一为 ids[] 或 items[]（注意方括号，后端才好接收数组）。
常见错误：用 div 模拟按钮 + fetch 提交 —— 一旦用户刷新或网络中断，操作状态就丢失，且无法用浏览器后退返回确认页。
- 后端接口应只接收
POST /batch/delete这类明确语义的路径，不接受GET带大量 ID 参数 - ID 字段值必须做 HTML 转义，避免注入：
<input type="hidden" name="ids[]" value="<script>"> - 如果 ID 来自 URL 查询参数（如
?id=1&id=2&id=3），服务端需先校验合法性，再透传到确认页生成 hidden 字段
confirm() 不适合批量确认场景
原生 confirm() 弹窗无法定制样式、不能嵌入说明文字、不支持键盘焦点控制，且在部分浏览器（如 iOS Safari）会静默拦截。
真正需要的是「页面级确认」：显示操作对象列表、影响范围提示、取消/继续按钮，并把「继续」绑定到表单提交。
- 不要写
if (confirm('确定删除这5条？')) form.submit() - 取消按钮应指向来源页（
@#@#@#@#@#@#@#@#@#@0），而非location.reload() - 如果操作涉及高危动作（如清空数据库），可加一个必填的
<input type="text" name="confirm_word" placeholder="请输入 'DELETE' ">，服务端比对字符串
服务端返回的确认页要带完整上下文
确认页不是前端拼出来的静态 HTML，它必须由服务端渲染，且包含原始请求中的全部关键信息：操作类型（delete/update）、目标资源类型（user/order/log）、数量、以及每个 ID 对应的可读名称（如用户名、订单号）。
否则用户无法判断「是不是点错了」—— 这是批量操作最常被投诉的问题。
- 避免只显示
ID: 1001, 1002, 1003，而应显示张三（user_1001）、李四（user_1002）、王五（user_1003） - 如果某条数据已不存在或权限不足，服务端应在确认页顶部用
<div class="warning">警告：ID 1004 的用户不存在，将被自动跳过</div>提示 - 操作按钮文案要具体：
删除这 3 个用户，而不是确认执行
最容易被忽略的是「执行后的跳转逻辑」：成功后不能停留在空白确认页，也不该直接跳回列表页导致用户看不到结果。服务端应重定向到结果页（如 /batch/result?task_id=abc123），并在那里展示每条记录的实际处理状态（成功/失败/跳过）及原因。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
