GitHub 不只是代码托管
很多人把代码托管站一个书签当全部，但真正常用的其实是围着它长出来的一圈站点：找项目、读 README、看构建状态、查依赖漏洞、看别人怎么组织仓库。这些站点我单独放一组，是因为它们的用途是判断一个开源项目值不值得用，而不是存代码，和文档组、工具组都不重叠。
这一组和文档组还有个区别：文档查的是确定的答案，这里查的是状态和信号。最近一次提交、维护者回不回 issue、有没有大量破坏性变更，全是软信息，得凑齐几条才能下结论，所以入口要集中，别临时靠搜索现找。
留在书签栏的入口
- Trending 与 Topics 页：看某语言当周在冒头的项目，比订阅一堆资讯号更贴近实际生态。我一般按语言过滤，只看 PHP 和 Go 两栏，全语言榜太杂。
- pkg.go.dev 与各类包索引：查一个库的公开 API、版本历史和被谁依赖，README 里通常不会写这些，而它们恰恰是判断能不能长期用的依据。
- Awesome 系列清单仓库：进入一个陌生领域时当目录用。它的问题也是优点，收得太全，所以只拿来定位关键词，不照单全收。
- 官方文档与 Actions 市场：写工作流时查 action 的输入参数和版本，比翻别人仓库里的配置文件靠谱，版本对不上时尤其如此。
- 包健康与漏洞页：看维护活跃度、未修复漏洞、许可证类型，决定要不要把一个依赖引进项目，商用场景下许可证这一栏要先看。
我留着这些站点的理由可以归结成一句话：README 是项目作者想让你看到的，而这些站点告诉你项目实际是什么状态。最近一次提交在两年前、issue 堆积、只有一个维护者、许可证和我的集成方式冲突，这些信息全在 README 之外。少看一条，可能就是半年后一次痛苦的迁移。
怎么快速判断一个项目
我的固定顺序是：先看最近提交时间和发布频率，再看 issue 里维护者回不回话，然后去包索引看 API 是否稳定、有没有连着好几个破坏性版本，最后才读 README 和快速开始。这个顺序能让我在五分钟内筛掉大部分星标很高但已经没人管的仓库。真要引进依赖时，我还会顺手看一下它的依赖树，一个只做小事却拖进十几个间接依赖的库，维护成本往往比自己写还高。
还有个小技巧：把仓库的依赖关系页和网络图存成书签模板，换一个仓库名直接改地址就能查。看谁在生产里依赖它，比看星标数有说服力得多。另外星标我只当热度参考，一个被某大项目依赖的小工具，往往比一个万星但零维护的库更值得进技术选型。
这一组我每季度清一次，删掉那些已经归档、转收费、或者被官方取代的入口。生态站点的半衰期比想象中短，书签栏也得跟着新陈代谢。