协奏综合管理系统

• 按真实资源判断冲突

  不同服务名称映射到共享资源键，不能因为卖的是另一种服务，就绕开同一空间的时间冲突。

• 占用覆盖完整履约范围

  准备、退场、赠送与增值占用一起核对，不只检查报价上的开始和结束时间。

• 失败尝试释放，占位带有效期

  多天订单分批取得占位，失败时按所有者尝试释放已取得批次；占位保留有效期，清理仍需核对支付与关联状态。

硬占用与可让出的缓冲分别判断，失败释放保留补偿路径。

• 名额与审核状态一起校验

  审核入口核对活动权限、资格与容量，在事务中处理审核及名额记录，不靠客户端显示的余量决定放行。

• 支付接手已有占位

  仍有效的审核预留转移到支付流程；过期则重新核对名额。转移、取消与释放核对关联和所有者，避免释放他人的占位。

• 退款也属于活动经营链

  合作方退款核对活动范围、真实支付与状态指纹；未知结果保留待核对，不把活动退款变成无条件财务权限。

活动终止、退款及记录归档是不同动作，分别保留状态。

• 草稿与发布分开

  草稿不改变当前发布内容；发布时保存独立版本，并在事务内更新活动流程。

• 答卷保留当时题目

  答卷记录问卷版本、原题目与选项、标题和说明；已有答卷按原题目校验，答案修改另留历史。

• 旧表单不套新版题目

  新版发布后，尚未提交的旧表单需要重新加载；已有答卷不会因后来改题而被新配置覆盖。

问卷随具体订单保留；加购与共享空间仍需重新检查资源。

• 提交先进入待审

  服务端核对教师、学员、课包与排期归属；取消、待调课时阻止申请。已消课要走更正流程，而不是再次普通提交。

• 确认时再认版本

  核对申请与排期版本；更正分支还核对原消课版本。内容已改变就要求重新核对，不把打开页面当作长期数据库锁。

• 关联结果成组更新

  审核事务处理履约记录、对应课包、学员、课酬快照、排期及审计。批量审核仍遵守单笔规则，失败项单独反馈。

批量申请允许逐项处理；消课不产生第二次收款，审核不等于发薪。

• 识别主体，不只看姓名

  按稳定身份与课程关联归组；主课、陪练分别呈现。未知或歧义关联进入核对，不自动猜一个同名学员。

• 续课保留原始记录

  原课包余额、期限、实收与退款仍独立；聚合页面不把多次购买重新写成一个总账本。

• 更正保留差额与事件

  改课按照课时、课酬变化处理，保留修改来源与事件。结账后的来源变化进入差异核对，而不是悄悄重发。

组合档案是查询视图；不同课包的余额、记录与权限不混合。

• 教学修改与结账共享保护

  准备结账期间，对同月关联教学修改进行检查，降低“按旧课酬结账、同时又改课”的交错风险。

• 稳定来源与预览指纹

  人员应付汇总与明细共用来源计算。确认前核对预览指纹，结账项使用稳定来源认领，而不是每点击一次新增一套。

• 批次与差异明确保留

  准备中的批次可继续处理；已结账来源变化列为差异。结账确认不自动再写一笔财务支出流水。

来源变化列为差异，结账记录不等于真实转账。

• 先核验通知，再确认到账

  接口请求签名，回调核验平台签名并解密通知，首次确认时再核对订单金额。付款密钥不进入小程序页面。

• 让重复处理汇入原记录

  确认时以条件更新取得短期处理权；重试查找已有预约或报名。业务未完成时保留“已支付、待确认”，不抹掉付款事实。

• 退出页面，也要查清结果

  过期订单先查支付结果，再决定关闭与释放占用。查询异常时保留待核对，优先避免误放已经付款的资源。

支付到账与业务完成分别记录；未完成的业务保留恢复路径。

• 先校验与预占，再调用微信

  核对归属、已付状态和剩余可退金额，保存退款号并进入申请中，再发起外部退款。

• 未知结果沿用原申请

  提交异常后查询原退款号。查询仍不明确时保留处理中或待核对；校验不匹配则记录错误，不伪装为退款成功。

• 多次退款按笔合并

  成功回调在事务内重读订单，按退款号合并，再关联退款流水。同一退款号对应同一笔退款流水，原收款记录保留。

结果未知先查询原退款号；确认成功后再登记退款事实。

• 真实资金使用稳定来源

  微信收入关联交易号，退款关联退款号。后续修改报价不重写原实付；缺少核验信息时保留待核对，不用报价凑出收入。

• 账单反查，而非只信本系统

  官方账单按日导入，校验下载完整性并分块处理。整日导入完成才记成功；差额通过有依据的核验调整记录表达。

• 长任务有状态与恢复点

  核验保存阶段和游标，租约限制重复处理；失败有限重试，保留进度。部分完成与整月完成分别呈现。

净收入不是利润；退款按实际发生时间与原始来源追溯。

• 高风险配置限定管理权限

  支付维护设置由管理员修改；资金相关动作在服务端检查身份和细分授权，不只靠前端隐藏菜单。

• 列明入口设置维护拦截

  新建与预支付的指定入口读取维护配置，返回统一提示；既有订单的后续处理单独管理。

• 明确尚未覆盖的边界

  目前覆盖指定的新建与预支付入口，尚不包括直接续付；配置读取异常时不启用维护拦截，后续需完善覆盖与异常策略。

维护入口按支付来源与业务类型检查，不等于暂停全部系统业务。

• 配置复用正式组件

  首页通过同一套模块组件组织不同场景。内容、顺序与主题由配置驱动，无需为每种布局重新开发页面。

• 修订校验减少覆盖冲突

  携带有效修订号保存时，事务中核对是否已有更新。发现冲突要求重新核对，而不是默认旧窗口可以覆盖新稿。

• 发布版本与历史回退

  发布前验证配置并建立布局快照；历史版本恢复为草稿，保留再编辑、预览与发布机会。

历史恢复先回草稿；发布快照保存布局，动态内容保持独立更新。配置范围限于现有模块。

• 快照按账号与会话分区

  优先显示同账号快照，按访问更新并合并同时进行的相同请求，避免一刷新就整页闪空。

• 写回前检查会话代次

  请求携带账号范围与会话变化标记，迟到的响应只有仍匹配当前上下文才更新画面。

• 展示缓存不替代授权

  权限拒绝不能靠旧画面继续操作；付款、余额、权益、占用和管理动作仍由服务端重新检查。

缓存只改善展示等待；敏感操作仍复核服务端会话、权限及业务归属。