双token+优化+endcase

实现思路 流程图 优化点+endcase 全局错误提示防刷屏场景: 在复杂的前端应用中（如数据看板、工作台或高并发的后台系统），页面初始化或用户操作时往往会在同一时间发起多个并发 API 请求。当遇到突发状况（如网络彻底断开、服务器宕机或登录凭证突发失效）时，这些并发请求会在同一毫秒级内同时失败并进入 Axios 的错误拦截器。 问题: 组件提示刷屏（视觉灾难）：如果直接在拦截器中调用 message.error()，由于并发请求同时失败，UI 界面会瞬间弹出一大叠、甚至几十个完全相同的错误提示（如“网络连接失败”），层层叠加直接遮挡系统画面，用户体验极差。 解决方案:[总结为从时间,内容,源头,组件配置四个方面的各自优化] 全局消息防抖 / 节流 实现原理：限制单位时间内（比如 2 秒内）只允许执行一次弹窗。 优点：代码量极少，直接引库，一行代码搞定。 致命缺点（吞报错）：它是不看内容的。如果高并发请求中，第一个请求报的是 网络断开（被弹窗），第二个紧随其后的请求报的是 余额不足 或 权限不足，后面的核心业务报错就会被节流直接“无情吞掉”，导致用户漏掉关键信息。 基于内容的“状态单例锁” 实现原理：利用 Set 集合存储当前正在显示的错误文本，配合 UI 组件的 onClose 回调销毁锁,只对“相同文本”进行去重，不同文本可以同时弹。 优点：精准。既解决了由于并发导致的同一个错误（如 网络断开）疯狂刷屏，又保证了如果同时发生不同的业务错误（如 A接口无权限、B接口数据不存在），它们都能正常显示。 缺点：需要侵入一点业务代码，维护一个全局的 Set。 Ant Design 官方提供的全局配置（maxCount） 实现原理：通过全局配置，限制整个系统在屏幕上最多同时存在多少个 message 实例。 优点：完全不需要写多余的拦截器逻辑，框架底层原生支持。 缺点：它是全局生效的，且不看内容。如果限制了 maxCount: 1，当系统在不同地方触发了不同的提示，前一个提示会被瞬间刷掉（顶替），用户可能还没看清前一个报错是什么。 请求层面的“取消重复请求”（CancelToken / AbortController） 实现原理：在 Axios 请求拦截器中，根据请求的 url、method、params 生成唯一 Key。如果发现有相同的 Key 且尚未结束，直接调用 abort() 取消掉后发的请求。 优点：不仅解决了提示刷屏，还顺便节省了服务器带宽，避免了重复提交带来的后端副作用。 缺点：不适用于数据不同的并发。它只能解决“完全相同”的连续请求，如果页面初始化时是同时发起了 获取用户信息、获取菜单列表、获取通知 这三个不同的请求，它们依然会同时失败，这个方案此时就无法阻止提示刷屏。