在阿里国际站做的网站上海最近的新闻大事10条
原因：
问题根源在于两个独立的系统（A系统与B系统）共享了同一cookie键名来存储各自用户的认证令牌（token）。这种设计导致了以下情形：
- 当用户在A系统登录后，一个token被存储在cookie中，使用了特定的键名。
- 同一用户在B系统中也进行了登录，然而B系统同样使用了相同的键名来存放其专属的token。
- 由于两个系统可能使用不同的后端服务和数据存储（如各自的Redis实例），当B系统尝试验证cookie中的token时，它实际上是在查询自己系统的认证数据库（如Redis），而不是A系统的。
当用户从B系统访问A系统时，由于B系统覆盖了cookie中的token，A系统尝试使用这个由B系统颁发的token进行认证，自然在A系统的后端（如Redis）中找不到对应的记录，导致认证失败，用户被迫重新登录A系统。
解决方案建议：
为了避免此类问题，每个系统应当使用独特的cookie键名来存储其认证信息。这可以确保系统间的token隔离，防止互相干扰。具体做法如下：
-
为每个系统分配唯一的cookie键名：例如，A系统可以使用
token_A，B系统使用token_B。这样，即使用户在同一浏览器中登录了多个系统，每个系统的token也不会相互覆盖。 -
前端代码调整：在前端的认证模块中，如
getToken方法，根据当前系统环境变量或配置文件中定义的键名来获取token，而不是硬编码一个通用的键名。 -
后端认证服务调整：后端也需要相应地调整，以支持各自系统的token认证流程，确保token的生成、存储和验证都在对应系统的上下文中进行。
总结：
将/src/utils/auth.js中TokenKey值修改成不同的值就好了