说实话,一开始接到这个题目，我有点懵，Golang跟NBA全明星名单？这俩玩意儿能扯上关系？但转念一想，作为一个写了几年Go的程序员，同时又是个十几年的老球迷，这事儿好像还真有点意思，让我泡杯茶，慢慢跟你聊聊。
为什么Golang适合处理NBA全明星名单？
你可能会问,用Python不香吗？用JavaScript不也挺好？但问题在于，NBA历届全明星名单这个数据，它有几个特点：
第一，数据量大。 从1951年第一届全明星赛到现在，70多年、70多届比赛，每届东西部各12人（早期还更少），再加上伤病替补、特殊增补，这数据量说大不大说小不小，但结构挺复杂。
第二，格式不统一。 早期的名单记录方式跟现在完全不同，有些年份甚至只有手写档案，这时候，Golang的强类型和结构体就派上用场了。
第三，需要高性能查询。 你想啊，如果我想查“科比·布莱恩特参加过多少次全明星”，或者“勒布朗·詹姆斯跟哪些人当过队友”，这要是用个弱类型语言，处理起来不得卡半天？
我去年写过一个小工具，专门用来解析和查询NBA全明星历史数据，代码不长，但挺实用的，今天就用这个例子，边写代码边聊。
第一步：定义数据结构
在Golang里,我们得先定义好数据结构，这就好比盖房子先画图纸，得想清楚每届全明星赛需要记录哪些信息。
type AllStarGame struct {
Year int `json:"year"`
Season string `json:"season"` // "2023-24"
Location string `json:"location"` // 举办城市
MVP string `json:"mvp"` // 全明星赛MVP
EastTeam []Player `json:"east_team"`
WestTeam []Player `json:"west_team"`
}
type Player struct {
Name string `json:"name"`
Team string `json:"team"` // 当时效力的球队
Position string `json:"position"` // 位置
Selection int `json:"selection"` // 第几次入选全明星
}
这个结构看起来简单,但实际填充数据时问题就来了，早期全明星赛没有“东西部首发”这个概念，后来才有球迷投票，而且有些球员入选了但因伤没打，这在记录上怎么体现？
我当时的做法是加了一个 Status 字段："selected"（入选）、"played"（参赛）、"injured"（受伤）、"replacement"（替补入选），这样就能区分科比2010年因伤没打，还是奥尼尔1996年作为替补入选的情况。
第二步：数据采集与清洗
说实话,最痛苦的不是写代码，而是找数据，NBA官方虽然有历史数据，但API只覆盖最近几年的，早期的数据散落在各个百科网站上，格式五花八门。
我用Golang写了个爬虫,但爬下来的数据跟狗啃的一样，举个例子，1984年全明星赛的名单，有的网站写“Larry Bird (Celtics)”，有的写“Bird, Larry - BOS”，这要是用正则表达式去匹配，得写到吐血。
后来我想了个办法：先用Golang的encoding/csv包把数据人工整理成CSV，再用Go程序去校验和清洗。 比如写个函数检查“名字里有没有特殊符号”、“年份是不是在合理范围内”、“东西部人数是不是12对12”。
这里有个小技巧：用Golang的sync.Map来缓存已经处理过的球员记录，避免重复处理，迈克尔·乔丹”这个名字，在1985年到2003年间出现了14次，如果每次都要重新解析，效率太低了。
var playerCache sync.Map
func getPlayerInfo(name string) (Player, bool) {
if p, ok := playerCache.Load(name); ok {
return p.(Player), true
}
// 否则从数据库查询
// ...
}
第三步：构建历届全明星名单数据库
数据清洗完了,就该往数据库里塞了，我用的是SQLite，轻量级，而且Golang有现成的驱动go-sqlite3，表结构大概是这样的：
CREATE TABLE all_star_games (
year INTEGER PRIMARY KEY,
season TEXT,
location TEXT,
mvp TEXT
);
CREATE TABLE players (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT,
team TEXT,
position TEXT,
selections INTEGER
);
CREATE TABLE game_roster (
game_year INTEGER,
player_id INTEGER,
conference TEXT, -- 'East' or 'West'
status TEXT, -- 'starter', 'reserve', 'replacement'
FOREIGN KEY (game_year) REFERENCES all_star_games(year),
FOREIGN KEY (player_id) REFERENCES players(id)
);
你可能会问,为什么不用NoSQL？因为全明星数据的关系性很强：球员属于某一年比赛，比赛有东西部之分，球员之间有队友关系，用SQL做联表查询，效率杠杠的。
比如查“勒布朗·詹姆斯在哪些年份跟德维恩·韦德做过全明星队友”，一句SQL就搞定了：
SELECT a.year FROM game_roster a JOIN game_roster b ON a.game_year = b.game_year WHERE a.player_id = (SELECT id FROM players WHERE name = 'LeBron James') AND b.player_id = (SELECT id FROM players WHERE name = 'Dwyane Wade') AND a.conference = b.conference;
第四步：API接口开发
数据库建好了,得让它能用啊，我用Gin框架写了几个API接口：
GET /api/games/{year}：获取某一年全明星赛的详细信息GET /api/players/{name}：获取某个球员的所有全明星记录GET /api/statistics：统计类数据，入选全明星次数最多的球员”、“最年轻的全明星MVP”等
这里有个坑：Golang的JSON序列化默认会把空值变成null，比如某个球员没有“位置”信息，传回前端就是个null，前端处理起来很麻烦，我加了个自定义的MarshalJSON方法：
func (p Player) MarshalJSON() ([]byte, error) {
type Alias Player
return json.Marshal(&struct {
Position string `json:"position"`
*Alias
}{
Position: if p.Position == "" { "Unknown" } else { p.Position },
Alias: (*Alias)(&p),
})
}
这样哪怕早期数据不完整,至少不会返回null。
第五步：一些有趣的发现
数据建好后,我自己先玩了一把，用Golang写了几个查询脚本，发现了一些有意思的事情：
-
入选全明星次数最多的球员：勒布朗·詹姆斯（19次）、卡里姆·阿卜杜尔-贾巴尔（19次）、科比·布莱恩特（18次），但科比有2次因伤没打，如果只算实际参赛的，勒布朗是唯一超过18次的。
-
最年轻的全明星MVP：1986年，伊塞亚·托马斯（25岁），等等，你可能以为是勒布朗或者科比？勒布朗第一次拿全明星MVP是2006年，已经21岁了，年轻”的定义很重要。
-
东西部战绩对比：1951年到2023年，东部赢了37次，西部赢了36次（有一次平局？不，那是2003年，迈克尔·乔丹最后一次全明星，加时赛后西部赢了），这个数据让我有点意外，原来东部赢的次数更多？
-
全明星赛的“熟人圈”：有些球员在不同年代都跟同一拨人做过队友，比如蒂姆·邓肯和托尼·帕克，从2003年到2016年，连续14年同时入选全明星，这大概就是马刺系的传承吧。
关于代码的一点感悟
写这个项目的时候,我一度想放弃，数据太乱了，早年的记录连“全明星首发”这个概念都没有，1951年第一届全明星赛，连电视转播都没有，你能想象吗？我查到的名单是这样的：
1951年全明星赛，波士顿花园球馆
- 东部：鲍勃·库西（凯尔特人）、多尔夫·谢伊斯（锡拉丘兹民族）、埃德·麦考利（凯尔特人）... 一共12人
- 西部：乔治·迈肯（明尼阿波利斯湖人）、吉姆·波拉德（明尼阿波利斯湖人）、亚历克斯·格罗扎（印第安纳波利斯奥林匹亚）... 也是12人
你看,那时候的球队名字都跟现在不一样。“明尼阿波利斯湖人”就是后来搬到洛杉矶的湖人队，“锡拉丘兹民族”就是后来的费城76人队，这些历史知识，要是不懂篮球的人来处理数据，绝对会搞混。
但这就是Golang的魅力所在。 它不会替你处理这些逻辑，但它给你足够精良的工具，让你自己把逻辑写清楚，结构体、接口、并发，这些东西组合起来，就能把最混乱的数据变得井井有条。
一点小遗憾
目前这个项目只覆盖了1951年到2023年的全明星赛数据,2024年的还没加进去，主要是因为我懒（笑），而且2024年的全明星赛改成了“东西部队长选人”的模式，数据结构又要改，Golang的灵活性在这种时候就体现出来了：我只需要在AllStarGame结构体里加一个DraftType字段就行了，其他代码几乎不用动。
有些年份的数据我实在找不到准确来源,比如1969年全明星赛，有资料说比尔·拉塞尔入选了，但又有资料说他根本没参加，我最后采用了NBA官网的数据（那个年代官网可能存在吗？其实NBA官网有历史数据库，叫“NBA Encyclopedia”这个文献可以参考），Golang的testing包帮了大忙，我写了一大堆单元测试来验证每条数据的准确性，全明星赛MVP必须来自获胜球队”——这个规则在2000年之前是成立的，但1998年迈克尔·乔丹全明星赛MVP，那年东部赢了，2003年凯文·加内特，西部赢了，都符合规则，但2002年科比·布莱恩特，西部输了？不，那年西部赢了，所以规则一直成立。
你可能会说,这跟Golang有什么关系？关系大了。用强类型语言处理数据，逼着我把所有边界情况都想清楚。 如果我是用Python写，可能就偷懒用dict糊弄过去了，碰到“MVP来自输球球队”这种异常数据，程序运行时才会报错，但在Golang里，编译过不了。
最后聊两句
这篇文章写到这里,感觉有点跑题，本来想聊NBA全明星名单的，结果一直在说Golang，但转念一想，这不正是生活吗？你以为你在学编程，其实你在整理数据；你以为你在整理数据，其实你在回顾篮球历史。真正的学习从来不是线性的，而是像Golang的协程一样，看似并行实则交织。
好了,代码也写了，数据也聊了，如果你也想用Golang折腾点什么历史数据，全明星名单是个不错的练手项目，代码我放在GitHub上（虽然README还没写完，数据库也没放全），感兴趣可以自己改着玩。
就这样吧,我得去更新2024年的数据了。哦对了，2024年全明星赛，勒布朗·詹姆斯还是首发，这哥们儿打了20年还在打，离谱。
本文来自作者[kyadmin]投稿，不代表ac米兰官网立场，如若转载，请注明出处：http://www.milanomuse.com/nba/84.html
评论列表（4条）
我是ac米兰官网的签约作者“kyadmin”！
希望本篇文章《用Golang写一篇关于NBA历届全明星名单的非典型文章》能对你有所帮助！
本站[ac米兰官网]内容主要涵盖：AC米兰,ac米兰中文,AC米兰官网
本文概览：说实话,一开始接到这个题目，我有点懵，Golang跟NBA全明星名单？这俩玩意儿能扯上关系？但转念一想，作为一个写了几年Go的程序员，同...