刚在看一个 uniapp 项目，里面有一个文件是对 storage 的封装，感觉有点过度封装的样子。

你还是多学习吧。。。

你直接业务层操作 uni.storage 不妥吧

封装一下, 便于打 log 和序列化呀, 你没看把 json 单独拎出来做了非空校验了吗

这样子是为了能够把底层的操作接口跟业务逻辑抽离开，假设未来需要更换底层的接口或者需要增加额外的逻辑，就不用在跳到每个调用 localstorage 的地方来修改，只要统一修改一次，过一遍业务逻辑的测试就可以了，节约了开发的工作量。

这里建议 try catch 一下，JSON.parse 有报错风险

这就是过度封装了，“假设未来 XX”属于典型的过度设计。先不说这个假设有多大可能会实现（应该几乎不会遇到要更换 localStorage 为其他存储类型吧），就算未来要修改，那个时候再考虑封装也不迟，因为那个时候有更多的信息。修改起来就是个查找替换罢了。

`JSON.parse()` 也完全不用 try...catch, 原因是 catch 住然后呢，再原样抛出还是返回 null ？ localStorage 里是自己之前保存的数据，如果这里出问题那说明逻辑上有问题，比如不是 JSON 却用了 `getJson()` 来获取。

很有必要，公司有一个本地修改数据保存的 demo 项目，之前都是在单个页面用 localStorage 的，现在太多了想换别的缓存方案，由于页面太多一直没改，如果是封装的话只需要改一个地方就行

如果是一次性项目 那没啥必要

如果是常用的公共代码，起码 在这里 你可能统一加 prefix 、ttl 处理，更换实现等等而不必担心哪里漏了...

减少读取写入 json 的样板代码而已

屏蔽底层实现细节，留出了足够的扩展空间，同时涉及到的代码量不大，是个好设计

@CSM 你没遇到过，不代表这就是过度封装。
1. 首先逐个替换永远存在遗漏的可能性。其次，等到需要用的时候再替换，这里就已经存在额外的开发成本了，提前设计好，改一次全局就能生效的，非要额外花人力去单独调整，这就是在浪费自己的时间。如果你热爱加班，确实是可以这么做的。
2. JSON.pase 肯定是要加 try...catch 的，出错你可以增加上报，可以加重试逻辑，可以返回默认值，也可以继续抛出异常。而不是等到外网爆炸了卡住了，才跑过来修复问题。

就代码而言写的确实不行，uni storge 自己就做了序列化和反序列化，根本不需要自己写 JSON 序列化
一般都是记录做了存储的键名，或者单独给某个数据做封装

方便切换，挺好的，建议回炉

封装的太简单了

@Niphor #8 确实，之前写微信小程序也做过类似的封装。主要还是微信小程序太坑了，读取 storage 有时候会耗时几百毫秒。体验版开发版正式版共用 storage ，导致必须要给 key 手动加前缀。