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/05-部署文档/CTO 代码审查报告：AI临床研究平台部署架构.md

@@ -1,55 +1,63 @@
 # **CTO 代码审查报告：AI临床研究平台部署架构**
 
-螳｡譬ｸ蟇ｹ雎｡<EFBFBD>?莉ｽ迢ｬ遶矩Κ鄂ｲ譁<EFBDB2>｡?(Dify/Python/Node/Frontend/PostgreSQL)  
-螳｡譬ｸ莠ｺ<EFBFBD>夊劒諡滓楔譫<EFBFBD>ｸ? 
-扈楢ｮｺ<EFBFBD>哂- (莨倡ｧ€)縲よ楔譫<E6A594>ｮｾ隶｡隨ｦ蜷井ｺ大次逕溽炊蠢ｵ<E8A0A2>梧<EFBFBD>譛ｬ荳取黄螻墓€ｧ蟷ｳ陦｡濶ｯ螂ｽ縲ゆｽ<E38286>ｭ伜惠鄂醍ｻ懷<EFBDBB>蜿｣蜥御ｾ晁ｵ夜溜邇ｯ荳､荳ｪ蜈ｳ髞ｮ鬟朱勦轤ｹ髴€隗｣蜀ｳ縲?
-## **1\. 讓｡蝮礼ｺｧ豺ｱ蠎ｦ螳｡隶?(Module-Level Audit)**
+审核对象：5份独立部署文档 (Dify/Python/Node/Frontend/PostgreSQL)  
+审核人：虚拟架构师  
+结论：A- (优秀)。架构设计符合云原生理念，成本与扩展性平衡良好。但存在网络出口和依赖闭环两个关键风险点需解决。
 
-### **笨?1.1 蜑咲ｫｯ Nginx (SAE)**
+## **1\. 模块级深度审计 (Module-Level Audit)**
 
-* **莨倡せ**<2A>壼､夐亳谿ｵ譫<EFBDB5>ｻｺ莨倡ｧ€<EFBDA7>井ｽ鍋ｧｯ蟆擾ｼ会ｼ帷識蠅<E8AD98>序驥乗ｳｨ蜈･譁ｹ譯茨ｼ<E88CA8>nvsubst<73>蛾撼蟶ｸ荳謎ｸ夲ｼ瑚ｧ｣蜀ｳ莠<EFBDB3>撕諤<E69295>｡ｵ髱｢譌<EFBDA2>豕募勘諤<E58B98><E8ABA4>鄂ｮ蜷守ｫｯ逧<EFBDAF>埓鬚倥€? 
-* **菫ｮ豁｣蟒ｺ隶ｮ**<2A>? 
-  * 遑ｮ隶､ nginx.conf 荳ｭ蠑€蜷?gzip<69>瑚ｿ吝ｯ?React 螟ｧ菴鍋ｧ?JS 譁<>ｻｶ閾ｳ蜈ｳ驥崎ｦ√€? 
-  * 譽€譟?Nginx 逧?client\_max\_body\_size 驟咲ｽｮ縲ょ現逍?PDF/Excel 蜿ｯ閭ｽ雜<EFBDBD>ｿ<EFBFBD>ｻ倩ｮ､逧?1MB<4D>悟ｻｺ隶ｮ隶ｾ鄂ｮ荳ｺ 50M縲?
-### **笨?1.2 蜷守ｫｯ Node.js (SAE)**
+### **✅ 1.1 前端 Nginx (SAE)**
 
-* **莨倡せ**<2A>啀risma "蜿榊髄蜷梧ｭ･" 豬∫ｨ矩撼蟶ｸ蜉｡螳橸ｼ瑚ｧ｣蜀ｳ莠<EFBDB3>ｼ€蜿台ｹ<E58FB0>諠ｯ荳崎ｧ<E5B48E>激逧<E6BF80>琉鬚倥€１ostgres-Only 逧<>楔譫<E6A594>栫螟ｧ蝨ｰ髯堺ｽ惹ｺ<E683B9>ｿ千ｻｴ雍滓球縲? 
-* **菫ｮ豁｣蟒ｺ隶ｮ**<2A>? 
-  * **霑樊磁豕<E7A381>ｼ城｣朱勦**<2A>啀ython 譛榊苅螯よ棡蜩榊ｺ疲<EFBDBA><E796B2>悟錘遶ｯ逧?HTTP Client 隶ｾ鄂ｮ雜<EFBDAE>慮莠<E685AE>雛<EFBFBD>溷ｻｺ隶ｮ隶ｾ鄂?timeout: 30s<30>碁亟豁｢蜷守ｫｯ霑樊磁謨ｰ蝣<EFBDB0>ｧｯ縲?
-### **笨?1.3 Python 蠕ｮ譛榊<E8AD9B>?(SAE)**
+* **优点**：多阶段构建优秀（体积小）；环境变量注入方案（envsubst）非常专业，解决了静态页面无法动态配置后端的难题。  
+* **修正建议**：  
+  * 确认 nginx.conf 中开启 gzip，这对 React 大体积 JS 文件至关重要。  
+  * 检查 Nginx 的 client\_max\_body\_size 配置。医疗 PDF/Excel 可能超过默认的 1MB，建议设置为 50M。
 
-* **莨倡せ**<2A>壽<EFBFBD>遑ｮ謖<EFBDAE><E8AC96>莠<EFBFBD> libGL 遲臥ｳｻ扈滉ｾ晁ｵ夜琉鬚假ｼ瑚ｿ呎弍 Python 螳ｹ蝎ｨ蛹匁怙螟ｧ逧<EFBDA7>搗<EFBFBD>梧枚譯｣蟾ｲ謠仙燕隗<E78795>∩縲? 
-* **菫ｮ豁｣蟒ｺ隶ｮ**<2A>? 
-  * **OOM 鬟朱勦**<2A>啀ython 霑帷ｨ具ｼ亥ｰ､蜈ｶ譏ｯ PyMuPDF/OCR<43>蛾撼蟶ｸ蜷<EFBDB8><E89CB7>蟄倥€ょ惠 2G 蜀<>ｭ倬剞蛻ｶ荳具ｼ悟苅蠢<E88B85>剞蛻ｶ蟷ｶ蜿第焚<E7ACAC><E7849A>unicorn Workers 荳崎ｦ∬ｶ<E288AC>ｿ<EFBFBD> 2 荳ｪ<E88DB3>峨€?
-### **笨?1.4 Dify (ECS)**
+### **✅ 1.2 后端 Node.js (SAE)**
 
-* **莨倡せ**<2A>夐€画叫莠?ECS 驛ｨ鄂ｲ莉･菫晁ｯ∵焚謐ｮ遘∵怏蛹厄ｼ悟酔譌ｶ菴ｿ逕?Swap 髦ｲ豁｢ OOM<4F>碁撼蟶ｸ諛り｡後€? 
-* **菫ｮ豁｣蟒ｺ隶ｮ**<2A>? 
-  * **螳牙<EFBFBD>諤?*<2A>哘CS 逧?Redis 遶ｯ蜿｣ (6379) 蜥?Weaviate 遶ｯ蜿｣ (8080) **扈晏ｯｹ荳崎ｦ<E5B48E>**蟇ｹ蜈ｬ鄂大ｼ€謾ｾ縲ゆｻ<E38286><EFBDBB>隶ｸ localhost 蜥?VPC 蜀<>ｽ題ｮｿ髣ｮ縲?
-### **笨?1.5 謨ｰ謐ｮ蠎?(RDS)**
+* **优点**：Prisma "反向同步" 流程非常务实，解决了开发习惯不规范的问题。Postgres-Only 的架构极大地降低了运维负担。  
+* **修正建议**：  
+  * **连接泄漏风险**：Python 服务如果响应慢，后端的 HTTP Client 设置超时了吗？建议设置 timeout: 30s，防止后端连接数堆积。
 
-* **莨倡せ**<2A>售chema 髫皮ｦｻ隶ｾ隶｡譫∽ｽｳ縲? 
-* **菫ｮ豁｣蟒ｺ隶ｮ**<2A>? 
-  * **Dify 謨ｰ謐ｮ蠎馴囈遖?*<2A>夂｡ｮ隶?Dify 菴ｿ逕ｨ逧<EFBDA8>弍迢ｬ遶狗<E981B6>?dify\_prod 蠎難ｼ御ｸ崎ｦ∝柱荳壼苅陦ｨ豺ｷ蝨ｨ ai\_clinical\_research 蠎謎ｸｭ<EFBDB8>碁亟豁?Dify 蜊<>ｺｧ閼壽悽隸ｯ蛻<EFBDAF>荳壼苅陦ｨ縲?
-## **2\. 霍ｨ讓｡蝮鈴寔謌宣｣朱<EFBDA3>?(Integration Risks)**
+### **✅ 1.3 Python 微服务 (SAE)**
 
