feat(admin): Add user management and upgrade to module permission system

Features - User Management (Phase 4.1):
- Database: Add user_modules table for fine-grained module permissions
- Database: Add 4 user permissions (view/create/edit/delete) to role_permissions
- Backend: UserService (780 lines) - CRUD with tenant isolation
- Backend: UserController + UserRoutes (648 lines) - 13 API endpoints
- Backend: Batch import users from Excel
- Frontend: UserListPage (412 lines) - list/filter/search/pagination
- Frontend: UserFormPage (341 lines) - create/edit with module config
- Frontend: UserDetailPage (393 lines) - details/tenant/module management
- Frontend: 3 modal components (592 lines) - import/assign/configure
- API: GET/POST/PUT/DELETE /api/admin/users/* endpoints

Architecture Upgrade - Module Permission System:
- Backend: Add getUserModules() method in auth.service
- Backend: Login API returns modules array in user object
- Frontend: AuthContext adds hasModule() method
- Frontend: Navigation filters modules based on user.modules
- Frontend: RouteGuard checks requiredModule instead of requiredVersion
- Frontend: Remove deprecated version-based permission system
- UX: Only show accessible modules in navigation (clean UI)
- UX: Smart redirect after login (avoid 403 for regular users)

Fixes:
- Fix UTF-8 encoding corruption in ~100 docs files
- Fix pageSize type conversion in userService (String to Number)
- Fix authUser undefined error in TopNavigation
- Fix login redirect logic with role-based access check
- Update Git commit guidelines v1.2 with UTF-8 safety rules

Database Changes:
- CREATE TABLE user_modules (user_id, tenant_id, module_code, is_enabled)
- ADD UNIQUE CONSTRAINT (user_id, tenant_id, module_code)
- INSERT 4 permissions + role assignments
- UPDATE PUBLIC tenant with 8 module subscriptions

Technical:
- Backend: 5 new files (~2400 lines)
- Frontend: 10 new files (~2500 lines)
- Docs: 1 development record + 2 status updates + 1 guideline update
- Total: ~4900 lines of code

Status: User management 100% complete, module permission system operational

docs/07-运维文档/06-长时间任务可靠性分析.md

@@ -1,9 +1,9 @@
 # 长时间任务可靠性分析：MemoryQueue vs Redis队列
 
-> **蝨ｺ譎ｯ<EFBFBD>?* 1000遽<30>枚迪ｮ遲幃€会ｼ碁｢<E7A281>ｮ｡2蟆乗慮螟<E685AE>炊譌ｶ髣ｴ  
-> **蠖灘燕譁ｹ譯茨ｼ?* MemoryQueue<EFBFBD>亥<EFBFBD>蟄倬弌蛻暦ｼ<EFBFBD>  
-> **髣ｮ鬚假ｼ?* 閭ｽ蜷ｦ蜿ｯ髱<EFBDAF>螳梧<E89EB3><E6A2A7>? 
-> **扈楢ｮｺ<EFBFBD>?* 笶?**荳崎<E88DB3>**
+> **场景：** 1000篇文献筛选，预计2小时处理时间  
+> **当前方案：** MemoryQueue（内存队列）  
+> **问题：** 能否可靠完成？  
+> **结论：** ❌ **不能**
 
 ---
 
@@ -11,103 +11,103 @@
 
 ### 任务特征
 ```
-莉ｻ蜉｡邀ｻ蝙具ｼ壽枚迪ｮ遲幃€会ｼ域<EFBFBD><EFBFBD>｢俶遭隕∝<EFBFBD>遲幢ｼ?
-譁<EFBFBD>鍵謨ｰ驥擾ｼ?000遽?
-蜊慕ｯ<EFBFBD>€玲慮<EFBFBD>?-10遘抵ｼ亥曙讓｡蝙句ｹｶ陦鯉ｼ<E9AF89>
-諤ｻ閠玲慮<EFBFBD>?000-10000遘?= 100-167蛻<EFBFBD>帖 竕?2蟆乗慮
+任务类型：文献筛选（标题摘要初筛）
+文献数量：1000篇
+单篇耗时：6-10秒（双模型并行）
+总耗时：6000-10000秒 = 100-167分钟 ≈ 2小时
 ```
 
 ### 当前实现
 ```typescript
-// backend/src/modules/asl/services/screeningService.ts (隨?5陦?
+// backend/src/modules/asl/services/screeningService.ts (第65行)
 
-// 4. 蠑よｭ･螟<EFBFBD>炊譁<EFBFBD>鍵<EFBFBD>育ｮ€蛹也沿<EFBFBD>夂峩謗･蝨ｨ霑咎㈹螟<EFBFBD>炊<EFBFBD>?
-// 逕滉ｺｧ邇ｯ蠅<EFBFBD>ｺ碑ｯ･蜿鷹€∝芦豸域<EFBFBD>髦溷<EFBFBD>  竊?豕ｨ諢剰ｿ呵｡梧ｳｨ驥奇ｼ?
+// 4. 异步处理文献（简化版：直接在这里处理）
+// 生产环境应该发送到消息队列  ← 注意这行注释！
 processLiteraturesInBackground(task.id, projectId, literatures);
 
 // 这个函数会：
-// 1. 霑占｡悟惠蠖灘燕Node霑帷ｨ倶ｸ?
-// 2. 荳ｲ陦悟､<EFBFBD>炊1000遽<EFBFBD>枚迪?
-// 3. 豐｡譛画戟荵<EFBFBD>喧<EFBFBD>亥<EFBFBD>蝨ｨ蜀<EFBFBD>ｭ假ｼ?
+// 1. 运行在当前Node进程中
+// 2. 串行处理1000篇文献
+// 3. 没有持久化（全在内存）
 ```
 
 ---
 
-## 笶?**MemoryQueue逧<EFBFBD><EFBFBD>蜻ｽ髣ｮ鬚?*
+## ❌ **MemoryQueue的致命问题**
 
-### 髣ｮ鬚<EFBFBD>1<EFBFBD>售AE螳樔ｾ倶ｼ夊｢ｫ閾ｪ蜉ｨ髞€豈?<3F>櫨 **譛€荳･驥<EFBDA5>**
+### 问题1：SAE实例会被自动销毁 🔥 **最严重**
 
-#### **Serverless逧<EFBFBD>悽雍ｨ<EFBFBD>壽潔髴€隶｡雍ｹ = 謖蛾怙髞€豈?*
+#### **Serverless的本质：按需计费 = 按需销毁**
 
 ```
 阿里云SAE的自动缩容策略：
-笏懌楳 譌<>豬<EFBFBD>㍼譌ｶ<E8AD8C>?5蛻<35>帖蜷守ｼｩ螳ｹ蛻ｰ0
+├─ 无流量时：15分钟后缩容到0
 ├─ 低流量时：缩减实例数
-笏懌楳 螟憺龍譌ｶ谿ｵ<E8B0BF>夊<EFBFBD>蜉ｨ郛ｩ螳ｹ<E89EB3>郁鰍逵∵<E980B5>譛ｬ<E8AD9B>?
-笏披楳 邉ｻ扈溷合郤ｧ<E983A4>壼ｮ樔ｾ矩㍾蜷?
+├─ 夜间时段：自动缩容（节省成本）
+└─ 系统升级：实例重启
 ```
 
-#### **2蟆乗慮莉ｻ蜉｡逧<EFBFBD>｣朱勦隸<EFBFBD>ｼ?*
+#### **2小时任务的风险评估**
 
-| 譌ｶ谿ｵ | SAE螳樔ｾ矩楳豈∵ｦら<EFBFBD>?| 隸ｴ譏<EFBDB4> |
+| 时段 | SAE实例销毁概率 | 说明 |
 |------|----------------|------|
-| **蟾･菴懈慮髣ｴ<EFBFBD>?:00-18:00<EFBFBD>?* | <EFBFBD>泯 30-50% | 豬<EFBFBD>㍼豕｢蜉ｨ蟇ｼ閾ｴ郛ｩ螳ｹ |
-| **螟憺龍譌ｶ谿ｵ<EFBFBD>?2:00-06:00<EFBFBD>?* | <EFBFBD>閥 80-95% | 閾ｪ蜉ｨ郛ｩ螳ｹ遲也払 |
-| **蜻ｨ譛ｫ/闃ょ∞譌?* | <EFBFBD>閥 70-90% | 菴取ｵ<EFBFBD>㍼譌ｶ谿?|
+| **工作时间（9:00-18:00）** | 🟡 30-50% | 流量波动导致缩容 |
+| **夜间时段（22:00-06:00）** | 🔴 80-95% | 自动缩容策略 |
+| **周末/节假日** | 🔴 70-90% | 低流量时段 |
 
-**逵溷ｮ槫惻譎ｯ讓｡諡<EFBFBD>**<EFBFBD>?
+**真实场景模拟**：
 ```
-21:00 逕ｨ謌ｷ謠蝉ｺ､1000遽<EFBFBD>枚迪ｮ遲幃€?
-21:00 SAE螳樔ｾ句ｼ€蟋句､<EFBFBD>炊<EFBFBD>磯｢<EFBFBD>ｮ｡2蟆乗慮螳梧<EFBFBD><EFBFBD>?
-21:15 蜑咲ｫｯ譛臥畑謌ｷ隶ｿ髣ｮ<EFBFBD>亥ｮ樔ｾ句ｭ俶ｴｻ<EFBFBD>?
+21:00 用户提交1000篇文献筛选
+21:00 SAE实例开始处理（预计2小时完成）
+21:15 前端有用户访问（实例存活）
 22:00 用户下班回家（无新访问）
-22:15 SAE譽€豬具ｼ<EFBFBD>15蛻<EFBFBD>帖譌<EFBFBD>豬<EFBFBD><EFBFBD>?竊?蜃<>､<EFBFBD>ｼｩ螳ｹ
-22:16 笶?螳樔ｾ玖｢ｫ髞€豈?
-      笏披楳 莉ｻ蜉｡霑帛ｺｦ<EFBDBA>?50/1000<EFBFBD>?5%<25>?
+22:15 SAE检测：15分钟无流量 → 准备缩容
+22:16 ❌ 实例被销毁
+      └─ 任务进度：150/1000（15%）
       └─ 结果：任务丢失，前功尽弃
 ```
 
 ---
 
-### 髣ｮ鬚<EFBFBD>2<EFBFBD>夊ｿ帷ｨ句ｴｩ貅<EFBFBD>裏豕墓△螟?
+### 问题2：进程崩溃无法恢复
 
 ```typescript
-// 蠖灘燕螳樒鴫<EFBFBD>育ｮ€蛹也沿<EFBFBD>?
+// 当前实现（简化版）
 async function processLiteraturesInBackground(taskId, projectId, literatures) {
   for (const lit of literatures) {
     try {
       // 处理单篇文献（耗时6-10秒）
       await processLiterature(lit);
     } catch (error) {
-      // 譟千ｯ<EFBFBD>､ｱ雍･<EFBFBD>檎ｻｧ扈ｭ荳倶ｸ€遽?
+      // 某篇失败，继续下一篇
       logger.error('Failed to process literature', { error });
     }
   }
 }
 
-// 鬟朱勦<EFBFBD>?
+// 风险：
 // 1. 如果Node进程崩溃（OOM、未捕获异常）→ 全部丢失
-// 2. 螯よ棡DB霑樊磁譁ｭ蠑€ 竊?譌<>豕穂ｿ晏ｭ倩ｿ帛ｺｦ
-// 3. 螯よ棡API髯先ｵ<EFBFBD> 竊?莉ｻ蜉｡蜊｡豁ｻ
-// 4. 豐｡譛画妙轤ｹ扈ｭ莨<EFBFBD> 竊?蠢<>｡ｻ驥榊､ｴ蠑€蟋?
+// 2. 如果DB连接断开 → 无法保存进度
+// 3. 如果API限流 → 任务卡死
+// 4. 没有断点续传 → 必须重头开始
 ```
 
 ---
 
-### 髣ｮ鬚<EFBFBD>3<EFBFBD>壽裏豕慕尅謗ｧ逵溷ｮ櫁ｿ帛ｺ?
+### 问题3：无法监控真实进度
 
 ```typescript
-// 蠖灘燕螳樒鴫逧<EFBFBD>ｿ帛ｺｦ譖ｴ譁?
+// 当前实现的进度更新
 await prisma.aslScreeningTask.update({
   where: { id: taskId },
   data: { processedItems: processedCount }
 });
 
-// 髣ｮ鬚假ｼ?
+// 问题：
 // - 进度只存在数据库
-// - 莉ｻ蜉｡迥ｶ諤∝惠蜀<EFBFBD>ｭ倅ｸ?
+// - 任务状态在内存中
 // - 实例销毁后，数据库显示 processedItems: 150
-// - 菴<EFBFBD>ｻｻ蜉｡螳樣刔蟾ｲ荳｢螟ｱ<EFBFBD>梧裏豕墓△螟?
+// - 但任务实际已丢失，无法恢复
 ```
 
 ---
@@ -115,24 +115,24 @@ await prisma.aslScreeningTask.update({
 ### 问题4：多实例冲突
 
 ```
-蝨ｺ譎ｯ<EFBFBD>售AE譛?荳ｪ螳樔ｾ?
+场景：SAE有2个实例
 
-逕ｨ謌ｷ謠蝉ｺ､莉ｻ蜉｡ 竊?螳樔ｾ帰蠑€蟋句､<E58FA5><EFBDA4>?
-                   竊?
-                螟<EFBFBD>炊蛻?00遽<30>慮<EFBFBD>悟ｮ樔ｾ帰髞€豈?
-                   竊?
-逕ｨ謌ｷ蛻ｷ譁ｰ鬘ｵ髱｢ 竊?隸ｷ豎りｷｯ逕ｱ蛻ｰ螳樔ｾ毅
-                   竊?
+用户提交任务 → 实例A开始处理
+                   ↓
+                处理到500篇时，实例A销毁
+                   ↓
+用户刷新页面 → 请求路由到实例B
+                   ↓
 实例B读取任务状态：processedItems: 500
-                   竊?
+                   ↓
 实例B不知道任务已中断
-                   竊?
-笶?莉ｻ蜉｡譏ｾ遉ｺ"霑幄｡御ｸ?<3F>御ｽ<E5BEA1>ｮ樣刔豐｡莠ｺ蝨ｨ螟<EFBDA8><E89E9F>?
+                   ↓
+❌ 任务显示"进行中"，但实际没人在处理
 ```
 
 ---
 
-## 笨?**Redis髦溷<EFBFBD>逧<EFBFBD>ｼ伜<EFBFBD>?*
+## ✅ **Redis队列的优势**
 
 ### 优势1：任务持久化
 
@@ -145,12 +145,12 @@ await jobQueue.push('asl:screening', {
 });
 
 // 任务保存在Redis中：
-// - 螳樔ｾ矩楳豈?竊?笨?莉ｻ蜉｡莉榊惠Redis
-// - 譁ｰ螳樔ｾ句星蜉?竊?笨?閾ｪ蜉ｨ諡ｾ蜿紋ｻｻ蜉｡
-// - 霑帷ｨ句ｴｩ貅<EFBFBD> 竊?笨?蜈ｶ莉妨orker謗･邂｡
+// - 实例销毁 → ✅ 任务仍在Redis
+// - 新实例启动 → ✅ 自动拾取任务
+// - 进程崩溃 → ✅ 其他Worker接管
 ```
 
-### 莨伜漢2<EFBFBD>壽妙轤ｹ扈ｭ莨?
+### 优势2：断点续传
 
 ```typescript
 // Worker处理任务
@@ -161,234 +161,234 @@ jobQueue.process('asl:screening', async (job) => {
     // 处理文献
     await processLiterature(literatureIds[i]);
     
-    // 譖ｴ譁ｰ霑帛ｺｦ<EFBFBD>井ｿ晏ｭ伜芦Redis<EFBFBD>?
+    // 更新进度（保存到Redis）
     await job.updateProgress((i + 1) / literatureIds.length * 100);
     
     // 如果Worker在这里崩溃：
-    // - BullMQ莨壼ｰ<EFBFBD>ｻｻ蜉｡譬<EFBFBD>ｮｰ荳?蛛懈ｻ<E68788>"
-    // - 蜈ｶ莉妨orker莨夐㍾譁ｰ諡ｾ蜿?
+    // - BullMQ会将任务标记为"停滞"
+    // - 其他Worker会重新拾取
     // - 从上次进度继续（而不是重头开始）
   }
 });
 ```
 
-### 莨伜漢3<EFBFBD>夊<EFBFBD>蜉ｨ驥崎ｯ?
+### 优势3：自动重试
 
 ```typescript
 // BullMQ配置
 const queue = new Queue('asl:screening', {
   connection: { host: 'redis' },
   defaultJobOptions: {
-    attempts: 3,              // 螟ｱ雍･蜷朱㍾隸?谺?
+    attempts: 3,              // 失败后重试3次
     backoff: {
       type: 'exponential',
-      delay: 2000             // 2遘偵€?遘偵€?遘?
+      delay: 2000             // 2秒、4秒、8秒
     },
-    removeOnComplete: true,   // 螳梧<EFBFBD>蜷取ｸ<EFBFBD><EFBFBD>?
-    removeOnFail: false       // 螟ｱ雍･蜷惹ｿ晉蕗<EFBFBD>井ｾｿ莠取賜譟･<EFBFBD>?
+    removeOnComplete: true,   // 完成后清理
+    removeOnFail: false       // 失败后保留（便于排查）
   }
 });
 
-// 蝨ｺ譎ｯ<EFBFBD>?
-// - LLM API荳ｴ譌ｶ謨<EFBFBD>囿 竊?笨?閾ｪ蜉ｨ驥崎ｯ<E5B48E>
-// - 鄂醍ｻ懈竃蜉ｨ 竊?笨?閾ｪ蜉ｨ驥崎ｯ<E5B48E>
-// - DB霑樊磁譁ｭ蠑€ 竊?笨?閾ｪ蜉ｨ驥崎ｯ<E5B48E>
+// 场景：
+// - LLM API临时故障 → ✅ 自动重试
+// - 网络抖动 → ✅ 自动重试
+// - DB连接断开 → ✅ 自动重试
 ```
 
 ### 优势4：分布式任务分配
 
 ```
-SAE譛?荳ｪ螳樔ｾ具ｼ<E585B7>
+SAE有3个实例：
 
-Redis髦溷<EFBFBD><EFBFBD>?000荳ｪ莉ｻ蜉｡<E89C89><EFBDA1>
-    竊?
-閾ｪ蜉ｨ蛻<EFBFBD><EFBFBD><EFBFBD>?
-笏懌楳 螳樔ｾ帰 Worker<EFBFBD>壼､<EFBFBD><EFBFBD>?Task 1-350
-笏懌楳 螳樔ｾ毅 Worker<EFBFBD>壼､<EFBFBD><EFBFBD>?Task 351-700
-笏披楳 螳樔ｾ気 Worker<EFBFBD>壼､<EFBFBD><EFBFBD>?Task 701-1000
+Redis队列（1000个任务）
+    ↓
+自动分配：
+├─ 实例A Worker：处理 Task 1-350
+├─ 实例B Worker：处理 Task 351-700
+└─ 实例C Worker：处理 Task 701-1000
 
 如果实例B销毁：
-笏懌楳 Task 351-700 譬<EFBFBD>ｮｰ荳?蛛懈ｻ<E68788>"
+├─ Task 351-700 标记为"停滞"
 ├─ 实例A或C的Worker自动接管
 └─ 继续处理，无需人工干预
 ```
 
 ---
 
-## <EFBFBD>投 **蜿ｯ髱<EFBFBD>諤ｧ蟇ｹ豈?*
+## 📊 **可靠性对比**
 
 | 维度 | MemoryQueue | Redis队列 | 差异 |
 |------|------------|----------|------|
-| **2蟆乗慮莉ｻ蜉｡螳梧<EFBFBD>邇?* | 10-30% | 99%+ | **300%謠仙合** |
-| **螳樔ｾ矩楳豈∝錘** | 笶?莉ｻ蜉｡荳｢螟ｱ | 笨?閾ｪ蜉ｨ諱｢螟<EFBDA2> | **蜈ｳ髞ｮ** |
-| **霑帷ｨ句ｴｩ貅<EFBFBD><EFBFBD>?* | 笶?蜈ｨ驛ｨ荳｢螟ｱ | 笨?譁ｭ轤ｹ扈ｭ莨<EFBDAD> | **蜈ｳ髞ｮ** |
-| **API荳ｴ譌ｶ謨<EFBFBD>囿** | 笶?莉ｻ蜉｡螟ｱ雍･ | 笨?閾ｪ蜉ｨ驥崎ｯ<E5B48E> | **蜈ｳ髞ｮ** |
-| **螟壼ｮ樔ｾ句刻隹?* | 笶?譌<>豕募刻隹<E588BB> | 笨?閾ｪ蜉ｨ蛻<EFBDA8><E89BBB> | **蜈ｳ髞ｮ** |
-| **莉ｻ蜉｡逶第而** | 笞<EFBFBD><EFBFBD><EFBFBD> 莉<>B | 笨?螳樊慮迥ｶ諤?| 蜿ｯ騾?|
-| **謌先悽** | ﾂ･0 | ﾂ･108/蟷?| 蜿ｯ謗･蜿?|
+| **2小时任务完成率** | 10-30% | 99%+ | **300%提升** |
+| **实例销毁后** | ❌ 任务丢失 | ✅ 自动恢复 | **关键** |
+| **进程崩溃后** | ❌ 全部丢失 | ✅ 断点续传 | **关键** |
+| **API临时故障** | ❌ 任务失败 | ✅ 自动重试 | **关键** |
+| **多实例协调** | ❌ 无法协调 | ✅ 自动分配 | **关键** |
+| **任务监控** | ⚠️ 仅DB | ✅ 实时状态 | 可选 |
+| **成本** | ¥0 | ¥108/年 | 可接受 |
 
 ---
 
 ## 🎯 **真实场景模拟**
 
-### 蝨ｺ譎ｯ1<EFBFBD>壼ｷ･菴懈慮髣ｴ謠蝉ｺ､<EFBFBD>域<EFBFBD>蜉溽<EFBFBD>?0%<25>?
+### 场景1：工作时间提交（成功率30%）
 
 ```
-10:00 逕ｨ謌ｷ謠蝉ｺ､1000遽<EFBFBD>枚迪ｮ遲幃€?
+10:00 用户提交1000篇文献筛选
       ├─ MemoryQueue：开始处理，预计12:00完成
-      笏?
-11:30 豬<EFBFBD>㍼髯堺ｽ趣ｼ郡AE郛ｩ螳ｹ<EFBFBD>亥唖髯?荳ｪ螳樔ｾ具ｼ<E585B7>
-      笏懌楳 螯よ棡莉ｻ蜉｡蝨ｨ陲ｫ蛻<EFBDAB>髯､逧<EFBDA4>ｮ樔ｾ倶ｸ<E580B6> 竊?笶?荳｢螟ｱ<E89E9F>域ｦら<EFBDA6>?0%<25>?
-      笏?
-12:00 螯よ棡蟷ｸ霑先悴陲ｫ蛻<EFBFBD>髯､ 竊?笨?螳梧<E89EB3><E6A2A7>域ｦら<EFBDA6>?0%<25>?
+      │
+11:30 流量降低，SAE缩容（删除1个实例）
+      ├─ 如果任务在被删除的实例上 → ❌ 丢失（概率50%）
+      │
+12:00 如果幸运未被删除 → ✅ 完成（概率50%）
 
-諤ｻ謌仙粥邇<EFBFBD>ｼ?0%
+总成功率：50%
 ```
 
-### 蝨ｺ譎ｯ2<EFBFBD>壼､憺龍謠蝉ｺ､<EFBFBD>域<EFBFBD>蜉溽<EFBFBD>?%<25>?
+### 场景2：夜间提交（成功率5%）
 
 ```
-21:00 逕ｨ謌ｷ謠蝉ｺ､1000遽<EFBFBD>枚迪ｮ遲幃€?
+21:00 用户提交1000篇文献筛选
       ├─ MemoryQueue：开始处理，预计23:00完成
-      笏?
-21:15 譌<EFBFBD>譁ｰ逕ｨ謌ｷ隶ｿ髣ｮ<EFBFBD>梧ｵ<EFBFBD>㍼髯堺ｸ?
-      笏?
-21:30 SAE譽€豬具ｼ<EFBFBD>15蛻<EFBFBD>帖譌<EFBFBD>豬<EFBFBD><EFBFBD>?竊?蜃<>､<EFBFBD>ｼｩ螳ｹ
-      笏?
-21:31 笶?螳樔ｾ矩楳豈<E6A5B3>ｼ御ｻｻ蜉｡荳｢螟ｱ<E89E9F>域ｦら<EFBDA6>?5%<25>?
+      │
+21:15 无新用户访问，流量降为0
+      │
+21:30 SAE检测：15分钟无流量 → 准备缩容
+      │
+21:31 ❌ 实例销毁，任务丢失（概率95%）
 
-諤ｻ謌仙粥邇<EFBFBD>ｼ?%
+总成功率：5%
 ```
 
-### 蝨ｺ譎ｯ3<EFBFBD>啌edis髦溷<EFBFBD><EFBFBD>域<EFBFBD>蜉溽紫99%+<EFBFBD>?
+### 场景3：Redis队列（成功率99%+）
 
 ```
-21:00 逕ｨ謌ｷ謠蝉ｺ､1000遽<EFBFBD>枚迪ｮ遲幃€?
-      笏懌楳 Redis髦溷<EFBFBD><EFBFBD>壻ｻｻ蜉｡蜈･髦?
-      笏懌楳 Worker<EFBFBD>壼ｼ€蟋句､<EFBFBD><EFBFBD>?
-      笏?
-21:31 螳樔ｾ矩楳豈?
+21:00 用户提交1000篇文献筛选
+      ├─ Redis队列：任务入队
+      ├─ Worker：开始处理
+      │
+21:31 实例销毁
       ├─ 任务保存在Redis
-      笏?
+      │
 21:32 新实例启动（或其他实例）
-      笏懌楳 Worker<EFBFBD>夊<EFBFBD>蜉ｨ諡ｾ蜿紋ｻｻ蜉?
-      笏懌楳 莉山edis隸ｻ蜿冶ｿ帛ｺｦ<EFBDBA>壼ｷｲ螟<EFBDB2>炊150遽?
-      笏懌楳 扈ｧ扈ｭ螟<EFBDAD>炊蜑ｩ菴<EFBDA9>850遽?
-      笏?
-23:00 笨?莉ｻ蜉｡螳梧<E89EB3>
+      ├─ Worker：自动拾取任务
+      ├─ 从Redis读取进度：已处理150篇
+      ├─ 继续处理剩余850篇
+      │
+23:00 ✅ 任务完成
 
-諤ｻ謌仙粥邇<EFBFBD>ｼ?9%+
+总成功率：99%+
 ```
 
 ---
 
 ## 💰 **成本分析**
 
-### MemoryQueue逧<EFBFBD>嚼阯乗<EFBFBD>譛?
+### MemoryQueue的隐藏成本
 
 ```
 任务失败率：70%（夜间）
-逕ｨ謌ｷ驥肴眠謠蝉ｺ､谺｡謨ｰ<EFBFBD>壼ｹｳ蝮?谺｡謇肴<E8AC87>蜉<EFBFBD>
-LLM API豬ｪ雍ｹ<EFBFBD>?
-- 隨?谺｡<E8B0BA>壼､<E5A3BC>炊200遽<30>錘螟ｱ雍･ 竊?豬ｪ雍ｹ ﾂ･86
-- 隨?谺｡<E8B0BA>壼､<E5A3BC>炊500遽<30>錘螟ｱ雍･ 竊?豬ｪ雍ｹ ﾂ･215
-- 隨?谺｡<E8B0BA>壼ｮ梧<EFBDAE> 竊?ﾂ･430
-諤ｻ謌先悽<EFBFBD>堋･731<EFBFBD>亥ｺ碑ｯ･蜿ｪ髴€ﾂ･430<EFBFBD>?
+用户重新提交次数：平均3次才成功
+LLM API浪费：
+- 第1次：处理200篇后失败 → 浪费 ¥86
+- 第2次：处理500篇后失败 → 浪费 ¥215
+- 第3次：完成 → ¥430
+总成本：¥731（应该只需¥430）
 
-逕ｨ謌ｷ菴馴ｪ鯉ｼ?
-- 蜿榊､榊､ｱ雍･ 竊?謚戊ｯ臥紫荳雁<E88DB3>?
-- 荳肴覆螟憺龍謠蝉ｺ､ 竊?菴ｿ逕ｨ蜿鈴剞
-- 蟇ｹ邉ｻ扈溷､ｱ蜴ｻ菫｡莉?竊?豬∝､ｱ鬟朱勦
+用户体验：
+- 反复失败 → 投诉率上升
+- 不敢夜间提交 → 使用受限
+- 对系统失去信任 → 流失风险
 ```
 
-### Redis髦溷<EFBFBD>逧<EFBFBD>悄螳樊<EFBFBD>譛?
+### Redis队列的真实成本
 
 ```
-Redis蟷ｴ雍ｹ<EFBFBD>堋?08
+Redis年费：¥108
 任务成功率：99%+
 用户重新提交次数：几乎为0
-LLM API謌先悽<EFBFBD>堋?30<33>域裏豬ｪ雍ｹ<E99B8D>?
+LLM API成本：¥430（无浪费）
 
-鬚晏､匁噺逶奇ｼ?
-- 逕ｨ謌ｷ貊｡諢丞ｺｦ謠仙<EFBFBD>?
-- 蜿ｯ莉･謾ｯ謖∵峩螟ｧ謇ｹ驥擾ｼ?000遽?<3F>?
+额外收益：
+- 用户满意度提升
+- 可以支持更大批量（5000篇+）
 - 夜间任务可靠运行
 ```
 
-**ROI隶｡邂<EFBFBD>**<EFBFBD>?
+**ROI计算**：
 ```
-闃ら怐謌先悽<EFBFBD>堋?31 - ﾂ･430 = ﾂ･301/谺?
+节省成本：¥731 - ¥430 = ¥301/次
 如果每月10次批量任务：
-闃ら怐 = ﾂ･301 ﾃ<EFBFBD> 10 = ﾂ･3,010/譛?
-Redis謌先悽 = ﾂ･9/譛?
-蜃€謾ｶ逶<EFBFBD> = ﾂ･3,001/譛?
+节省 = ¥301 × 10 = ¥3,010/月
+Redis成本 = ¥9/月
+净收益 = ¥3,001/月
 
-ROI = 33,344%<EFBFBD>域兜蜈･ﾂ?<3F>悟屓謚･ﾂ?,010<EFBFBD>?
+ROI = 33,344%（投入¥9，回报¥3,010）
 ```
 
 ---
 
-## 笞<EFBFBD><EFBFBD><EFBFBD> **扈楢ｮｺ荳主ｻｺ隶?*
+## ⚠️ **结论与建议**
 
 ### 明确结论
 
 ```
-髣ｮ鬚假ｼ哺emoryQueue閭ｽ蜷ｦ螳梧<EFBFBD>2蟆乗慮莉ｻ蜉｡<EFBFBD>?
+问题：MemoryQueue能否完成2小时任务？
 答案：❌ 不能可靠完成
 
-蜴溷屏<EFBFBD>?
+原因：
 1. SAE实例会自动销毁（15分钟无流量）
-2. 2蟆乗慮莉ｻ蜉｡蜃<EFBFBD>荵主ｿ<EFBFBD>┯驕<EFBFBD>芦螳樔ｾ矩楳豈?
-3. 莉ｻ蜉｡荳｢螟ｱ蜷取裏豕墓△螟?
-4. 謌仙粥邇?< 30%<25>悟､憺<EFBDA4>?< 5%
+2. 2小时任务几乎必然遇到实例销毁
+3. 任务丢失后无法恢复
+4. 成功率 < 30%，夜间 < 5%
 ```
 
 ### 强烈建议
 
 ```
-蟇ｹ莠手ｶ<EFBFBD>ｿ<EFBFBD>10蛻<EFBFBD>帖逧<EFBFBD>ｻｻ蜉｡<EFBFBD>悟ｿ<EFBFBD>｡ｻ菴ｿ逕ｨRedis髦溷<EFBFBD><EFBFBD>?
+对于超过10分钟的任务，必须使用Redis队列！
 
 时间阈值：
 - < 10秒：可以用MemoryQueue（同步处理）
-- 10遘?- 10蛻<EFBFBD>帖<EFBFBD>壼ｻｺ隶ｮ逕ｨRedis髦溷<EFBFBD>
+- 10秒 - 10分钟：建议用Redis队列
 - > 10分钟：必须用Redis队列
 - > 1小时：强制要求Redis队列
 ```
 
-### 螳樊命莨伜<EFBFBD>郤?
+### 实施优先级
 
 ```
 阶段1（本周）：Redis缓存
 ├─ 解决LLM成本问题
-笏披楳 蟾･菴憺㍼<E686BA><E38DBC>2螟?
+└─ 工作量：2天
 
-髦ｶ谿ｵ2<EFBFBD>井ｸ句捉<EFBFBD>会ｼ啌edis髦溷<EFBFBD>  竊?**蠢<>｡ｻ蛛夲ｼ<E5A4B2>**
-笏懌楳 隗｣蜀ｳ髟ｿ莉ｻ蜉｡蜿ｯ髱<EFBDAF>諤?
-笏懌楳 蟾･菴憺㍼<E686BA><E38DBC>3螟?
-笏披楳 荳榊★逧<E29885>｣朱勦<E69CB1><E58BA6>70%莉ｻ蜉｡螟ｱ雍･邇?
+阶段2（下周）：Redis队列  ← **必须做！**
+├─ 解决长任务可靠性
+├─ 工作量：3天
+└─ 不做的风险：70%任务失败率
 ```
 
 ---
 
-## <EFBFBD>統 **謚€譛ｯ扈<EFBFBD>鰍<EFBFBD>壻ｸｺ莉€荵?0蛻<30>帖譏ｯ蛻<EFBDAF>ｰｴ蟯ｭ<E89FAF>?*
+## 📝 **技术细节：为什么10分钟是分水岭？**
 
 ### SAE实例缩容策略
 
 ```
-髦ｿ驥御ｺ全AE鮟倩ｮ､遲也払<EFBFBD>?
+阿里云SAE默认策略：
 - 检测周期：5分钟
 - 无流量阈值：15分钟
-- 郛ｩ螳ｹ蟒ｶ霑滂ｼ?蛻<>帖
+- 缩容延迟：5分钟
 
-諤ｻ隶｡<EFBFBD>?5蛻<35>帖蜷主庄閭ｽ郛ｩ螳?
+总计：15分钟后可能缩容
 ```
 
-### 莉ｻ蜉｡譌ｶ髟ｿ荳朱｣朱<EFBFBD>?
+### 任务时长与风险
 
 ```
-莉ｻ蜉｡譌ｶ髟ｿ     螳樔ｾ矩楳豈<E6A5B3>｣朱<EFBDA3>?    蟒ｺ隶ｮ
+任务时长     实例销毁风险     建议
 ─────────────────────────────────────
-< 1蛻<EFBFBD>帖      蜃<EFBFBD>荵惹ｸ?%        蜷梧ｭ･螟<EFBFBD>炊
+< 1分钟      几乎为0%        同步处理
 1-5分钟      < 5%           可用MemoryQueue
 5-10分钟     10-20%         建议Redis队列
 10-30分钟    50-70%         必须Redis队列
@@ -399,73 +399,72 @@ ROI = 33,344%（投入
 
 ## 🎯 **立即行动**
 
-### 螯よ棡謔ｨ諠ｳ邇ｰ蝨ｨ蟆ｱ豬玖ｯ暮柄莉ｻ蜉｡<EFBFBD>?
+### 如果您想现在就测试长任务：
 
-**荳肴耳闕?*<2A>夂畑MemoryQueue豬玖ｯ<EFBFBD>1000遽?
-- 鬟朱勦<EFBFBD>?0%讎ら紫螟ｱ雍･
+**不推荐**：用MemoryQueue测试1000篇
+- 风险：70%概率失败
 - 浪费：重复调用LLM API
 
-**謗ｨ闕<EFBFBD>**<EFBFBD>壼<EFBFBD>逕?00遽<30>ｵ玖ｯ包ｼ<E58C85>10蛻<30>帖<EFBFBD>?
+**推荐**：先用100篇测试（10分钟）
 ```typescript
 // 限制测试数量
 const testLiteratures = literatures.slice(0, 100);
 processLiteraturesInBackground(task.id, projectId, testLiteratures);
 ```
 
-辟ｶ蜷手ｧょｯ滂ｼ?
+然后观察：
 - 是否遇到实例销毁？
-- 莉ｻ蜉｡譏ｯ蜷ｦ螳梧紛<EFBFBD>?
+- 任务是否完整？
 - 如果失败，立即改用Redis队列
 
 ### 如果您准备改造：
 
-**蜿り€<EFBFBD>枚譯?*<2A>?
-- `04-Redis謾ｹ騾<EFBFBD>螳樊命隶｡蛻?md`
+**参考文档**：
+- `04-Redis改造实施计划.md`
 - `05-Redis缓存与队列的区别说明.md`
 
-**謾ｹ騾<EFBFBD>鬘ｺ蠎?*<2A>?
-1. 笨?Redis郛灘ｭ假ｼ域悽蜻ｨ<EFBFBD><EFBFBD>
-2. 笨?Redis髦溷<EFBFBD><EFBFBD>井ｸ句捉<EFBFBD>俄<EFBFBD>?**驥咲せ**
-3. 笨?豬玖ｯ<E78E96>2蟆乗慮莉ｻ蜉｡
+**改造顺序**：
+1. ✅ Redis缓存（本周）
+2. ✅ Redis队列（下周）← **重点**
+3. ✅ 测试2小时任务
 
 ---
 
-## <EFBFBD>投 **髯<EFBFBD>ｽ包ｼ壼ｮ樣刔豬玖ｯ募ｻｺ隶?*
+## 📊 **附录：实际测试建议**
 
-### 豬玖ｯ墓婿譯<EFBFBD><EFBFBD>夐ｪ瑚ｯ｀emoryQueue逧<EFBFBD>ｸ榊庄髱<EFBFBD>諤?
+### 测试方案A：验证MemoryQueue的不可靠性
 
 ```bash
-# 豁･鬪､1<EFBFBD>壽署莠?000遽<30>枚迪ｮ遲幃€我ｻｻ蜉?
-# 豁･鬪､2<EFBFBD>夂ｭ牙ｾ?5蛻<35>帖
-# 豁･鬪､3<EFBFBD>壽｣€譟･莉ｻ蜉｡迥ｶ諤?
-#        - 螯よ棡螟ｱ雍･ 竊?隸∵<E99AB8>螳樔ｾ玖｢ｫ髞€豈?
-#        - 螯よ棡謌仙粥 竊?霑先ｰ泌･ｽ<EFBDA5>御ｸ堺ｻ｣陦ｨ蜿ｯ髱?
+# 步骤1：提交1000篇文献筛选任务
+# 步骤2：等待15分钟
+# 步骤3：检查任务状态
+#        - 如果失败 → 证明实例被销毁
+#        - 如果成功 → 运气好，不代表可靠
 
 # 重复测试5次：
-# - 謌仙粥邇<EFBFBD>ｺ碑ｯ?< 30%
+# - 成功率应该 < 30%
 ```
 
 ### 测试方案B：Redis队列验证
 
 ```bash
 # 步骤1：部署Redis队列版本
-# 豁･鬪､2<EFBFBD>壽署莠?000遽<30>枚迪ｮ遲幃€我ｻｻ蜉?
+# 步骤2：提交1000篇文献筛选任务
 # 步骤3：主动停止SAE实例
-# 豁･鬪､4<EFBFBD>夐㍾譁ｰ蜷ｯ蜉ｨ螳樔ｾ?
-# 豁･鬪､5<EFBFBD>壽｣€譟･莉ｻ蜉｡譏ｯ蜷ｦ閾ｪ蜉ｨ諱｢螟?
+# 步骤4：重新启动实例
+# 步骤5：检查任务是否自动恢复
 
-# 鬚<EFBFBD>悄扈捺棡<EFBFBD>?
-# - 莉ｻ蜉｡閾ｪ蜉ｨ諱｢螟<EFBFBD> 笨?
-# - 莉取妙轤ｹ扈ｧ扈?笨?
-# - 譛€扈亥ｮ梧<EFBFBD>?笨?
+# 预期结果：
+# - 任务自动恢复 ✅
+# - 从断点继续 ✅
+# - 最终完成 ✅
 ```
 
 ---
 
-**譁<EFBFBD>｡｣扈ｴ謚､閠<EFBFBD>ｼ<EFBFBD>** 謚€譛ｯ蝗｢髦? 
+**文档维护者：** 技术团队  
 **最后更新：** 2025-12-12  
-**蜈ｳ髞ｮ扈楢ｮｺ<EFBFBD>?* MemoryQueue譌<EFBFBD>豕募庄髱<EFBFBD>螳梧<EFBFBD>2蟆乗慮莉ｻ蜉｡<EFBFBD>悟ｿ<EFBFBD>｡ｻ霑∫ｧｻ蛻ｰRedis髦溷<EFBFBD>
-
+**关键结论：** MemoryQueue无法可靠完成2小时任务，必须迁移到Redis队列