## 问题概述
- 现状：`users` 同时承载学生/老师/班主任/干部等身份，且“学生↔用户”绑定分散，导致查询与权限判定割裂。
- 痛点：
  - 身份与账号未解耦，复用困难、扩展性差
  - 教师/班主任/学生的组织归属（班级、系部）未统一建模
  - 仪表盘与考勤口径需跨实体检索，复杂度与耦合高

## 目标
- 账户与人物实体解耦：统一用“账号（Account）↔人物（Person）”绑定
- 学生/老师/干部使用专属子实体，清晰表达业务属性
- 路由鉴权同时基于账号的角色等级与实体身份

## 数据模型（MongoDB 集合）
1. accounts（账号）
- 字段：`_id, username, email, hashed_password, edition, status`
- 说明：仅承载登录与权限基础信息，不直接承载业务属性

2. persons（人物基础档案）
- 字段：`person_id, name, gender, phone, id_no, type: ['student','teacher','staff']`
- 索引：`person_id` 唯一

3. students（学生实体）
- 字段：`person_id, student_id, grade, major, class_id, guardians, status, department`
- 关系：`account_id?`（可空）；索引：`student_id` 唯一、`class_id`、`account_id` 稀疏唯一

4. teachers（教师实体）
- 字段：`person_id, teacher_id, department, title, roles: ['teacher','homeroom','cadre']`
- 关系：`account_id?`；索引：`teacher_id` 唯一、`department`、`account_id` 稀疏唯一

5. bindings（统一绑定表）
- 字段：`account_id, person_id, primary: boolean, type`
- 说明：一账号可绑定一个主人物（primary）与若干备用绑定；索引：`account_id+type` 唯一（primary）

6. classes（班级）
- 扩展：`head_teacher_person_id` 替代原 `head_teacher_id`（指向教师实体）

7. schedules（课表）
- 扩展：`teacher_person_id` 替代原 `teacher_id`；`classes: [{class_id, location}]` 保持共享节次

8. leaves/attendance/conduct/directives
- 维持现有集合，但在查询上通过 `person_id`/`student_id`/`class_id` 衔接

## 鉴权与角色
- 保留 `role_level`（user=1, manager=2, leader=3, master=4, administrator=5）
- 登录载荷扩展：`person_id, person_type, bound_primary`（用于后端快速定位实体）
- 路由依赖：在 `require_role(min_level)` 基础上增加实体类型校验（例如学生端必须有绑定且为 `student`）

## API 设计（新增/改造）
- 绑定管理（新）：`POST /api/v1/bindings`、`DELETE /api/v1/bindings/{account_id}/{person_id}`、`GET /api/v1/bindings/me`
- 人物档案：`POST/GET/PUT /api/v1/persons`
- 学生：`POST/GET/PUT /api/v1/students`（含批量导入/绑定工具）
- 教师：`POST/GET/PUT /api/v1/teachers`（标记班主任/干部）
- 班级与课表：适配 `person_id` 字段，查询统一从实体出发
- 仪表盘路由：学生/班主任/中层/校级端以实体维度查询，兼容旧数据

## 迁移方案
1. 引入新集合与索引（不破坏现有）
2. 从现有 `users` 生成 `persons` 与对应 `students/teachers`（示例用户：`leader_edu→teacher(cadre)`、`manager_edu→teacher(homeroom)`）
3. 写入 `bindings`（把当前登录账号与对应人物建立主绑定）
4. 更新 `classes.head_teacher_person_id` 与 `schedules.teacher_person_id`
5. 仪表盘查询优先走新模型，保留旧模型回退

## 分阶段实施
- M1（模型与绑定）：创建集合与索引，提供绑定接口，完成示例数据迁移与验证
- M2（查询改造）：学生/班主任/中层/校级端查询切换到实体模型，完成序列化与性能验证
- M3（管理接口）：完善人员与班级、系部管理接口，支持批量导入/绑定
- M4（清理与文档）：去除冗余字段、补充接口文档与示例

## 验证与性能
- MCP 校验集合与索引；事务性绑定校验唯一约束
- 查询走索引：`account_id/person_id/class_id/teacher_person_id`
- 压测：按班级/教师的日级查询与节次查询

## 兼容策略
- 保留现有 `users` 字段与接口短期可用
- 新接口逐步替换前端对旧字段的依赖

确认后，我将按此方案落地：先交付 M1（集合与绑定接口），在不影响现有功能的前提下逐步迁移与联调。