GitHub 上这 10 个开源项目，我用过之后就没删过收藏
三年前我刚开始学编程的时候，有个坏习惯：看到一个项目 Star 数高就 Star，看到一个"awesome"就收藏。半年之后我打开收藏夹，几百个项目，说得上真正用过的不超过五个。
那种感觉很普通——收藏了很多，但实际没改变什么。
后来我换了个思路：不再追着 Star 数跑，而是问自己"这个东西有没有真的帮我省过时间、解决过问题"。从这个角度出发再去看 GitHub，视角完全不同。
所以我回头翻了一遍自己这几年真正用过的项目，挑了 10 个出来。它们不全是 GitHub 上 Star 最多的，但每一个都是我经历过"发现它 -> 开始使用 -> 成为习惯"这个过程的。
freeCodeCamp：我见过最认真的免费编程课
先说不意外的：freeCodeCamp，377K+ Star，全球最大编程学习社区。
它为什么不出意外？因为它确实是目前免费编程教育的天花板，不是之一。
几年前我有个朋友想从传统行业转行前端，预算有限，不想报培训班。我让他去 freeCodeCamp 试三个月，没给任何其他建议。三个月后他把整个前端路径做完了——React、Node.js、MongoDB，每门课都带着实战项目。他后来拿到了几家的面试，成功入职了一家中小公司。
我并不是说 freeCodeCamp 能替代一切，它的课程偏重前端和全栈，算法部分相对薄弱，UI 教学也算不上前沿。但它做对了最重要的一件事：不是让你看视频，而是让你上手写代码。
每学一个概念，当场就有练习题。每个模块结束，有五个必须独立完成的实战项目才能拿到证书。这种"强制输出"的设计，比任何方法论都有效。
适合谁：零基础转行者、想系统练编程但预算有限的人。
不一定适合谁：已经有经验、只想快速了解某个新技术的开发者。
hello-algorithm：看动画学算法，真的可以
70.5K+ Star，这个项目有个中文名叫《算法图解》。
我第一次用它是大二准备面试的时候。那时候刷 LeetCode 刷得很痛苦，题目刷了五十道，但总觉得没形成体系，换一道类似的又不会了。一个学长推荐了 hello-algorithm，说"你先把这个看完再刷题"。
我花了两周把所有动画看了一遍，从复杂度分析到动态规划，每个算法都有动图演示，旁边配多语言代码实现。看完之后再去刷 LeetCode，感受完全不一样了——以前是背题，现在是看到题目能反应过来"这个可以用贪心""那个是 DP 状态转移"。
它最大的优点是降低了理解算法的心理门槛。很多人学算法卡住，不是智商问题，是抽象概念没法在脑子里建立直观画面。这个项目就是专门解决这个问题的。
适合谁：算法入门阶段的人、准备面试但刷题刷不出体系感的人。
不适合谁：已经在大厂刷了 500+ 题的高阶选手——它太基础了，对你来说信息密度不够。
awesome：你找不到资源，只是没搜对这个词
264K+ Star，一个"列表的列表"。
说来惭愧，我第一次知道 awesome 系列是在用了 GitHub 两年以后。那时候我在找一个 Python 的异步爬虫框架，在搜索引擎里翻了半天各种博客，推荐的五花八门，不知道该信谁。后来一个同事说："你去 GitHub 搜 awesome-python"。
打开一看，排序好的分类、每个库一句话的介绍、Star 数标注。十五分钟就选好了。
它做的事情本质上很简单：让有经验的人帮你做过一轮筛选。 你不需要从零开始了解一个领域的生态，直接跳到"大家都知道比较好的东西"这个集合里，再根据自己的需求深入。
awesome-python（160K+）、awesome-go、awesome-machine-learning……这些子项目都值得单独 Star。也有不那么主流的，比如 awesome-interview-questions，里面按领域整理了常见面试题，面试前一周扫一遍，效率很高。
什么时候用：进入一个新语言/新框架的时候，先搜 awesome-xxx，之后再去看具体的技术选型文章。
VS Code：我反而推荐你去看看它的源码
154K+ Star，微软出的代码编辑器，这个不用我介绍，可能每个读到这篇文章的人都在用。
但我想说的不是"用 VS Code"这件事——而是看它的源码。
VS Code 是我见过的最适合学习的大型开源项目之一。它用 TypeScript 写成，工程化程度非常高：清晰的模块边界、完善的测试、详细的贡献指南。如果你在工作中写 TypeScript，看过 VS Code 的代码之后，对你自己项目的架构设计会有直接的启发。
我的实际经历：有段时间我在做一个 Electron 桌面应用，遇到了主进程和渲染进程通信的问题。搜了很多教程都讲得模模糊糊，后来直接去看 VS Code 怎么处理同样的问题的一瞬间，看它的 IPC 封装层设计，直接解决了我的困惑。
至于插件推荐，网上太多了，不展开。我只说一个容易被忽略的插件：GitLens。它能让你在代码每一行旁边看到"这行代码是谁在什么时候写的、为什么写的"。在团队协作里，这个插件救过我很多次。
核心建议：用起来不稀奇，真正有价值的是深入研究它——看架构、看插件系统、看贡献流程。
the-art-of-command-line：命令行这件事，专门学一遍是值得的
140K+ Star，一个专门讲命令行技巧的仓库。
这是我见过最"看标题觉得没必要、看完觉得相见恨晚"的项目之一。
我做开发的第一年，对命令行的理解就是 cd、ls、git add、git commit。后来有一次 SSH 进服务器排查问题，看到一个同事操作命令行像弹钢琴一样流畅——用 awk 一行命令处理了一个两百行的日志文件，用 xargs 批量重命名了一堆文件，整个过程不超过两分钟。
我站在旁边看着，有一种很强烈的感觉：同样的事情我可以做，但要花十倍的时间，因为我不知道有这些工具。
后来去读了 the-art-of-command-line，里面有中文版本。不是一本正经的命令手册，而是按场景组织的——"你需要批量处理文件""你需要分析日志""你需要监控系统状态"——每个场景给最实用的命令。看完之后，我开始在日常工作中有意识地用命令行替代 GUI 操作，效率提升是真实的。
一个最直接的收益：学会命令行之后，你可以脱离 IDE 和图形界面做任何事。服务器、Docker 容器、远程环境——这些地方往往只有终端可用。
996.ICU：一个代码仓库背后的真实处境
268K+ Star，一个和编程技术完全无关的项目。
我犹豫过要不要把它放进来。但它确实是这 10 年里中国开发者对 GitHub 影响最大的项目之一，也是让很多人第一次意识到"开源不只是代码"的事件。
2019 年，一个开发者在 GitHub 上发起了 996.ICU 项目——"996 工作制，生病进 ICU"。短时间内它冲到了 GitHub Star 增长历史第一，背后是中国几百万程序员对加班文化的集体回应。项目里有黑名单（实行 996 的公司）和白名单（正常作息的公司）。
它对技术人有什么实际价值？
从功利的角度说，名单本身信息量很大。你拿到一个 offer 不知道这家公司怎么样，去名单里搜一下。这个比招聘网站的评论真实得多，因为是匿名的、集体维护的。
但它更深的价值在于提醒我们：工具和技术是为生活服务的，不是反过来。在做职业选择的时候，薪资只是一个维度，工作环境、节奏、对人的长期消耗，值得认真衡量。
这个项目我把它放在这里，不代表我支持或反对某个具体制度。我只是觉得，作为一个开发者社区的集体记忆，它值得被记住。
public-apis：做 Demo 再也不用担心没数据了
248K+ Star，超过 1000 个免费 API 的汇总。
有一段时间我在准备一个前端作品集会，想做几个有真实数据的应用——天气查询、电影搜索、汇率换算——但没有后端，不想自己搭服务器。
public-apis 救了我。
这个仓库按类别整理了各种免费 API：天气、新闻、金融、游戏、AI……每个 API 标注了是否需要注册、是否支持 HTTPS、是否支持 CORS。你对着列表，花十分钟就能找到合适的接口，直接用 fetch 调就能跑起来。
我在实际项目里用过的几个：
- OpenWeatherMap：免费天气 API，做一个天气应用 Demo 足够了
- Unsplash API：免费图片搜索，作品集项目里配图全靠它
- CoinGecko API：加密货币行情，做数据可视化练手很好用
- REST Countries：国家基础信息，搭一个"世界百科"小项目绰绰有余
有一个使用建议：联系 API 之前先看一眼项目的 GitHub 地址和最近更新时间，确认它还在维护。public-apis 列表里偶尔会有已经停服的标注不及时的情况。
nvm：Node 版本管理的救星
74.5K+ Star，一个解决了一个特定但普遍问题的工具。
这个问题是什么呢？你开发 A 项目需要 Node 16，B 项目需要 Node 18，你又想用最新的 Node 20 玩点新东西。每次切项目前要先卸载重装 Node？这绝对是种折磨。
nvm 就是解决这个的。装完之后，你想要的任何 Node 版本都可以在三行命令之内切换：
nvm install 18
nvm use 18
nvm alias default 18
更深一层的用法：在你的项目根目录加一个 .nvmrc 文件，里面只写版本号 18，进目录的时候运行 nvm use 就会自动切换到正确版本。这个细节在团队协作里非常有价值——每个人的本地环境不必完全一致，但每个项目可以约定统一版本。
我用 nvm 踩过的唯一一个坑：Mac 上装了 nvm 之后，再用 npm install -g 装的包，切换 Node 版本后会找不到。原因是全局包是按版本隔离的。解决方法很简单——换版本后重新装一下常用的全局包，或者用 nvm reinstall-packages 命令迁移。
一句话：如果你在用 Node.js，没有理由不装 nvm。
gitignore：你可能还没有一个说得过去的 .gitignore
155K+ Star，一个"看起来很小但能避免大问题"的项目。
我见过有人在 Git 仓库里提交了 node_modules，整个文件夹被推上去，CI 构建直接超时。也见过 .DS_Store 文件满天飞、IDE 配置文件、编译产物全部进了版本库的情况。
这些问题出现的原因都一样：.gitignore 文件没写好，或者根本没写。
GitHub 上的 gitignore 仓库收录了几乎所有语言、框架、IDE 和操作系统对应的模板。使用方法只有一个：新建项目的时候，找到你的技术栈对应的模板，复制内容到你的 .gitignore，完事。
几个常见的坑：
- 模板要匹配你的技术栈：用 Python 项目却复制了 Java 的模板，照样会有无关文件漏进去
- 全局 .gitignore：有些文件是操作系统或 IDE 层面的（比如 macOS 的
.DS_Store、Windows 的Thumbs.db），你可以配置一个全局.gitignore文件，一劳永逸 - 已经提交进 Git 的文件不会被忽略：如果你的
node_modules已经被提交了，加.gitignore没用。需要先运行git rm -r --cached node_modules把它从版本控制中移除
虽然是个小工具，但它能帮你维持一个干净的仓库。仓库整洁度这个事，表面上不影响功能，实际上影响协作效率和代码审查体验。
spoon-knife：第一个 PR，从这里开始
12.3K+ Star，和其他几个项目比起来 Star 数不算高。但它的价值不在于本身，在于它是一扇门。
spoon-knife 是 GitHub 官方推荐的新手练习项目。它是专门为从没提交过 PR 的人设计的——整个项目的内容只有一个 README，贡献方式很简单：往里面加一行你的信息。
但它的意义不是这行信息，而是让你走完整个开源贡献流程：
- Fork 项目到自己的账号
- Clone 到本地
- 创建新分支
- 做修改、提交
- 推送到自己的 Fork
- 提交 Pull Request
- 等待代码审查和合并
这个流程，对一个完全没有 GitHub 经验的人来说，是有一定认知门槛的。我曾经帮过两个刚学编程的朋友完成他们人生中第一个 PR，用的都是 spoon-knife。他们的反馈差不多："原来 GitHub 协作是这样的。"
如果你想参与开源但不知道从哪开始，先从这里走一遍流程。等熟悉了 Fork -> Branch -> PR 的路径，再去找真正的开源项目贡献代码，就不会手足无措了。
最后：如何选择适合自己的开源项目
回到开头说的问题——收藏了一堆，真正用上的没几个。我自己的解决方案是三个问题：
1. 这个东西能帮我解决当前的实际问题吗？ 如果不能，再好看也先放着。
2. 我愿意花多少时间搞清楚它？ 有些项目入门成本高，需要几天才能上手；有些十分钟就能用上。先找时间成本低的，快速获得正反馈，再深入高门槛的。
3. 六个月后我还会用它吗？ 问这个问题是在逼自己想清楚：这是一时新鲜，还是真的需要。
GitHub 上好的项目是无限的，但你的时间和注意力是有限的。选少一点，用深一点。
如果这篇文章只让你记住一件事，我希望是这个：Star 数可以参考，但真正衡量一个项目价值的标准，是你有没有因为它而改变了自己的工作或学习方式。
那才是真正的"收藏"。