Fix: Token fallback and update issues when not logged in

[wsxiaolin]

No description provided.

[github-actions]

🤖 Codex-Style Code Review by OpenCode

💡 This is an automated advisory review. It is non-blocking and does not affect merge requirements.

Let me read the relevant files for deeper context.

PR 代码审查报告

概览

本次 PR 涉及 4 个文件，核心目标是改进 403 错误处理和登录会话管理，同时调整 cookie 提示和退出登录逻辑。

---

🔴 getData.ts — 源代码中硬编码凭据

apiToken 和 apiAuthCode 的回退值（'7pEWTsF4gR9qauzJCDQkxPLOZlnbMtAG', 'IKuoMliVTbXte15U7H8ROjaA2CQk96fh'）直接硬编码在源代码中。这些看起来像是匿名匿名的共享回退凭据。无论是公共仓库还是内部仓库，这些都应当通过环境变量或配置文件注入，而不是硬编码。

// 应改为：
const apiToken = !isAuthcatePath && !token ? import.meta.env.VITE_API_FALLBACK_TOKEN : token
const apiAuthCode = !isAuthcatePath && !authCode ? import.meta.env.VITE_API_FALLBACK_AUTH_CODE : authCode

同样，'x-API-Version': '2502' 也应提取为常量。

---

🔴 getData.ts — token 保存条件变更引入逻辑回归

旧逻辑（第 218-227 行）：

if (sm.getObj('userAuthInfo').value?.token == null) {
  sm.setObj('userAuthInfo', { ... })
}

只在 当前没有已存储 token 时写入。如果用户已是登录状态，调用 login()（如用于重新认证或页面初始化）不会覆盖已有会话。

新逻辑：

if (isRealLogin && data.Token) {
  sm.setObj('userAuthInfo', { ... })
}

总是覆盖已有 token，无论之前是否已有有效会话。并且 sm.setObj 现在放在 if (data.Status === 200) 块外面，意味着即使 data.Status !== 200，只要 isRealLogin && data.Token 为 true，也会执行写入，这可能是一个更严重的回归。

建议保持原有的保护性检查，或至少确保 data.Status === 200 的条件：

if (data.Status === 200 && isRealLogin && data.Token) {
  sm.setObj('userAuthInfo', { ... })
}

---

🟡 getData.ts — handle403 在 body 403 路径中可能重复执行

当 HTTP 状态是 403 时，!response.ok 分支会调用 handle403(npath, 'http')。但如果服务器返回 HTTP 200 但 body 中 Status === 403，handle403 会再次被调用。在某些情况下，服务器可能同时返回 HTTP 403 和 body Status 403，导致 handle403 被调用两次并重复写入 breadcrumb。建议在 handle403 内部添加防重入保护，或者调整控制流为 else if。

---

🟡 Home.vue — token 清理条件可能过于激进

if (res.Status !== 200 || !res.Data?.User) {
  sm.remove('userAuthInfo')
  return
}

当 res.Status !== 200 但 res.Data?.User 仍然存在时，也会清除鉴权信息——旧代码仅在 !res.Data?.User 时 return，不会清除。这是行为变更，可能需要与产品确认是否预期如此。建议考虑区分网络错误（暂时性）和明确的认证拒绝（应清除）。

---

🟡 Header.vue — localStorage.clear() 是核弹式的操作

使用 localStorage.clear() 然后手动恢复 cookieConsent 是一种脆弱模式。如果将来有其他需要保留的 key，这段代码需要同步修改。更健壮的方式是只删除已知的认证相关的 key：

const keysToRemove = ['userAuthInfo', 'userConfig', /* ... other known keys */]
keysToRemove.forEach(key => localStorage.removeItem(key))

硬编码的时间戳 1785328995457（约 2026 年 3 月）也是一个魔法数字。

---

🟢 i18n/zh.ts — Cookie 提示文本过于简略

- '我们可能会使用 Cookie 或浏览器本地能力来支持登录、安全、语言偏好和性能优化。本提示只用于告知，不会额外保存你的选择。'
+ '我们使用 Cookie ！'

新文本去掉了所有关于用途和选择保存的说明。如果这是配合 cookie 机制重构（如 Header.vue 中改为本地保存选择），建议更新文案以匹配新的行为。当前文本看起来像是临时占位符。

---

🟢 getData.ts — 格式化变更

• from './cache.ts' 的 import 从多行压缩为单行（L8），与文件中其他 import 风格不一致（如 L1-L9 都是单行导入单模块）。建议保持一致性。
• getData 函数的签名重新换行，属于纯风格变更。

---

总结

严重性	数量	关键项
🔴 Blocking	2	硬编码凭据、token 保存条件回归
🟡 Important	3	handle403 潜在重复调用、Home.vue 清除条件、Header.vue localStorage.clear 方式
🟢 Nit	2	文案可读性、代码风格一致性