-### **<2A>圷 鬟朱勦荳€<E88DB3>售AE 逧?蟄､蟯帶譜蠎<E8AD9C>" (Internet Access)**
+* **优点**：明确指出了 libGL 等系统依赖问题，这是 Python 容器化最大的坑，文档已提前规避。  
+* **修正建议**：  
+  * **OOM 风险**：Python 进程（尤其是 PyMuPDF/OCR）非常吃内存。在 2G 内存限制下，务必限制并发数（Gunicorn Workers 不要超过 2 个）。
 
-* **髣ｮ鬚<EFBDAE>**<2A>售AE 驛ｨ鄂ｲ蝨?VPC 蜀<>ｼ碁ｻ倩ｮ､**豐｡譛牙<E8AD9B>鄂大<E98482>蜿｣**縲? 
-* **蝨ｺ譎ｯ**<2A>壼錘遶ｯ隹<EFBDAF><E99AB9>?DeepSeek API縲￣ython 荳玖ｽｽ蜈ｬ鄂<EFBDAC> PDF縲¨PM 螳芽｣<E88ABD>ｾ晁ｵ厄ｼ域桷蟒ｺ譌ｶ<E8AD8C>峨€? 
-* **蟇ｹ遲<EFBFBD>**<2A>壼ｿ<E5A3BC>｡ｻ蝨ｨ VPC 荳ｭ驟咲ｽ?**NAT 鄂大<E98482>** (謗ｨ闕<EFBDA8>) 謌也｡ｮ菫?SAE 譛臥ｻ大ｮ壼<EFBDAE>鄂?IP 逧<><E980A7>蜉帙€?*蜷ｦ蛻吩ｸ顔ｺｿ蠖灘､ｩ謇€譛?AI 蜉溯<E89C89>驛ｽ莨夊ｶ<E5A48A>慮縲?*
+### **✅ 1.4 Dify (ECS)**
+
+* **优点**：选择了 ECS 部署以保证数据私有化，同时使用 Swap 防止 OOM，非常懂行。  
+* **修正建议**：  
+  * **安全性**：ECS 的 Redis 端口 (6379) 和 Weaviate 端口 (8080) **绝对不要**对公网开放。仅允许 localhost 和 VPC 内网访问。
+
+### **✅ 1.5 数据库 (RDS)**
+
+* **优点**：Schema 隔离设计极佳。  
+* **修正建议**：  
+  * **Dify 数据库隔离**：确认 Dify 使用的是独立的 dify\_prod 库，不要和业务表混在 ai\_clinical\_research 库中，防止 Dify 升级脚本误删业务表。
+
+## **2\. 跨模块集成风险 (Integration Risks)**
+
+### **🚨 风险一：SAE 的"孤岛效应" (Internet Access)**
+
+* **问题**：SAE 部署在 VPC 内，默认**没有公网出口**。  
+* **场景**：后端调用 DeepSeek API、Python 下载公网 PDF、NPM 安装依赖（构建时）。  
+* **对策**：必须在 VPC 中配置 **NAT 网关** (推荐) 或确保 SAE 有绑定公网 IP 的能力。**否则上线当天所有 AI 功能都会超时。**
 
 ### **🔄 风险二：部署依赖死锁 (Deployment Deadlock)**
 
