目录1. 技术实现思路2. 目前已实现接口3. 关键业务流程说明3.1 登录流程3.2 个人资料与角色3.3 用户、患者、医生关系4. 总结本周主要推进了后端的用户模块进入到“可登录、可鉴权、可管理基础人员信息”的阶段。当前已经完成用户认证、个人信息、角色切换、患者/医生基础信息接口以及对应的数据访问与服务层逻辑能够支撑前端做基础联调。1. 技术实现思路延续项目既定技术栈FastAPI 负责路由与请求处理Pydantic v2 做请求参数校验sqlite3做数据访问Service Repository 分层组织业务逻辑Session 表保存登录态Header 传递会话令牌整体分层设计如下路由层只接参数、调服务、返回结果服务层做业务规则校验与流程编排仓储层专注 SQL 读写核心层数据库连接、会话存储、配置与异常2. 目前已实现接口// 认证与个人信息 POST /api/v1/auth/login/wechat POST /api/v1/auth/login/web POST /api/v1/auth/logout GET /api/v1/users/me PATCH /api/v1/users/me POST /api/v1/users/me/roles/select POST /api/v1/users/me/roles/switch POST /api/v1/users/me/avatar // 用户管理 GET /api/v1/users POST /api/v1/users PATCH /api/v1/users/{user_id} PATCH /api/v1/users/{user_id}/status // 患者/医生基础档案 GET /api/v1/patients POST /api/v1/patients GET /api/v1/doctors POST /api/v1/doctors PATCH /api/v1/doctors/{doctor_id}/status3. 关键业务流程说明3.1 登录流程当前支持两种入口微信登录通过 code 换取 openid若用户不存在则自动注册默认 patient 角色Web 调试登录通过 username 登录开发环境下可自动注册方便前后端联调登录成功后统一返回session_tokenuser_idrole / active_roleexpires_in这保证了前端可以在一次登录响应中拿到“身份 会话 状态”。3.2 个人资料与角色本周补齐了用户中心能力获取个人信息GET /users/me更新昵称、手机号、邮箱PATCH /users/me角色选择/切换select/switch头像上传限制图片类型与大小3.3 用户、患者、医生关系数据上采用“用户主表 业务扩展表”users 保存登录与基础身份信息patients 通过 user_id 关联用户doctors 通过 user_id 关联用户并通过 department_id 关联科室这种拆分便于后续扩展例如患者病史、医生排班等不会把 users 表做得过于臃肿。4. 总结本次主要加上了用户相关的模块配置OSS实现上传图片的云存储分析了用户/医生/病人的关联为后面实现chat复杂模块设备分配、模型调用、医生联调等定下了基础。