TableListVulnerabilities组件刷新后数据丢失问题排查

以下是针对TableListVulnerabilities组件刷新后数据丢失问题的具体排查步骤：

1. 确认sessionStorage的写入逻辑是否可靠 #

• 检查数据写入时机：必须确保在接口请求成功返回数据后才执行sessionStorage.setItem()，比如放在请求的then回调或await之后。如果写入逻辑在请求发起前、错误分支里，或者请求失败时没有处理，刷新后自然没有持久化数据。
• 核对键名一致性：sessionStorage的键名区分大小写，比如'vulData'和'VulData'是两个不同的键，写入和读取时必须完全匹配。

2. 检查数据序列化/反序列化是否正确 #

sessionStorage仅支持存储字符串类型，任何对象类型数据必须经过转换：

• 写入时必须用JSON.stringify()将数据转为字符串，避免直接存储对象导致变成[object Object]这种无效值。
• 读取时必须用JSON.parse()将字符串转回对象，否则拿到的是原始字符串，无法正常渲染。
• 额外注意：如果数据包含循环引用，JSON.stringify()会抛出错误，导致写入失败，需先处理循环引用问题。

3. 组件初始化时的读取逻辑是否缺失 #

组件刷新后会重新初始化，必须在加载时主动从sessionStorage读取数据：

• 优先在状态初始化时读取：比如用函数式初始化state，确保组件挂载时直接拿到持久化数据：

  const [vulData, setVulData] = useState(() => {
    const stored = sessionStorage.getItem('vulData');
    return stored ? JSON.parse(stored) : [];
  });
  

• 避免仅依赖接口请求填充状态：如果刷新时接口请求未返回（或失败），而又没有读取sessionStorage的逻辑，组件会显示空白。

4. 排查数据是否被意外清除 #

• 检查代码中是否存在sessionStorage.clear()或sessionStorage.removeItem('vulData')的调用，可能在其他逻辑（比如路由跳转、组件卸载）中误删了数据。
• 排除浏览器隐私模式影响：隐私模式下sessionStorage会在标签页关闭时清除，但刷新页面时应保留数据，可切换普通模式测试。

5. 异步请求与读取逻辑的顺序问题 #

如果组件初始化时先发起接口请求，再读取sessionStorage，会导致请求返回后覆盖持久化数据：

• 正确顺序：先读取sessionStorage填充状态，再发起接口请求更新数据（如果需要最新数据），确保刷新后先显示缓存数据，再更新为最新数据。

关联组件影响排查 #

检查ListVulnerableDevices组件是否存在以下情况：

• 是否使用了相同的sessionStorage键名，导致数据被覆盖。
• 是否有修改或删除目标键数据的逻辑，影响TableListVulnerabilities组件的持久化数据。

内容的提问来源于stack exchange，提问作者Jas Verma