后台表格最容易变成“所有部门都想加一列”的地方。最后一屏 18 列、每行 6 个按钮、状态标签五颜六色，用户还是要导出 Excel。真正要先解决的是：用户来到这张表，最常完成什么任务。
01 先定义任务，再决定这是不是一张 Table
IBM Carbon 当前 Data Table 指南明确指出，表格适合组织和显示数据、帮助用户定位具体资源，但不应该被当成电子表格应用的替代品。
如果用户需要自由公式、复杂单元格编辑和大规模建模，产品可能真的应该提供 Excel 导出或专门编辑器，而不是把所有能力硬塞进网页表格。
02 列不是“有数据就展示”，而要根据任务分优先级
订单对象可能有 50 个字段，但客服每天只需要订单号、客户、状态、金额、时间和异常原因。其余信息可以在详情或展开区域查看。
列越多，横向扫描越慢。可以支持列设置，但默认视图应该是一套经过设计的工作视图，而不是把选择成本全部交给用户。
03 表头要短、稳定，并告诉用户哪些列可以排序
Carbon 建议列标题保持一到两个词，必要时最多两行。标题过长往往说明字段命名本身需要优化。
如果支持排序，必须有明确 Hover/Focus 和已排序指示。Carbon 的无障碍实现会通过 aria-sort 关联排序状态；设计端也要标注哪些列可排序，不能让开发猜。
04 行 Hover 即使不能点击，也能帮助用户横向扫描
长表格里用户需要把左侧名称和右侧数值对应起来。轻微行高亮可以让视线保持在同一行。Carbon 当前使用指南也建议始终保留 Row Hover 以辅助扫描。
但如果整行可点击，行内又有链接、开关、菜单，要明确交互优先级，避免用户不知道点击空白区域会发生什么。
05 单行操作和批量操作不要混成按钮森林
高频主要操作可以直接显示，低频操作收进 Overflow Menu。用户勾选多行后，再出现 Batch Action 区域，可以减少每行重复按钮。
危险操作要和普通操作分隔，并在执行前根据可撤销程度决定是否确认。不要因为“功能很多”就在每行塞五六个图标。
06 展开行适合补充上下文，不适合塞一个完整详情页
Carbon 支持 expandable data table，用来在有限空间渐进披露更多信息。适合展示备注、附加属性、简短历史。
如果展开后出现复杂 Tabs、表单、十几个操作，说明用户已经进入独立任务，跳转详情页通常更清晰。
07 分页、无限滚动和虚拟列表要根据任务选择
需要记住位置、批量操作、精确跳页的企业后台，传统 Pagination 往往更稳定；日志流或持续加载内容才更适合无限滚动。
数据量非常大时还要考虑服务端筛选与虚拟渲染。设计师不必决定技术细节，但必须了解“显示 10 万行”不是纯视觉问题。
08 表格密度应支持工作效率，而不是追求“看起来高级”
专业用户可能希望一屏看到更多行，低频用户则需要更宽松的行高。可以提供 Compact / Default 等密度选项，但不要牺牲点击区域和可读性。
表格设计成熟的标志不是边框多精致，而是用户能快速定位、比较、操作，并且很少需要离开产品去手工整理同一份数据。
09 冻结列与水平滚动要谨慎组合
当列很多时，固定第一列可以帮助用户保持对象上下文，但冻结三四列会占掉大量可视宽度。特别是在 13 英寸笔记本上，剩余数据区可能只看得到一两列。
固定的应该是用户判断“这一行是谁”最需要的标识，例如名称或订单号，而不是因为左侧字段都很重要就全部锁住。
10 表格状态需要覆盖 Loading、Empty、Error 和权限差异
真实数据表不总有内容。首次使用为空、筛选后为空、接口加载失败、没有权限、部分字段不可见，分别需要不同反馈。
如果统一显示“暂无数据”，用户无法判断是公司没有记录、筛选条件过窄还是系统出错。
11 列设置和保存视图适合专业高频用户
当不同角色确实需要不同字段，可以允许显示/隐藏列、调整顺序并保存 View。例如财务保存“回款视图”，运营保存“交付视图”。
但产品仍应提供优秀默认视图。自定义能力应该增强效率，而不是补救一个所有人都难用的默认表格。
常见问题
后台表格默认应该展示多少列？
没有固定数量。优先展示完成主要任务所需的字段，其余可通过详情、展开或列设置提供。
整行可以点击吗？
可以，但要避免与行内控件冲突，并用 Hover、光标和键盘行为表达清楚。
什么时候使用可展开行？
适合补充少量上下文；如果内容复杂，应进入独立详情页。
表格一定要分页吗？
不一定。分页、无限滚动、虚拟列表应根据数据量和任务选择。
需要提供导出 Excel 吗？
如果用户有跨系统分析、汇报或复杂编辑需求，导出往往是合理能力，而不是设计失败。
相关服务与进一步咨询
链接复制成功
