登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  前端

前端表格列设置刷新后丢失怎么办:可见列、列宽和顺序这样保存

来源:17golang原创

时间:2026-06-29 15:23:35 351浏览 收藏

后台表格经常提供“列设置”:用户可以隐藏不关心的列、调整列宽、把常用列拖到前面。但不少页面刷新后又回到默认列,用户每次打开都要重新配置。问题看起来只是一个小交互,实际上涉及用户偏好数据如何保存、恢复、升级和清理。

本文按问答方式回答:表格列设置应该存在哪里,存什么结构,字段变更后怎么兼容,什么时候需要清理,以及如何避免旧配置把新表格带偏。

目录
  • 问题原文:为什么表格列设置刷新后丢失
  • 先给结论:列偏好要有 key、版本和默认值
  • 常见误区:只存一个可见列数组还不够
  • 正确做法:按数据生命周期保存和恢复
  • 边界情况:字段改名、列删除和多页面共用
  • 延伸问题:什么时候该同步到服务端

问题原文:为什么表格列设置刷新后丢失

常见问题是这样的:

后台订单表格里,用户隐藏了“备注”“渠道”两列,又把“支付时间”拖到前面。刷新页面后配置全部没了。这个应该用 localStorage 存吗?怎么避免以后新增列或删除列时出错?

这个问题不能只回答“存 localStorage”。表格列配置至少有三类数据:可见列、列宽、列顺序。它们都和当前页面、当前用户、当前表格版本有关。如果只把一个数组随手写进去,短期能恢复,长期容易遇到旧字段、脏数据和不同表格互相覆盖。

先给结论:列偏好要有 key、版本和默认值

推荐做法是:每个表格使用独立的存储 key,保存带版本的配置对象;读取时先检查版本,再过滤不存在的列,最后和默认列合并。这样既能恢复用户偏好,也不会因为业务列变更导致页面异常。

一个较稳的结构如下:

const TABLE_PREF_VERSION = 3;
const TABLE_PREF_KEY = "orders.table.columns.v3";

const defaultColumns = [
  { key: "orderNo", title: "订单号", width: 160, visible: true },
  { key: "amount", title: "金额", width: 120, visible: true },
  { key: "paidAt", title: "支付时间", width: 180, visible: true },
  { key: "remark", title: "备注", width: 220, visible: false },
];

const tablePrefs = {
  version: TABLE_PREF_VERSION,
  updatedAt: Date.now(),
  columns: [
    { key: "orderNo", width: 180, visible: true },
    { key: "paidAt", width: 180, visible: true },
    { key: "amount", width: 120, visible: true },
    { key: "remark", width: 220, visible: false },
  ],
};

这里不重复存 title,因为列标题属于代码里的默认列定义;偏好只保存用户改过的状态。这样标题文案改了以后,不会被旧缓存覆盖。

常见误区:只存一个可见列数组还不够

很多页面只存下面这种结构:

localStorage.setItem("orders.columns", JSON.stringify(["orderNo", "amount"]));

它能解决“隐藏列后刷新恢复”的最小问题,但会留下几个坑:

  • 没有列宽,用户拖过的宽度无法恢复。
  • 没有顺序,拖拽排序后刷新仍回默认顺序。
  • 没有版本,字段改名后旧 key 会继续参与渲染。
  • 没有默认值合并,新增列可能永远不出现。

列偏好不是单个布尔值,而是一份小型配置数据。它需要从用户操作进入存储,再从存储恢复到表格渲染,最后在字段变更时清理或迁移。

正确做法:按数据生命周期保存和恢复

把列配置看作一条数据生命周期,会更容易设计:用户操作产生偏好,偏好经过字段过滤后写入本地存储;页面初始化时读取偏好,检查版本,合并默认列,最后渲染表格。

前端表格列配置数据生命周期:用户调整列、生成偏好、过滤字段、写入本地存储、读取恢复、渲染表格

下面是一个简化实现:

