开源项目进展；3个假进度信号最坑人

star 破万、issue 一天几十条、版本号一个月跳三回，这种仓库主页看着热气腾腾。你把代码拉下来跑一遍可能就发现：核心逻辑三个月没人动过，两年前的 bug 还挂在那儿。开源项目进展这件事最容易被表面热闹骗过去。热闹是流量，是别人点了一下收藏；进展是代码，是有人真的往里写东西、修东西、把版本推出来。这两样经常不在一根线上。

开源项目进展别只数 star

star 这东西本质上就是个收藏夹。我自己浏览器收藏夹里躺着几百个仓库，一个都没部署过，点 star 的时候想的是「以后可能用得上」，然后就没有以后了。一个项目 star 涨得快，可能是被谁转发了一次，可能上了趋势榜，也可能只是 README 写得好看。它跟「有没有人在修 bug」基本无关。所以判断开源项目进展，第一步该看的是主干上最近有没有人往里写东西，而不是有多少人点了那颗星。

假信号一：提交记录刷得比谁都勤

看 commit 曲线最容易上当。有的仓库一天几十个提交，绿格子铺满一整年，你打开 diff 一看，全是改空格、调 README 换行、把版本号从 1.x 挪到 1.y。还有一类更隐蔽，依赖机器人自动提 PR，合并一多，图表亮得像圣诞树，实际上人一行没写。

我一般只翻主分支最近三四周的提交，挨个看 diff 落在哪几个文件、动了什么逻辑、有没有跟着改测试。删掉注释里的错别字不算进展，把示例代码的缩进统一了也不算。见过提交曲线常年满格的工具库，装上最新版，老问题原样还在。那种就是进度条画得漂亮，路其实没挪。

假信号二：issue 满屏，关掉的没几个

issue 数量是能刷出来的：模板提问、来求 star 的、机器人自动开的、同一个问题换个人再问一遍。开得多不代表有人在干活，得看关闭比例和维护者的回复质量。有的项目回复很客气，「感谢反馈，我们会评估」，然后就没有然后了，一年后那条还挂在第一页。

还有个常见毛病是把 issue 当许愿池，新需求天天进，老 bug 一直躺着。我的土办法是搜一下最近关掉的那些，看关闭理由是「已修复」还是「重复」「不打算做」。修复和拒绝都算有人在管，全是「待处理」才是真的没人管。

假信号三：版本号跳得欢，包还是那个包

release 页一个月好几版，看着特别勤快。你下载前后两版对比一下，实质变化可能只有版本号那一行。CHANGELOG 通篇「更新依赖」「修复若干小问题」「优化使用体验」，没有一条对得上具体文件。这种日志读完了你还是不知道自己升级之后会碰上什么。

看 CHANGELOG 有个笨办法：能不能从中读出「我这次升级要改什么、会坏什么」。读不出来，那它就是装饰品。还有些项目预发布版本发得特别勤，正式版遥遥无期，那种节奏更像是给关注者看的，不是给使用者用的。

roadmap 画得漂亮，也是一种进度幻觉

时间线、里程碑、季度规划，一张图讲得清清楚楚。可 roadmap 不是承诺，改期也不犯法。判断方式很土：看每个里程碑下面有没有挂着对应的 issue 和 PR，挂着的才算在推，只有一行字的算许愿。有的路线图上写着「即将支持某某」，那个「即将」已经即将了很久，图本身两年没更新过。

文档先行也是同一类幻觉。README 里把还没做的功能写得跟已经做完一样，社区群里天天有人问「什么时候上」，气氛热得不行。但热的是讨论，不是代码。群聊热度、fork 数、周报里的漂亮话，都不能替代主干上那几次实实在在的合并。

我自己的一套检查顺序

顺序不固定，但大致这么走：先翻主分支最近一个月提交的性质，再看 release 和 CHANGELOG 有没有实质条目，接着看 issue 的关闭率而不是数量，然后本地拉下来按文档装一遍，看写的和跑出来的是不是一回事。

再往下就该扫依赖列表了，有没有长期没人维护、被公开披露过问题的组件。这条跟网站安全直接挂钩，你要是拿它顶着线上业务跑，出了事是自己兜，没人替你兜。同时看一眼下载渠道，镜像和 CDN 分发正不正常，CI 拉包会不会卡住。发布渠道长期没人打理的项目，往往也就那么回事儿。

真进展通常不怎么响

真正在往前走的项目大多安静。一周几个不大的提交，CHANGELOG 每条都看得懂，维护者敢拒绝需求、敢直说这个不做，发版之前测试跑过一遍。慢，但在挪。你甚至能从贡献者名单里看出点东西：如果一两年下来只有一个人偶尔提交，其余全是一次性路过，那它的抗风险能力也就那样，那个人忙起来项目就停。

反过来，一个项目如果主要靠发布会、徽章和几句口号撑着，它的进展大概率停在 PPT 上。别急着上生产，先用一台便宜的云服务器把最小功能跑通，跑不动的话，再热的话题也跟你没关系。

选开源项目跟相亲差不多，照片再好看也得见一面。花半小时按上面几条翻一遍，比看十篇推荐文管用。真拿不准就先放一放，仓库又不会跑，等它出下一个正式版再说。