家长如何参与多个孩子的学习管理

在少儿与青少年的培训场景中，“使用者”与“买单者”往往是分离的：去教室上课的是孩子（学员），但查看课表、跟进考勤、代办请假以及支付学费的通常是家长。

更复杂的是，一个家长可能有多个孩子在同一机构的不同班级就读，而一个孩子也可能同时绑定父亲和母亲两个账号。

如果系统没有区分这些身份，切换孩子、代办学习事务和付款就可能使用错误的主体。教育机构管理系统在九月重构中，将绑定关系、当前孩子和实际付款人分别处理。

1. 从附属入口到独立关系实体

在最初的简易原型中，家长被视为学员端的一个“附属视图”，注册时输入孩子账号，孩子点击拒绝就直接将家长账号删除。

多孩子场景能说明这项设计的风险：假设一位家长已绑定一个孩子，又向另一个孩子申请绑定，后一次申请被拒绝不应影响已有账号、钱包和其他绑定关系。这是规则上的冲突，并非已经发生资产丢失事故的记录。

9 月重构将相关操作调整为分别处理绑定关系与账号状态：

Parent User家长账号实体status: pending / normal / frozen；拥有独立登录凭据与钱包

Relation绑定授权关系 AbindingStatus: confirmed；关联大儿子（Student 1）

Relation绑定授权关系 BbindingStatus: rejected；关联小女儿（Student 2）

两条绑定关系之间没有先后，家长账号本身的状态也不因某一条被拒而改变。

• 关系状态与账号状态分离：
  • 绑定关系的 bindingStatus 仅包含 pending（待确认）、confirmed（已确认）、rejected（已拒绝）；
  • 家长账号自身的 status 包含 pending（待激活）、normal（正常）、frozen（已冻结）。
• 拒绝不删号，确认不解冻：
  • 学员拒绝绑定申请，将该笔授权关系置为 rejected 并通知家长，不再通过删除家长账号来处理拒绝；
  • 学员确认绑定时，若家长账号为待激活则激活为正常；若账号为 frozen（冻结），确认操作保留冻结状态。

2. 集中化多孩子状态机管理

在前端界面中，家长端顶部通常提供一个“当前孩子切换器”。但在早期，课程页、课表页、成绩页和订单页各自维护了一份局部的孩子状态，导致切换孩子后，部分页面依然消费旧孩子的缓存，引发数据串扰。

9 月前端架构将孩子状态的唯一归属收拢至全局共享 User Store，并建立了严密的五态生命周期：

当前状态	触发条件	转到
（进入页面）	初始化	idle
idle	触发多孩子查询	loading
loading	存在已确认绑定的孩子，选定当前 activeChildId	ready
loading	确认当前无任何有效绑定的孩子，友好展示绑定指引	empty
loading	网络故障或接口异常，提供重试按钮	error
ready	切换孩子或重新登录	loading
empty	完成新绑定审核	loading
error	点击手动重试	loading

• 杜绝非法回退：当查询失败或无孩子数据时，系统坚决杜绝“拿家长自己的 userId 去调用学员查询接口”的错误降级行为；
• 缓存校验：持久化缓存的 childId 在每次重新加载时，必须在后端返回的 confirmed 列表中重新核验；若该关系已被解除，立即自动重置为列表中的首个有效孩子。

3. 三重身份的精确消歧

为了防止代办交易中的身份混淆，九月迁移的相关入口明确区分三重主体：

业务主体维度	真实含义与归属	典型应用场景
业务主体（Student / Child）	实际接受教学服务、享有课程课时与成绩评价的学生	课表展示、上课考勤、成绩雷达图、请假配额计算
操作发起者（Operator / Parent）	当前登录系统、点击按钮发起请求的具体账号	登录鉴权日志、通知接收人、代办操作审计
资金付款人（Payer / Wallet）	实际出资扣款的钱包账号主体	订单实付记录、余额扣减、消费流水、退款时优先确定的接收人

家长订单列表的全局视图

在家长浏览订单列表时，系统默认查询该家长已确认绑定的全部孩子的订单，通过订单自身的孩子与班级信息识别归属。部分历史订单缺少姓名，需要显示待核对提示，不能用当前孩子补造归属。

顶部的“当前孩子切换器”影响课表与成绩等学习视图；订单付款使用订单自身的学员身份，不随当前孩子切换。退款优先使用可信付款记录中的付款人，历史缺少付款人记录时仍保留退回申请人的兼容规则。

4. 课次代办的严格安全边界

在本轮修订涉及的课次代办入口中，身份与时间校验包括：

1. 显式传参与强制后端校验：家长代办请求必须显式传入 childId，后端拦截器核验该 childId 是否属于当前登录家长且处于 confirmed 状态，严禁前端仅传 scheduleId 而由后端盲目猜测身份；
2. 统一业务时区（Asia/Shanghai）：服务端按统一业务时区判断课次是否已开始，避免客户端时区差异造成口径不一致；允许办理的时间范围由服务端校验；
3. 正确关联课程实例：请假配额校验必须严格通过 CourseSchedule 提取真实的开班实例 ID（courseInstanceId），坚决防止将排课课次 ID 误传为课程 ID 导致配额误判。

这些调整把三个问题分开处理：绑定关系决定家长能代办谁的事务，当前孩子决定学习页面看谁的数据，订单与付款记录决定交易属于谁。验证覆盖的是九月指定入口；历史资料缺失和未迁移模块仍需分别核对。