首先vuex是状态，又不是缓存。想要存储数据，可以使用indexedDB。然后就是更新缓存的问题，这个确实是一个很常见的难题。没有太完美的解决方案，只能根据项目要求进行取舍。

顺晟科技：

你说的标记，就是数据的版本信息，可以是数据的最后更新时间，如果一致就不用再次从后端获取了。

简单地说，就是这样了。

首先，可以用indexedDB作为缓存的容器，用websql也可以，只是不推荐。然后缓存更新的问题嘛，可以这样。

前端可以先显示缓存的数据，然后给个提示，检查更新中… 。等待后端返回结果，如果是最新，那么告知用户，已经是最新数据；如果不是最新，可以告知用户，数据有更新，现已替换成最新数据。

如 @qq326943819 所说，这类需求通常适合放到服务端来做，因为缓存也是可以跨会话有效的。这虽然不能减少客户端的流量消耗，但可以有效减少服务端的计算消耗。具体的方案就很多了，Redis 是常见方案之一。

在用户页面操作的过程中，需要频繁的向后端发起数据请求，其中很多请求参数和请求结果是一致的。我想在这些请求时，是否可以使用上一次的请求结果，因此将这些请求存入vuex或者缓存？

首先，感谢之前的回复。

所以我也真想不出来需要前端做复杂计算和存储的场景，甚至更进一步，我期望的是前端不做任何计算。我更期望前端能够给用户一个操作体验上的优化。在产品繁多的互联网时代，这才是赢得用户和做好一款产品的致臻。

我的需求，确实是想在前端做一个缓存系统。作用类似后端的Redis。

另外：服务端计算和缓存问题，这个交给服务端的大神们吧。其实我是以前端开发思考，提出的问题。前端的确不适合做复杂的计算。

总结你的需求，其实就是一个缓存系统。

我个人是很忌讳在前端做复杂的计算或者存储的，原因很简单，客户端的性能是无法估量的，较复杂的操作放在前端来处理，不是很明智的处理

在需要显示数据的时候：

不过好像很多数据接口，即使请求参数一致，但请求结果是可变的，因此缓存这一部分是没有意义的了。

如果本地没有缓存，那肯定是向后端申请了。

当前我是将vuex当做“缓存”来用，就是我会将请求后端当前用户信息的数据全部放到vuex里面，在不同页面使用。

至于缓存，或者你说的服务端计算次数多，Redis就是来解决这个痛点的。甚至还有很多很多解决服务端压力的现成方案，诸如分布式、微服务等，每一个都那么。

1、字典数据、变化频繁的数据且不涉及机密的，适合在前端做缓存，比如部门信息、员工的基本信息等。这些数据缓存起来，可以减轻后端很多工作。2、一般可以放在indexedDB里面，只是相关代码并不是那么容易搞定。3、后端数据变了，前端数据如何在时间更新？4、有些数据很铭感，有些数据涉及到权限，这些数据如果在前端缓存，是否会造成泄密？这些都是需要考虑的。

这样看来，只能是部分数据缓存了，而且需要根据业务场景做适配了。

感谢前面的回复。

如果一定要在客户端实现（比如为了省流量），本质上也是做一个类 Redis 的东西。用不用 Vuex 不重要，它只是提供了一套 API 而已。具体的实现上，如果有机会做业务分析，对可以缓存的接口按参数构建 key，丢到一个 map 里，请求优先返回 map 里的匹配；对不可以缓存的（前端无法根据已有知识确定缓存是否有效），服务端返回一个时间戳（比如通过一个 HEAD 请求），通过比对时间戳来确定是否请求新数据。

讲个亲身经历的问题

需要像你主题所说的需要前端缓存的场景就只能是减少用户的网络流量使用，但是我觉得目前的环境下，遇到这种需求只怕是万一的概率。

在一个聊天室场景，用户需要显示等级标志，服务端每次只给我用户的积分，我需要对照积分去计算用户的等级，当聊天信息到达40个以上（即需要40个计算过程），在移动端的新机型上跑起来没任何问题，但是换了一个老点的安卓，进入到这个页面则卡死了。后来计算直接由服务器进行，前端只是做等级展示，则解决了这个问题

甚至可以做个版本对比，告知用户，本次更新涉及了哪些数据。git的版本对比用过吧。

另外，关于前端做复杂计算和存储，我倒是保持支持的态度，这样可以分担服务器的压力吧。比如年龄计算，如果都让后端服务器计算，随着用户量增多，服务器需要计算的次数越多，分摊给前端，每个用户那里只需要计算一次。（服务器配置的处理能力太强悍，或者分布式之类的另算，也可能与项目大小相关）

缓存方案：1，内容：[常用 && 不经常修改]=>当前用户信息：用户ID、头像、昵称。=>字典数据：性别映射、业务分类数据。：这样看来，其实需要缓存的数据不多啊[不常用 || 经常修改]：使用次数不多，没必要缓存2，更新：在修改用户信息时，将缓存标识更新。（缺点：后台修改，不能检查到）请求参数增加一个最后修改的时间戳，有更新返回更新。（缺点：这样业务逻辑复杂化了）缓存时限。（缺点：即使时限在短，也不能保证用户看到的最新数据）

还是那个观点，客户端的性能是无法预估的，很多操作服务端或者前端都是可以操作、处理的，但是为什么我提倡放在服务端合适，因为前端最最主要的职责，还是只是提供展示。作为最靠近用户的一层，如何让用户操作起来更顺畅，体验更好才是前端最正确的职责。

如果本地有缓存，那么把缓存标识发给后端，后端判断是否最新，如果是最新不用发送数据，只需要告知即可。如果不是最新，那么发送最新数据。（这个就需要后端配合了）

痛点方向应该是去研究服务端的Redis，而不是在前端来做这种冗余的操作

我是支持在前端做数据缓存的，只是这不是一件简单的事情。1、哪些数据适合，哪些数据不适合。2、如何缓存3、如何更新4、涉密数据怎么办