项目修改记录（按日 · 仅业务向提交）

收录原则： 仅保留对产品业务规则、流程、数据模型或角色端能力有实质影响的提交；不含纯合并、纯第三方组件换皮、与业务无关的样式微调等。
说明： 按自然日聚合；每条提交拆成多段描述业务背景、改动要点、角色影响。

---

2026-04-28

7738dbf — feat: 优化教室发布页面的交互

业务背景

机构要把线下教室「数字化」上架，核心信息除了面积、设施，还包括在哪儿、属于哪一片区域，否则学员和导师搜索、导航、对比场地时会不直观，后续预约也容易因信息不全产生纠纷。

本次改动要点

教室发布 / 编辑流程里，强化了地理位置与区域维度的录入方式。

地图选点让机构用直观方式标定场地坐标，区域数据与表单字段联动，减少手工填错行政区或商圈的情况。

机构在提交前能更完整表达「这家店 / 这间教室在什么位置」，为后续列表展示、地图入口和对外分享打基础。

对使用方的影响

机构运营人员发布教室时步骤更清晰，必填与选填的界限在交互上更顺。

学员与导师之后在浏览教室时，能拿到更可靠的位置与区域标签（具体展示形态依赖后续页面，但数据源在此提交阶段被补全）。

项目侧同步了小程序入口配置，保证新流程在包内可被正常打开，避免因未注册页面导致的调试中断。

---

2026-04-29

9a77e45 — 优化机构端

业务背景

机构端不仅要「有一条教室数据」，还要能长期维护：改价、改时段、上下架、纠错地址等。导师在约课或租场前也需要看到教室详情，否则只能在订单里猜条件，体验差且增加客服成本。

机构侧能力

教室列表与维护路径被梳理，使运营从「找到某一间教室」到「改完保存」之间的跳转更少、状态更明确。

教室详情成为一等公民页面，机构可核对发布结果；同一套详情能力延伸到导师侧，导师在决策前能看到与机构一致的信息口径。

时间与预约相关

引入日期时间区间类控件，统一表达「哪一天、哪一段可约 / 可租」这类业务时间。

它与房间管理、表单编辑串在一起，避免在多个页面各写一套时间组件、各有一套校验规则。

流程收敛

原先地图选点以独立页面存在，维护与入口容易分叉；本次把能力收进当前主流程，降低「两个入口、两套逻辑」的风险。

与教室预约、跳转详情相关的通用逻辑被沉淀，后续加新场景（例如从订单进详情、从消息进详情）可以复用同一套规则。

---

2026-04-30

559d9e9 — feat: 优化机构和导师的预约教室相关逻辑

业务背景

场地预约涉及多角色：机构要管场地与收款/确认，导师要订时段上课，学员可能关联到课包或活动。若订单详情、列表入口散落在主包且不按角色分包，包体与路由都会臃肿，用户也会搞不清「我的订单」到底是课单还是场地单。

订单与入口的职责划分

机构与导师在场地预约、场地订单相关界面上的分工更清晰：谁发起、谁履约、在哪儿看进度，通过入口与页面层次表达，而不是仅靠文案硬提示。

学员侧与导师侧的订单详情被挪到对应分包，主包保留更通用的入口清单。这样不同身份登录后，看到的页面集合更符合最小权限与心智模型。

场地预订列表与链路

增加面向场地预约记录 / 场地预订列表的主包能力，使用户可以从列表进入详情，再从详情回到订单或教室上下文。

工具层梳理了房间信息与地图展示之间的映射，减少「列表里一间房、地图上对不上」的体验问题。

全 App 动线

发现页、个人中心、首页等与「约场地」相关的跳转策略一并调整，使同一业务概念在不同入口用语一致、去向一致，降低「从这个入口进是一种流程、从那个入口进是另一种流程」的割裂感。

---

2026-05-02

878a6f8 — feat: 优化导师和学员的选课逻辑

业务背景

课程在业务上通常按舞种或品类划分，若导师发布、学员浏览、活动聚合各用一套字符串或枚举，很快会出现「爵士 / Jazz / jazz」并存，筛选与统计都会失真。

类型体系统一

在常量层收口舞种 / 课程类型，全栈（至少在前端与联调 mock 层）共用同一套代码与展示文案。

这直接影响：列表筛选是否可靠、详情页标签是否可比、活动页聚合是否重复计算。

导师侧

课程发布与课程管理与新的类型体系对齐，导师在选类型时选项稳定，发布后的课程在管理列表里也能按类型维度的规则展示或排序（具体规则由页面承接，但数据源已统一）。

学员侧

活动页与课程详情页在「这门课属于哪一类」上表达一致，学员在对比多门课、从活动跳进详情时不会因为标签不一致而产生误解。

联调与演示

Mock 数据与展示同步调整，便于本地覆盖多舞种、多课程路径，减少「线上一种数据、本地另一种数据」造成的假问题。

---

2026-05-06

015fe71 — commit（学员意向 / 订单与课程发布相关）

业务背景

学员不仅有「立即购买 / 报名」，还有意向表达（例如想学某类课、想等开班），需要与订单生命周期区分；同时学员需要订单列表来回看状态，否则只能依赖零碎入口。

学员侧

新增订单列表类能力，使历史订单、进行中的预约或课单有统一回顾入口。

学员意向发布流程随路由与页面配置更新，并与首页、活动、我的等主导航联动，避免意向填完却找不到入口。

导师侧