function saveColumnPrefs(columns) {
  const payload = {
    version: TABLE_PREF_VERSION,
    updatedAt: Date.now(),
    columns: columns.map((column) => ({
      key: column.key,
      width: column.width,
      visible: column.visible !== false,
    })),
  };

  localStorage.setItem(TABLE_PREF_KEY, JSON.stringify(payload));
}

function readColumnPrefs() {
  const raw = localStorage.getItem(TABLE_PREF_KEY);
  if (!raw) return null;

  try {
    return JSON.parse(raw);
  } catch {
    localStorage.removeItem(TABLE_PREF_KEY);
    return null;
  }
}

恢复时不能直接相信本地数据。先建立默认列索引,再按偏好里的 key 合并。

function restoreColumns(defaultList) {
  const prefs = readColumnPrefs();
  const defaultMap = new Map(defaultList.map((column) => [column.key, column]));

  if (!prefs || prefs.version !== TABLE_PREF_VERSION) {
    return defaultList;
  }

  const restored = [];
  const usedKeys = new Set();

  for (const item of prefs.columns || []) {
    const base = defaultMap.get(item.key);
    if (!base) continue;

    restored.push({
      ...base,
      width: typeof item.width === "number" ? item.width : base.width,
      visible: item.visible !== false,
    });
    usedKeys.add(item.key);
  }

  for (const column of defaultList) {
    if (!usedKeys.has(column.key)) {
      restored.push(column);
    }
  }

  return restored;
}

这个恢复逻辑做了三件事:旧字段会被过滤掉;保存过的列按用户顺序恢复;新增列会追加进来,不会因为旧配置而消失。

边界情况:字段改名、列删除和多页面共用

表格列配置最容易坏在边界情况。下面这几类要提前定规则。

字段改名

如果 paidAt 改成 payTime,最好升级版本并清理旧配置,或者写一段明确迁移逻辑。不要让旧字段继续混在配置里。

列被删除

列被删除后,恢复函数应该自动跳过不存在的 key。上面的 defaultMap.get(item.key) 就是在做这件事。

多页面共用

不同页面不要共用同一个 key。订单列表、退款列表、用户列表即使列名相似,也应该分别使用独立 key,例如:

const orderTableKey = "orders.table.columns.v3";
const refundTableKey = "refunds.table.columns.v1";
const userTableKey = "users.table.columns.v2";

用户需要恢复默认

列设置弹窗里建议保留“恢复默认”按钮。本质就是移除当前表格的偏好数据,再用默认列重新渲染。

function resetColumnPrefs() {
  localStorage.removeItem(TABLE_PREF_KEY);
  return defaultColumns;
}

前端表格列配置恢复路径:读取本地偏好、检查版本、过滤旧字段、合并默认列、渲染表格

延伸问题:什么时候该同步到服务端

如果表格只在单个浏览器里使用,localStorage 足够简单。但下面几种情况更适合同步到服务端:

  • 同一个账号需要在多台设备上共享列设置。
  • 企业后台要求管理员统一下发表格默认列。
  • 列配置和权限相关,不能只依赖浏览器本地数据。
  • 用户偏好需要审计或跨浏览器迁移。

服务端保存时也不要省掉版本和默认值合并。前端仍然要对服务端返回的配置做字段过滤,因为后端保存的也可能是旧版本偏好。

延伸问题:存列宽会不会影响响应式

会有影响。列宽建议只在桌面端或大屏后台页面里恢复;移动端或窄屏场景可以忽略宽度,只恢复可见列和顺序。否则用户在大屏拖出的宽度,到了小屏可能让表格横向滚动过度。

总结

前端表格列设置刷新后丢失,本质不是一个按钮状态问题,而是一份用户偏好数据的生命周期问题。推荐保存 versionupdatedAt 和列偏好数组;恢复时检查版本、过滤不存在字段、合并默认列;同时提供恢复默认入口。这样既能记住用户习惯,也能在业务列变化后保持页面稳定。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>