题目重点：从球队/赛事与用户信号生成附近候选，设计偏好排序、冷启动、距离和组件级规模化。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版推荐目标是帮助用户发现能关注的本地球队，不把体育新闻点击率等同球队推荐成功。
- 球队主数据含地点、联赛、赛季、有效状态；用户位置可粗粒度授权、城市默认或手选，不能要求精准 GPS 才服务。
- 排序目标暂以关注/赛程订阅等显式行动为主指标，加入多样性、距离、覆盖和隐私护栏；题目没有指定权重。
解题路线
- 数据产生：摄取官方/合作方球队和赛程目录，去重 teamId、校验城市/场馆位置与赛季；用户侧收集明确同意的喜欢运动、关注队伍、互动和地点信号并保留采集时间。
- 候选召回先按城市/邻近区域及球队活跃状态过滤，再混入热门本地球队、用户喜欢运动相关队伍和可探索候选；冷启动用手选运动及地区热门。
- 排序用距离、运动匹配、关注关系、近期赛程、历史互动等特征，避免未来行为泄漏；离线以时间切分评估 top-k 相关性，线上看关注/留存及隐藏、不感兴趣反馈。
- 对候选召回、特征服务、排序、内容详情分别估容量：主数据缓存与地理索引可复用，热点城市候选预计算，用户实时特征短 TTL；排名降级到城市热门列表。
- 新闻推荐扩展需独立内容 freshness、去重和版权/来源检查；一个球队有很多新闻，不应直接挤占候选球队多样性。
手动走一遍
新用户只选择 Seattle 与篮球：先从当地有效篮球队召回，同时给少量邻近候选；不应因为缺浏览历史返回空列表。已关注某队的用户若目标是发现新球队，可降低已关注队排名，展示相关联赛新队；若目标是内容 feed，则策略相反。
规模与取舍
设本地区候选 T、用户数 U、特征维度 F：候选扫描 O(T) 或索引查询约 O(log T + K)，精排 K 个候选成本依模型而定；用户特征 O(UF) 或稀疏存储。规模化前须拿实际 QPS、城市分布和时效目标，题目未明确数值。
易错点与追问
容易失分的边界
- 只说协同过滤，却未解释新用户和新球队。
- 把用户精确定位设为必需，忽略权限与位置不确定性。
- 只按点击优化而不断重复已有热门球队。
- 把 的体育新闻目标直接当成 的球队目标。
继续深挖
- 同城有多个同名球队或球队搬迁时如何维护 teamId？
- 位置不可用时怎样生成和解释推荐？
- 比赛日热点城市如何缓存候选而保留个性化？
- 如何避免少数热门队垄断曝光，又不损失相关性？
