请教一个前端暂存数据的问题

[yanz123]

我们有个功能会在前端记录客服的行为，积累了 5 分钟或者积累了 20 条记录就会调接口统一发到后端处理。
如果后端接口报错了，前端就会把这些记录继续暂存在前端，等接口恢复之后统一发给后端。
这种模式下前端可能会无限积累数据。
比较极端的情况是 前端把数据暂存在 localstorage 里面，localstorage 被修改后会有脏数据，这样前端把脏数据发到后端会报 4XX 错误，导致前端永远无法再调通后端接口，除非把 localstorage 清空。
不知道还有没有常见的情况会导致这种无法恢复的场景发生。
这种情况下通常应该怎么设计？
1.前端积累到一定的数据量之后，进入另一个逻辑，比如 100 条就分 5 段发送，有一段不成功就丢弃那段的所有数据？
2.不知道有没有更好的方法。

[darkengine]

@dingjs
@Chad0000

嗯，通过某 AI 查到了这些：

Client-side databases: There are several client-side databases that can be used in front-end development, including IndexedDB, WebSQL, and SQLite. These databases allow you to store and retrieve data on the client-side, and can be used in offline applications.

[LavaC]

浏览器有自带的 indexDB 数据库

[yaphets666]

17 楼说的应该没问题，调接口之前，清空 localStorage 相关字段，调接口后如果失败了，再把数据存回去。

[ccagml]

一定需要 20 条才能发？
如果错了就把 20 分成 10,10 两组发，其中有错了在把 10 分成 5,5 发呢
如果脏数据返回 400+
后端挂了应该会返回 500+

[nekochyan]

如果有脏数据为什么后端不把脏数据是哪些返回给前端，这样前端清掉这些脏数据不就行了吗

[a13761839322]

数据错误是什么原因？代码原因还是业务原因，代码原因保证自己的健壮即可，业务原因就返回对应错误 ，修正数据（剔除错误条目）后 retry

使用 localstorage 出于什么考虑，多 tab 的共享吗？简单点可以直接放内存，内存也没你想的那么脆弱，还方便管理

[darkengine]

@a13761839322 估计有些埋点数据吧，放内存里关掉 tab 就没了。

[xwayway]

或许这些数据并不重要，重要就不会采取这种方式来传输了，既然不重要，默认允许可以失败，即脏数据可以丢弃

[yanz123]

是的 我们有埋点数据 关掉浏览器后数据还得在

[tool2d]

用 indexdb 很合适，就是 API 是异步，而 localstorage 是同步，需要改改代码。

[libook]

后端区分一下故障类型，前端根据后端返回的故障类型来选择策略：

数据格式错误，清除 localstorage ；
其他错误，稍后重试。

[SethShi]

参考别家的系统看看. 用 localstorage 模拟队列.
1. 0~100 先从 队列取到 0~20, 发送成功再删除队头 20 条, 发送失败放到队尾.
2. 限制最大条数, 比如 1W 条, 超过之后老的删除掉.(取决于你的业务是否能删除)
3. 让你们服务端应该不要返回错误, 永远存储数据, 后端自己做数据清洗

[gam2046]

@yanz123 #19 就是#17 说的。后端返回 4xx 状态码就是数据本身的问题，无脑删掉就行了，留着，下次请求也是失败。如果是服务端挂了，返回的是 5xx 状态，或者直接是请求不通，那就留着下次再用呀。

[otakustay]

前端也做个 FIFO 队列呗，实在不行了该丢就丢

[DrakeXiang]

记录行为那就是日志，日志怎么会需要修改和校验？如果后端给不出哪调出错那就只能如楼上所说，要么自己把出错的试出来去掉，要么就整块丢掉，大小自己掌握

[duan602728596]

IndexedDB 啊，前端也是有数据库的。
localstorage 同步，还是存的字符串。不适合这个业务场景。
每条数据可以对应唯一 ID ，重复的数据传到后端也不处理。

[KisekiRemi]

indexDB 啊，定 key 判断，或者加入时间区间，在某个时间区间报错就设定规则删除，具体逻辑看具体需求设置

[wonderl17]

前端校验数据就行了呀，后端那边也可以校验后丢弃不报 4xx 呀

[chairuosen]

让后端改

[Bijiabo]

看起来这个设计有些问题。如果后端一直报错，或者后端用于接收错误的接口有一定概率报错，就比较崩溃了。

如果我来做这个选择，我可能会考虑区别于当前的后端服务，使用一个单独的服务来收集数据。一些用户行为打点的服务，也有错误收集功能。