在编程开发中使用Local Storage存储数据是否属于良好实践？

这个问题没有绝对的标准答案，是否属于良好实践完全取决于你存储的内容类型、业务场景、安全要求，你提到的数值、菜单类非敏感前端配置存在Local Storage，属于行业内常规合理的操作，并不违反规范。但Local Storage有明确的适用边界和使用禁忌，具体可以参考以下规则：

适合使用Local Storage的场景 #

• 纯前端交互类配置：比如用户自定义的主题配色、侧边栏折叠状态、菜单展示排序/隐藏配置、操作偏好设置等不需要同步到服务端的非敏感状态，这类内容存Local Storage可以保留用户的使用习惯，刷新/重开页面不需要重新配置，是非常普遍的用法
• 低优先级缓存数据：比如静态枚举值、非敏感的搜索历史、前端临时保存的表单草稿（未提交前的临时内容）等，用Local Storage存储可以减少重复的接口请求，提升页面加载速度
• 同域名跨页面共享的非敏感状态：相比Cookie，Local Storage存储空间更大（通常为5MB），且不会自动随接口请求发送到服务端，更适合做前端层面的跨页面状态共享

禁止使用Local Storage的场景 #

• 任何敏感数据：密码、用户身份凭证（比如JWT Token）、身份证号、手机号、银行卡号等隐私信息，Local Storage属于明文存储，一旦站点出现XSS漏洞，这些数据会被攻击者直接盗取，存在极高的安全风险
• 核心业务数据：订单状态、用户资产、权限配置等直接影响业务逻辑的内容，Local Storage的数据可以被用户随意修改，且用户清理浏览器缓存后数据会直接丢失，存储这类内容会导致业务逻辑混乱、数据不一致
• 大容量结构化数据：Local Storage只有5MB左右的存储空间，超出上限会触发存储报错，大量数据存储更推荐使用IndexedDB

实际使用的最佳实践 #

• 数据做序列化处理：存储非字符串类型的内容（比如数值、对象、数组）时，统一用JSON.stringify()做序列化，读取时用JSON.parse()解析，避免出现类型异常
• 增加数据校验逻辑：从Local Storage读取到的内容不要直接投入业务逻辑使用，一定要先做格式、范围的合法性校验，避免用户手动篡改存储内容导致前端报错
• 做好降级兼容：部分用户可能会手动禁用浏览器的Local Storage功能，代码中要做好兜底逻辑，读取失败时使用默认值，避免页面直接崩溃
• 定期清理过期数据：对于有有效期的缓存内容，存储时要同时记录过期时间，读取时判断是否过期，及时清理无效数据，避免占用存储空间

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