课程发布与学员侧新增能力在路由与选项上一致，防止导师发布后学员侧字段对不上、或意向单与正式课类型不一致。

表单与配置复用

舞种等选项通过专门的选项组装能力输出，发布课程、填写意向等多处表单引用同一来源，减少「A 页面有 10 个舞种、B 页面只有 8 个」的配置漂移。

---

2026-05-08

f4c2902 — 页面细节调整

业务背景

多角色、多业务线并行迭代后，容易出现同一业务概念在不同页面叫法不同、返回路径不同、状态展示不同。需要一轮跨页面的收敛，把注意力还给核心任务（订课、订场、看订单）。

跨线打磨

机构、学员、导师相关页面在流程、文案与跳转上做了对齐：进入详情、返回列表、从订单再进教室等路径更连贯。

删除或合并已冗余的列表、订单子页面，减少用户「点进一个列表发现是旧版」的概率。

沟通场景

增加电话联络类能力，支持在合规前提下从业务页发起拨号，缩短「看到机构 / 导师信息 → 实际沟通」的路径。

导航与 Tab

底部 Tab 与路由表同步更新，保证收敛后的页面在主导航里仍然有稳定入口，而不是只改页面却在 Tab 上留死链。

6535ea8 — feat: 修改首页结构

业务背景

首页是各角色进入小程序后的任务枢纽。若首页仍以泛内容为主、弱化管理入口，导师会频繁多点几次才能回到课程管理，拉低日常运营效率。

信息架构

首页结构按「先主任务、后辅信息」调整：不同角色进入后，第一眼与后续动线更贴近其日常操作。

导师路径

导师首页与课程管理绑定更紧，从「打开小程序」到「处理课程发布 / 班级」的步数减少。

配置一致性

pages.json 与首页结构同步改版，避免新旧首页路由并存：用户收藏的旧路径、或测试时书签的路径不会落到空白或重复页。

---

2026-05-09

5c7005a — 联调

业务背景

此前大量能力依赖前端 mock，业务规则与真实接口未对齐时，只能「看起来像能用」。联调阶段要把鉴权、数据持久化、第三方依赖跑通，才能把产品逻辑放到真实环境里验证。

后端基础设施

鉴权链路落地，健康检查便于部署与排障。

数据库连接与迁移脚本就位，schema 与种子数据可与本地或远程 MySQL 对齐，避免「代码里一套表、库里另一套表」。

领域接口拆分

机构、场地租赁、学员、导师、上传、用户等路由按业务域拆分文件，后续迭代时权限、限流、文档都可以按域推进，而不是挤在单文件里难以评审。

微信与存储

集成微信相关能力与对象存储 / 上传服务，支撑真实登录、素材与附件类业务，而不是全部用占位 URL。

前后端约定

演示账号、环境变量示例、登录页与 mock 账户描述与后端对齐，使同一套账号与角色在小程序与 API 上调试时语义一致，减少「前端以为是学员、后端 token 当机构」的错位。

28ffd44 — 学员增加课程状态

业务背景

学员报名后，一门课可能会经历报名成功、待开课、进行中、已结课等阶段；若没有统一的状态模型，列表里只能看到标题和金额，用户无法判断「下一步该上课还是该评价 / 该续费」。

数据与接口

报名 / 选课相关查询扩展，返回足够字段表达当前业务状态。

拼班、课程、导师相关接口配合调整，使同一门课在不同入口读到的状态一致。

鉴权与权限

中间件与鉴权规则配合，避免学员看到不属于自己的课或拼班，也避免状态字段泄漏到其他用户上下文。

学员界面

「我的报名」能按状态分群或展示明确标签；课程详情、拼班详情在按钮与提示上与状态绑定（例如未开课禁止某些操作）。

发现、首页、个人中心等入口做同步，避免状态能力上线后，旧入口仍引导用户去看不含状态的旧版信息。

导师侧

课程发布与课程元数据对齐新的状态表达，降低「导师填的信息与学生看到的进度不一致」的沟通成本。

7419520 — feat: 调整逻辑

业务背景

产品从「多 Tab 平铺所有频道」演进到「按角色组织主线任务」，同时需要站内通知 / 消息，否则订单变更、拼班成团等事件只能依赖微信模板消息或人工通知，闭环不完整。

通知与消息中心

后端提供消息列表、未读数量、单条已读、全部已读等接口，为统一消息中心打底；各端后续可按同一协议渲染卡片或跳转业务详情。

分角色壳与 Tab 面板

小程序主界面改为分角色壳页面 + Tab 面板：学员聚焦课程与拼班，导师聚焦授课与租场，机构聚焦场地与经营类入口。

「我的」以面板承载账号、设置、辅助入口，与主 Tab 任务区分离，减少一个 Tab 里堆十来个入口的拥挤感。

独立消息页

新增消息页并与底部导航协同，使用户养成「有事看消息中心」的习惯，而不是在订单、拼班之间来回找红点。

身份与首页策略

引入按角色回到各自首页的导航策略，切换身份后不会卡在上一个角色的 Tab 结构里，降低误操作与困惑。

旧结构的下线

主包中与旧版「发现 / 活动 / 独立首页」强耦合的页面形态被移除或替换，统一归位到壳层导航。

后端协同

拼班、课程、订单、机构、租赁、学员、导师等路由与数据结构同步调整，使消息、订单与角色首页这一批产品改动在 API 层有对应支撑，而不是前端单独换皮。

---