Spotify API曲目本地会话存储与读取功能异常问题

嘿，看起来你在sessionStorage存储Spotify曲目和组件渲染这块碰到了两个典型的小问题，我来帮你拆解下可能的原因和对应的解决办法～

问题1：checkPlaylistName() 误进入if代码块（即使session存储值为undefined） #

这种情况大概率是判断条件的逻辑有漏洞，或者存值时不小心把undefined转成了字符串"undefined"导致的：

常见原因 #

1. 直接用if (sessionStorage.getItem('yourKey'))做判断：如果之前存值时，把undefined直接存进去（比如没做判断就JSON.stringify(undefined)），那getItem拿到的会是字符串"undefined"，这个字符串在布尔判断里是true，就会误进if块。
2. 读取时没做解析或类型校验：比如直接拿原始字符串做判断，而不是先解析成数组再判断长度。

解决步骤 #

1. 规范存值逻辑：存之前先校验数据，避免存undefined或无效值：

   // 从Spotify API获取曲目后
   const spotifyTracks = await fetchSpotifyTracks(); // 你的API请求函数
   // 确保存的是有效数组，哪怕是空数组也比undefined好
   sessionStorage.setItem('savedTracks', JSON.stringify(spotifyTracks || []));
   

2. 修正checkPlaylistName的判断逻辑：先解析、再校验类型，最后判断：

   function checkPlaylistName() {
     const savedTracksStr = sessionStorage.getItem('savedTracks');
     // 解析时做容错，确保拿到的是数组
     const savedTracks = savedTracksStr ? JSON.parse(savedTracksStr) : [];
     
     // 只有当数组有内容时才进入if块
     if (Array.isArray(savedTracks) && savedTracks.length > 0) {
       // 你的业务逻辑
       console.log('进入目标代码块');
     }
   }
   

3. 清理无效存储：如果之前已经存了"undefined"字符串，先在控制台执行sessionStorage.removeItem('savedTracks')清空一下，避免干扰。

问题2：render语句中的控制台日志执行两次，第一次空数组，第二次undefined #

这个问题基本是组件重渲染+状态初始化/更新不规范导致的，比如React组件（假设你用的是React）的生命周期或状态设置逻辑有问题：

常见原因 #

1. 组件初始化时状态默认值是undefined，第一次渲染用了临时设置的空数组，然后异步读取sessionStorage时，错误地把状态设置成了undefined，触发第二次渲染。
2. 读取sessionStorage的逻辑没放在合适的钩子（比如useEffect）里，导致每次渲染都执行，甚至重复设置状态。

解决步骤 #

1. 给状态设置正确的默认值：确保初始化时状态是空数组，而不是undefined：

   // 比如React组件里的状态
   const [tracks, setTracks] = useState([]); // 这里默认是空数组，不是undefined
   

2. 把读取sessionStorage的逻辑放在 useEffect 里，确保只执行一次：

   useEffect(() => {
     const savedTracksStr = sessionStorage.getItem('savedTracks');
     if (savedTracksStr) {
       try {
         const parsedTracks = JSON.parse(savedTracksStr);
         // 强制校验类型，避免非数组值污染状态
         setTracks(Array.isArray(parsedTracks) ? parsedTracks : []);
       } catch (err) {
         console.error('解析sessionStorage曲目失败:', err);
         setTracks([]); // 解析失败也设为空数组
       }
     }
   }, []); // 空依赖数组，仅在组件挂载时执行一次
   

3. 检查是否有其他触发重渲染的因素：比如父组件传递的props频繁变化，或者其他状态更新逻辑不小心触发了重渲染，可以用React DevTools的Profiler工具排查下重渲染原因。

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