优化代码

.trae/documents/fix-login-infinite-loop.md

@@ -0,0 +1,51 @@
+# 修复登录无限循环（登录成功后弹回登录页）
+
+## Context（问题与证据链）
+
+用户反馈：登录成功后又回到登录界面，无限循环。排查已确认（含用户亲证）：
+
+**用户确认的现象**
+- 登录页地址栏为 `api.yunzer.cn`（远程线上认证中心，非本地 9000）
+- 登录后见过「选择要进入的企业」界面（hero920103 绑定 2 家企业），**选完企业后又弹回登录页**
+
+**数据库证据（go-platform 库）**
+- hero920103 = identity_id 2（李志强），绑定两家企业（tid=1、tid=2）→ 登录必走"待选企业"分支
+- `yz_auth_session`：18:09~18:12 连续 4 条会话被踢（revoked=1, revoke_reason='kicked'）；最新会话 id=386（18:18:29，tid=2，client_id 为空）
+- 18:24:42 登录日志（id=218，user_id=1）与 hero920103 实际 identity_id=2 不符 → **该日志由远程旧版代码写入**（字段语义不同），且 IP=127.0.0.1/::1 符合"远程 nginx 反代回环"特征
+
+**代码机制（go/services/auth/session.go L61-134）**
+- `CreateSession` 按 identity_id **全局**统计活跃会话，超 MaxSession 即踢最旧会话（kicked），不区分 tid/client/服务实例
+- 登录 → 远程建会话 → 企业选择 → 新会话又创建 → 互踢 → authorize 发现会话已吊销 → 送回登录页 → 再登录 → **无限循环**
+- 远程为旧版代码（字段错位可证），其企业选择后的会话处理存在缺陷，无法本地修复
+
+## 修复方案
+
+### 第一步：本地开发认证切换到本地 9000 实例（核心修复）
+
+修改 `backend/.env.development`：
+
+```
+VITE_AUTH_BASE='http://127.0.0.1:9000/auth'
+```
+
+本地 9000 已注册全套认证端点（/auth/login、/auth/authorize、/auth/token、/auth/userinfo、/auth/switch-tenant，见 `go/routers/auth/auth.go`），且为最新代码（企业选择、cookie、PKCE 逻辑完整）。
+
+### 第二步：配套校验与清理
+
+1. 核对 `yz_auth_client` 表 yz-backend 的 redirect_uris 白名单包含 `http://127.0.0.1:4401/auth-callback.html`（不匹配则用 MySQL MCP 补登）
+2. 清理脏数据：将 hero920103（identity_id=2）名下 revoked=0 的旧会话标记 revoked=1（reason='cleanup'），避免旧会话占用互踢名额
+3. 重启 Vite dev server 使 env 生效
+4. 验证本地登录页 HTML 表单嵌入 client_id（curl 抓取确认，防止空 client 会话再现）
+
+### 第三步：端到端验证
+
+1. 无痕窗口（避免残留 localStorage token/userInfo）访问 `http://127.0.0.1:4401`
+2. 完整走：跳本地登录页 → 输入 hero920103 → 企业选择（展示 2 家）→ 选 tid=2 → 回跳 auth-callback → 进入工作台，无循环
+3. MySQL MCP 复查 `yz_auth_session` 无异常互踢
+4. 登录恢复后，验证原任务功能：apps/oa/schedule 日历按 hero920103 排班显示上班（绿）/休息（橙）背景（后端 `/backend/oa/scheduling/my` 已就绪）
+
+## 涉及文件
+
+- `backend/.env.development`（唯一代码修改：VITE_AUTH_BASE 指向本地）
+- 数据库：`yz_auth_client`（白名单核对）、`yz_auth_session`（脏数据清理）
+- 不改 Go 代码（互踢规则是合理安全设计；根因是开发环境认证指向了旧版远程中心）