户外运动 / 骑行垂类赛道 — 骑行社区 + 工具平台
属于「互联网 + 体育健康」赛道，切入点是骑行这一垂直领域。目标用户群体是城市骑行爱好者、俱乐部骑手、专业训练者。
立项原因：
骑行在国内正在爆发式增长（城市绿道建设、共享单车培养用户习惯、健康生活方式意识提升），但缺乏一个集骑行记录、社交互动、训练管理、赛事运营、电商变现于一体的垂直社区平台。传统工具（如 Strava、行者）偏海外或工具属性过重，缺少社交和组织化功能。
解决的核心问题：
1. 骑行记录碎片化 — 骑行数据散落在不同 APP 中，无法集中管理和分析
2. 约骑组队困难 — 缺乏高效的约骑组织工具，报名、审批、成团全靠微信群沟通
3. 训练缺乏体系 — 骑行爱好者和业余选手缺少科学训练计划和能力评估
4. 社区互动薄弱 — 骑行成果缺乏展示和互动平台
5. 骑行生态闭环缺失 — 从骑行到装备购买、保险、赛事参与，各环节割裂
1. 用户模块（User）
微信授权登录/注册（openid 绑定 + 手机号）
个人信息编辑（昵称、头像、性别、城市、车型、骑行等级）
实名认证（姓名 + 身份证正反面）
紧急联系人管理
用户关注/粉丝体系
用户能力画像（总里程、总爬升、总时长、总次数、耐力/冲刺/爬坡/恢复四项能力值）
2. 轨迹模块（Track）
GPS轨迹录制与上传（含轨迹点序列批量保存）
难度自动计算（距离×0.3 + 爬升×0.5 + 路面类型加成）
轨迹点赞/收藏/评论/浏览计数
路线库（Route + RouteNode）— 经典路线推荐与收藏
创意轨迹大赛 — 参赛投稿、投票、评选获奖
轨迹审核（后台内容安全管控）
3. 约骑组队模块（Group Ride）
创建约骑活动（出发时间、路线、车型要求、难度等级、最少/最多人数、报名截止时间）
报名/审批流程（团长审核制）
自动成团机制（达到最低人数自动 CONFIRMED，超时人数不足自动 FAILED）
成员管理、活动日志完整流水
活动日历
SOS 紧急求救记录
团长信息批量填充（一次查询、批量赋值，避免 N+1）
4. 训练模块（Training）
训练目标管理（目标类型、目标值、截止日期、进度百分比自动计算）
训练计划模板 → 自动生成周计划 + 每日任务
每日打卡签到 → 连续签到阶梯奖励（3天+10分、7天+15分）
连续签到天数回溯计算
能力雷达图数据（骑行后自动更新）
5. 社交模块（Social）
成就系统：10 种成就（首次骑行、10次、100km、1000km、万公里、爬坡王、百公里单次、夜骑、创意之星、连续30天签到），条件判断自动解锁 + 积分奖
6. 积分模块（Points）
7. 商城模块（Mall）【预留】
8. 系统管理模块（System）
1. 骑行后事件驱动链
2. 成就系统的条件引擎
3. 约骑组队的有限状态机
4. 批量查询避免 N+1 问题
5. AOP 声明式权限控制
项目实现难点
1. 并发安全
约骑报名：多人同时报名同一活动时需要校验人数上限，当前通过 MyBatis-Plus 的 `updateById`（行级 WHERE id=）依赖数据库行锁，但缺少显式的 `SELECT ... FOR UPDATE` 悲观锁或版本号乐观锁保护，在高并发场景下存在超卖风险（`currentMembers >= maxMembers` 检查后到插入之间有时间窗口）。
- 积分消费：version 字段已定义但未在 WHERE 条件中使用（`updateById` 只匹配 id），乐观锁形同虚设。
2. 事务颗粒度
多个 `@Transactional` 方法内包含大量业务逻辑（如 `saveTrackWithPoints` 包含批量插入轨迹点 + 能力更新 + 积分发放 + 成就检查），事务持有时间较长，在数据量大时可能造成锁竞争。
3. 轨迹数据处理
骑行轨迹通常包含数千个 GPS 坐标点，当前采用 `batchInsert` 一次写入，这是正确的做法。但前端上传时如何压缩/分包传输、后端如何做数据平滑/降噪，是轨迹类应用常见的难点——当前代码尚未看到这部分处理。
4. 微信生态对接
微信登录涉及 openid 换取、手机号解密（加密数据 → AES 解密 → 纯手机号），小程序端和后端需要配合完成安全闭环。当前代码有相关实体和 DTO（`LoginDTO` 含 phoneCode），但实际解密逻辑用了 mock 实现。
5. 数据库设计复杂度
~60 张表的设计需要很好的领域建模能力。
评论