-* **邇ｰ雎｡**<2A>? 
-  1. 蜷守ｫｯ蜷ｯ蜉ｨ髴€隕?DIFY\_API\_KEY縲? 
-  2. DIFY\_API\_KEY 髴€隕?Dify 蜷ｯ蜉ｨ蟷ｶ莠ｺ蟾･逋ｻ蠖募錘謇崎<EFBFBD>逕滓<EFBFBD>縲? 
-  3. 蜷守ｫｯ螯よ棡驟咲ｽｮ莠?蛛･蠎ｷ譽€譟･螟ｱ雍･蛻咎㍾蜷ｯ"<22>悟惠蝪ｫ蜈･ Key 荵句燕莨壽裏髯宣㍾蜷ｯ縲? 
-* **蟇ｹ遲<EFBFBD>**<2A>夐ｦ匁ｬ｡驛ｨ鄂ｲ譌ｶ<E8AD8C>悟錘遶ｯ邇ｯ蠅<EFBDAF>序驥?DIFY\_API\_KEY 蜿ｯ莉･蜈亥｡ｫ荳ｪ蛛<EFBDAA>€ｼ<C280>亥ｦ?temp<6D>会ｼ瑚ｮｩ譛榊苅霍題ｵｷ譚･縲らｭ<E38289> Dify 驛ｨ鄂ｲ螂ｽ諡ｿ蛻ｰ逵<EFBDB0> Key 蜷趣ｼ梧峩譁ｰ SAE 驟咲ｽｮ蟷ｶ驥榊星縲?
-### **<2A>倹 鬟朱勦荳会ｼ壼燕遶ｯ荳?Dify 逧<>ｷｨ蝓?(CORS)**
+* **现象**：  
+  1. 后端启动需要 DIFY\_API\_KEY。  
+  2. DIFY\_API\_KEY 需要 Dify 启动并人工登录后才能生成。  
+  3. 后端如果配置了"健康检查失败则重启"，在填入 Key 之前会无限重启。  
+* **对策**：首次部署时，后端环境变量 DIFY\_API\_KEY 可以先填个假值（如 temp），让服务跑起来。等 Dify 部署好拿到真 Key 后，更新 SAE 配置并重启。
+
+### **🌐 风险三：前端与 Dify 的跨域 (CORS)**
+
+* **问题**：前端直接调用后端（通过 Nginx 代理）没问题。但如果前端需要**直接嵌入** Dify 的 Web UI（如 iframe）或直接调用 Dify API（绕过后端），会遇到 CORS。  
+* **对策**：坚持\*\*"所有请求走后端"\*\*的原则。前端 \-\> Nginx \-\> 后端 \-\> Dify。不要让前端直连 Dify，既安全又避免 CORS。
 
-* **髣ｮ鬚<EFBDAE>**<2A>壼燕遶ｯ逶ｴ謗･隹<EFBDA5>畑蜷守ｫｯ<EFBDAB>磯€夊ｿ<E5A48A> Nginx 莉｣逅<EFBDA3>ｼ画ｲ｡髣ｮ鬚倥€ゆｽ<E38286>ｦよ棡蜑咲ｫｯ髴€隕?*逶ｴ謗･蠏悟<E8A08F>** Dify 逧?Web UI<55>亥ｦ<E4BAA5> iframe<6D>画<EFBFBD>逶ｴ謗･隹<EFBDA5>畑 Dify API<50>育ｻ戊ｿ<E6888A>錘遶ｯ<E981B6>会ｼ御ｼ夐∞蛻ｰ CORS縲? 
-* **蟇ｹ遲<EFBDB9>**<2A>壼撓謖―*\*"謇€譛芽ｯｷ豎りｵｰ蜷守ｫｯ"\*\*逧<>次蛻吶€ょ燕遶?\-\> Nginx \-\> 蜷守ｫｯ \-\> Dify縲ゆｸ崎ｦ∬ｮｩ蜑咲ｫｯ逶ｴ霑<EFBDB4> Dify<66>梧里螳牙<E89EB3>蜿磯∩蜈?CORS縲?
 ## **3\. 架构关系图谱**
 
 \[浏览器\]  
@@ -69,18 +77,19 @@
    |  
    \+--(HTTPS)--\> \[OSS 对象存储\]  
    |  
-   \+--(NAT鄂大<EFBFBD>)--\> \[莠定＃鄂? DeepSeek/OpenAI\]
+   \+--(NAT网关)--\> \[互联网: DeepSeek/OpenAI\]
 
-## **4\. 扈?1-2 莠ｺ蝗｢髦溽噪逕溷ｭ伜ｻｺ隶ｮ**
+## **4\. 给 1-2 人团队的生存建议**
 
