# Backend Docs
> 文档版本：v1.0
> 最后更新：2026-04-02 08:28:05


这套文档服务两个目的：

1. 让后面开发时能快速查到当前后端边界
2. 把“配置驱动游戏”的核心约束写清楚，避免业务层和游戏层重新耦合

## 建议阅读顺序

1. [系统架构](D:/dev/cmr-mini/backend/docs/系统架构.md)
2. [核心流程](D:/dev/cmr-mini/backend/docs/核心流程.md)
3. [API 清单](D:/dev/cmr-mini/backend/docs/接口清单.md)
4. [数据模型](D:/dev/cmr-mini/backend/docs/数据模型.md)
5. [配置管理方案](D:/dev/cmr-mini/backend/docs/配置管理方案.md)
6. [资源对象与目录方案](D:/dev/cmr-mini/backend/docs/资源对象与目录方案.md)
7. [后台管理最小方案](D:/dev/cmr-mini/backend/docs/后台管理最小方案.md)
8. [前后端联调清单](D:/dev/cmr-mini/backend/docs/前后端联调清单.md)
9. [TodoList](D:/dev/cmr-mini/backend/docs/todolist.md)
10. [开发说明](D:/dev/cmr-mini/backend/docs/开发说明.md)

## 当前系统范围

当前 backend 已覆盖：

- 多租户入口识别
- APP 短信登录
- 微信小程序登录
- 手机号绑定与账号合并
- 首页卡片与入口聚合
- Event 详情与 play 上下文
- 以 `event_release` 为核心的 launch
- session 生命周期
- session 结果沉淀
- 开发 workbench

下一阶段建议重点：

- 可伸缩配置管理
- 共享资源对象化
- source/build/release 分层
- 配置构建器
- 发布资产清单

## 当前最重要的设计约束

- 用户是平台级，不是俱乐部级
- 渠道是入口，不是用户体系
- `event` 是业务对象，不是运行配置本体
- `event_release` 才是进入游戏时真正绑定的配置发布对象
- `game_session` 必须固化当时实际使用的 release

## 代码入口

- 程序入口：[main.go](D:/dev/cmr-mini/backend/cmd/api/main.go)
- 应用装配：[app.go](D:/dev/cmr-mini/backend/internal/app/app.go)
- 路由注册：[router.go](D:/dev/cmr-mini/backend/internal/httpapi/router.go)
- migration：[migrations](D:/dev/cmr-mini/backend/migrations)