文档版本:v1.0 最后更新:2026-04-07 14:08:00
本文档写给 backend 当前开发线程,目标是用一份短文档说明两件事:
本文档不替代以下方案文档,而是它们的执行版摘要:
当前系统建议继续按以下链路理解,不要回退到“散装配置 + 临时页面”的推进方式:
地图运行域
-> Place / MapAsset / TileRelease
-> CourseSource / CourseSet / CourseVariant
-> MapRuntimeBinding
活动运营域
-> Event / EventPresentation / ContentBundle
-> EventRelease
客户端消费域
-> event detail / play / launch / result / entry-home
-> frontend 只消费发布后的稳定摘要
EventEventReleaseSessionlaunch.runtimecurrentPresentation / currentContentBundleplay.canLaunchplay.canLaunch 为准session 才是最终绑定运行对象和多赛道 variant 的事实来源backend 后续支持游戏定制,建议继续按这五层推进:
负责:
负责:
负责:
负责:
EventPresentationContentBundle负责:
当前 backend 不建议继续四处补小接口,而应优先把以下 4 条生产链做稳。
优先保证以下对象关系稳定:
PlaceMapAssetTileReleaseCourseSourceCourseSetCourseVariantMapRuntimeBindingEventPresentationContentBundleEventRelease要求:
发布链当前应继续保持:
runtime 不可进入presentation 不可进入content bundle 不可进入manifest 不可进入也就是:
play.canLaunchlaunch必须共享同一套发布完整性语义。
多赛道当前不是前端显示问题,而是 backend 生产链问题最容易出错的部分。
backend 当前应确保:
assignmentMode 真正进入发布物play.courseVariants[] 真正进入发布物preview.variants[] 与可选 variant 一一对应launch.variant 与最终 session 绑定一致准备页地图预览 V1 已进入前端实现,因此 backend 当前应稳定提供:
preview.modepreview.baseTilespreview.viewportpreview.variants[].controlspreview.selectedVariantId当前前端策略是:
play.preview所以 backend 当前重点不是改前端展示,而是确保:
event detail / playbackend 当前可以默认前端已经稳定消费以下摘要:
status / canLaunch / currentPresentation / currentContentBundlelaunch.runtimelaunch.variantlaunch.presentationlaunch.contentBundleongoingSessionfinish(cancelled)也就是说,backend 当前新增字段时,优先考虑是否会影响以上已稳定消费链路。
当前阶段不建议 backend 现在优先去做:
/dev/workbench 继续膨胀成正式后台一句话:
现在要做的是生产闭环,不是万能后台。
backend 当前建议只盯这份最小执行清单:
play.canLaunch 与 launch 阻断语义一致assignmentMode 稳定进入发布物courseVariants[] 稳定进入发布物launch.variant 与最终 session 一致play.preview 稳定进入 event detail / playpreview.variants[] 与 variant 对齐backend 现在建议按以下顺序推进:
这样可以避免:
backend 当前应继续围绕“活动生产与发布平台”推进,而不是回到散装配置模式。
现在最该做的不是加更多零碎接口,而是做稳这三件事: