批量操作栏应放在表格顶部更符合用户预期，因其首屏可见、避免滚动遮挡、语义清晰且支持键盘导航与状态同步。
批量操作栏该放在表格顶部还是底部
放在顶部更符合用户预期。用户进入列表页第一眼看到的是筛选和操作入口，而不是先扫完几十条数据才看到“全选”按钮。底部放操作栏容易被滚动遮挡，尤其在移动端或小屏设备上，用户可能根本没意识到有批量功能。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
常见错误是把批量操作栏塞进表格 <thead> 里——这会让语义混乱，屏幕阅读器误读为表头内容；也别用 <code><div> 浮在表格上方盖住滚动区域，会导致固定定位后与表格不同步。
<ul><li>正确做法：用独立的 <code><section class="batch-actions"></section> 包裹，紧贴表格上方（<table> 前），并加 <code>margin-bottom: 1rem
scroll 并动态计算表格顶部偏移，否则会错位怎么实现“全选/反选”又不卡顿
直接遍历所有 <input type="checkbox"> 并设 .checked 属性，在 500+ 行时明显卡顿。本质是 DOM 批量写入触发多次重排重绘。
关键不是“怎么点”，而是“怎么存状态”。不要靠 DOM 属性实时判断是否选中，改用 JavaScript 数组维护选中 ID 列表：
立即学习“前端免费学习笔记（深入）”；
- 点击单个 checkbox 时，用
dataset.id取 ID，includes()判断后push()或filter()更新数组 - “全选”只更新数组：
selectedIds = allRowIds.slice()，不碰 DOM - 渲染选中态交给模板引擎或
classList.toggle()批量操作，而非逐个赋值.checked - 注意：避免在循环中调用
querySelectorAll，缓存好节点引用
批量操作按钮要不要禁用状态
要，但逻辑得对。很多人只在 selectedIds.length === 0 时禁用按钮，这不够。
真实业务中，批量操作常受权限、状态、类型约束。比如“删除”不能作用于已归档订单，“导出”要求至少选中 1 条但不超过 1000 条：
- 禁用条件应组合判断：
!hasPermission('delete') || selectedIds.length === 0 || hasArchived(selectedIds) - 按钮文案也要同步更新，如从“删除”变成“删除（2项）”，再变成“删除（不可用：含已归档）”
- 用
aria-disabled="true"而非仅 CSS 灰显，保障可访问性
怎么让批量操作支持快捷键和键盘导航
鼠标党能点，键盘党也得能用。默认 Tab 键只能跳到第一个 checkbox，批量操作栏被跳过，这是常见盲区。
必须手动管理焦点流：
- 给批量操作栏容器加
tabindex="0"，确保可聚焦 - 按
Shift + Tab从表格最后一行回到操作栏时，自动将焦点落在“全选”按钮上 - 支持空格键切换“全选”按钮状态，
Enter触发当前启用的操作（如“导出”） - 操作执行后，焦点应回到操作栏本身，而非丢失或跳到页面顶部