-1. **逵<EFBFBD>蝶鮟醍ｧ第橿**<EFBFBD>? 
-   * SAE 2.0 譛?*髣ｲ鄂ｮ隶｡雍ｹ**蜉溯<E89C89>縲ょｼ€蜿醍識蠅<E8AD98>ｼ域ｵ玖ｯ慕識蠅<E8AD98>ｼ牙苅蠢<E88B85>ｼ€蜷ｯ<E89CB7>梧ｲ｡莠ｺ逕ｨ譌ｶ荳肴噺 CPU/蜀<>ｭ<EFBFBD> 雍ｹ縲? 
-   * RDS 雍ｭ荵ｰ**騾夂畑蝙?* (2譬?G) 蜊ｳ蜿ｯ<EFBFBD>御ｸ崎ｦ∽ｹｰ迢ｬ莠ｫ蝙具ｼ悟､溽畑蠕井ｹ<EFBFBD>€? 
-2. **荳崎ｦ∬<EFBFBD>蟒ｺ逶第而**<EFBFBD>? 
-   * 逶ｴ謗･逕ｨ髦ｿ驥御ｺ<EFBFBD> **ARMS** (蠎皮畑螳樊慮逶第而譛榊苅) 逧<><E980A7>雍ｹ鬚晏ｺｦ謌門渕遑€迚医€ゆｸ崎ｦ∬<EFBDA6>蟾ｱ謳ｭ Prometheus \+ Grafana<EFBFBD>檎ｻｴ謚､謌先悽螟ｪ鬮倥€? 
-3. **謨ｰ謐ｮ螟<EFBFBD>ｻｽ譏ｯ蠎慕ｺ?*<2A>? 
-   * RDS 蠑€蜷ｯ閾ｪ蜉ｨ螟<EFBFBD>ｻｽ<EFBFBD>井ｿ晉蕗7螟ｩ<EFBFBD>峨€? 
-   * ECS 荳顔噪 Dify docker-compose.yaml 蜥?.env 譁<EFBFBD>ｻｶ<EFBFBD>悟苅蠢<EFBFBD>惠譛ｬ蝨ｰ謌?Git 遘∵怏莉灘ｺ灘､<E78198>ｻｽ荳€莉ｽ縲<EFBDBD>CS 豐｡莠<EFBDA1>庄莉･驥堺ｹｰ<EFBDB9>碁<EFBFBD>鄂ｮ譁<EFBDAE>ｻｶ豐｡莠<EFBDA1>ｰｱ蠕鈴㍾驟阪€? 
-4. **蠑€蜿第譜邇?*<2A>? 
-   * 蛻ｩ逕ｨ ECS 蛛?*霍ｳ譚ｿ譛?*<2A>梧悽蝨ｰ逶ｴ霑?RDS 蠑€蜿代€ゆｸ崎ｦ∵ｯ乗ｬ｡驛ｽ蜀吩ｻ｣遐∝悉譟･謨ｰ謐ｮ縲?
-**譛€扈育ｻ楢ｮ?*<2A>夊ｿ吝･玲楔譫<E6A594>ｮｾ隶｡蠕鈴撼蟶ｸ謇主ｮ橸ｼ悟ｮ悟<EFBDAE>蜿ｯ莉･謾ｯ謦台ｻ<E58FB0> 0 蛻?10 荳<>畑謌ｷ逧<EFBDB7>ｧ<EFBFBD>ｨ｡縲りｯｷ驥咲せ隗｣蜀ｳ **"SAE 隶ｿ髣ｮ蜈ｬ鄂<EFBDAC> (NAT)"** 霑吩ｸｪ髣ｮ鬚假ｼ悟叉蜿ｯ蠑€蟋矩Κ鄂ｲ縲
+1. **省钱黑科技**：  
+   * SAE 2.0 有**闲置计费**功能。开发环境（测试环境）务必开启，没人用时不收 CPU/内存 费。  
+   * RDS 购买**通用型** (2核4G) 即可，不要买独享型，够用很久。  
+2. **不要自建监控**：  
+   * 直接用阿里云 **ARMS** (应用实时监控服务) 的免费额度或基础版。不要自己搭 Prometheus \+ Grafana，维护成本太高。  
+3. **数据备份是底线**：  
+   * RDS 开启自动备份（保留7天）。  
+   * ECS 上的 Dify docker-compose.yaml 和 .env 文件，务必在本地或 Git 私有仓库备份一份。ECS 没了可以重买，配置文件没了就得重配。  
+4. **开发效率**：  
+   * 利用 ECS 做**跳板机**，本地直连 RDS 开发。不要每次都写代码去查数据。
+
+**最终结论**：这套架构设计得非常扎实，完全可以支撑从 0 到 10 万用户的规模。请重点解决 **"SAE 访问公网 (NAT)"** 这个问题，即可开始部署。