收藏夹里躺着三百多个 GitHub 链接真正常打开的不到二十个这是我两年前清理浏览器书签时的真实发现。那次清理让我意识到一件事收藏本身不产生价值收藏之后的分类、试用、淘汰才产生价值。GitHub 上每天都有新仓库冒出来其中有大量有意思的地址——有的是能当教材啃的学习仓库有的是装完就回不去的效率小工具有的是纯粹为了好玩、看完会心一笑的项目还有一些是被反复转发的资源聚合站。问题不在于找不到而在于找得太多、存得太乱、用得太少。这篇内容就是把我这些年攒下来的收藏链接做一次系统整理同时把怎么把这些链接真正用起来这件事讲透。我会按用途把仓库分成几大类每一类说清楚它能解决什么问题、哪些值得留、哪些可以先跳过也会把访问、下载、部署、评估这些绕不开的实操细节拆开讲包括镜像站的取舍、Release 包和源码包的区别、404 和 403 这类报错的排查顺序。不管你是刚注册账号、连仓库首页都没点进去过的新手还是已经会写 Actions 的老手应该都能从里面挑到几条能马上用上的东西。下面正式开始。1. 先想清楚收藏链接这件事到底解决什么问题1.1 收藏夹为什么会变成数字垃圾场大部分人的收藏行为是被动的刷到一条推荐、看到别人转发、搜问题顺手点了个星标然后就再也没有然后了。这种收藏方式有三个致命问题。第一是没有入口存进去的链接没有和任何具体场景绑定等到真需要用的时候你根本想不起来自己曾经存过它。第二是没有淘汰机制三年前的工具早就停止维护了可它还挂在你列表里下次你再点进去看到的是两年前的 README白浪费十分钟。第三是分类维度错了很多人按语言或者技术栈分类结果一个前端工具、一个后端框架、一个命令行小玩具全塞进工具这一格格子越撑越大最后还是找不到。我后来的做法是把分类维度换掉改成按我什么时候会打开它来分。比如写文档的时候要用、截图发文章的时候要用、想学一个新东西的时候要用、纯娱乐无聊的时候翻这样四五个场景就够。场景是稳定的技术栈是变化的按场景分三年后你依然能凭直觉找到东西。这个思路后面几节的分类就是照着它来的。1.2 我筛选链接的三条硬标准不是每个看起来有意思的仓库都值得进收藏夹。我现在加链接之前会过三道关任何一道不过就直接放弃宁可少存也不存垃圾。第一条标准是最近一年内有实质提交。注意是实质提交不是改个 README 里的错别字、不是自动化的依赖机器人。判断方法很简单点进仓库首页看 commit 时间轴如果最近几个月的提交全是chore(deps)或者Bump version这类说明维护者基本不管了。这类项目不是不能用只是你遇到问题提交 issue 大概率没人理。第二条标准是有能看懂的上手路径。我指的是 README 里有没有一段让人五分钟内跑起来的内容可能需要安装什么、执行哪条命令、跑起来长什么样。如果一个项目的 README 通篇是愿景和截图唯独没有怎么装那它对我来说只能算资讯不算工具。这条对新手尤其重要你没必要为了一个玩具去啃三百行构建脚本。第三条标准是许可证清晰。这条最容易被忽略但踩过坑就知道疼。MIT、Apache-2.0 这类宽松协议基本可以放心用GPL 系列如果你要闭源分发就得注意还有一些项目干脆没写许可证那严格来说你连商用都不敢碰。我一般会在收藏备注里记一句许可证类型省得以后翻出来还要重新查。1.3 分类骨架把链接挂到使用场景上下面这张表是我目前用的分类骨架也是后面几节的展开逻辑。把它贴出来是想让你有个整体印象所有链接最终都要落到某一行里落不进去的说明它不属于你的工作流直接删掉更省事。分类触发场景典型内容更新频率学习成长想系统补一块知识开源书单、课程讲义、路线图季度看一次效率工具日常写代码、写文档终端增强、截图、剪贴板、图床半年看一次好玩有趣想放松、找灵感个人主页装饰、生成艺术、小游戏随手资源聚合想找某类项目各种 awesome 清单、周刊月度看一次部署运维要把项目跑起来CI 配置、容器镜像、打包脚本按需有一个细节值得说资源聚合类和具体工具类要分开存。前者是入口后者是出口。聚合类仓库的价值在于帮你找到具体的仓库本身不是拿来用的具体工具类才是你每天会打开的。混在一起存你每次翻列表都要重新判断一遍这个是用来干嘛的非常消耗注意力。2. 学习类仓库能当教材啃的那些收藏2.1 体系化路线型从零到能上手的那条线GitHub 上最值钱的一类学习资源是路线图式的仓库。它不教具体语法而是告诉你一个领域从入门到能干活中间需要经过哪些站每一站大概要花多久。这类仓库的典型形态是一张大图加一堆外链看起来简陋但对新手的作用极大因为它帮你省掉了我该先学什么这个最耗神的决策。我自己收藏过几个方向的路线图用下来最有用的是后端和 DevOps 方向。原因很实在这两个领域知识点太散没有路线图你很容易陷在细节里出不来。举个例子一条典型的后端路线会这样排先理解一门语言的基础语法和运行时再学 HTTP 和网络基础然后是数据库和索引接着才是框架、缓存、消息队列最后是部署和监控。你会发现框架被排在很靠后的位置这和很多培训班上来就教框架的顺序完全相反。为什么因为框架是易变的HTTP 语义和索引原理是十年不变的先学不变的东西你换框架的成本会低很多。用这类仓库有个小技巧不要照着图从头点到底。路线图的价值是坐标系不是待办清单。正确用法是先看全景找到自己当前的位置然后只往下走两到三站走完再回来看一次。一次性把整张图存进笔记然后逐项打勾基本都会半途而废。2.2 中文友好型汉化插件与翻译项目语言的摩擦成本经常被低估。一个英文界面你每操作一步都要在脑子里做一次翻译效率损失可能有三成以上而且会显著影响你探索的意愿——看不懂的地方你就不会去点。所以我在收藏夹里专门留了一格给中文友好类项目主要分两种。第一种是界面汉化脚本。GitHub 网页端的界面汉化一般是通过浏览器扩展配合用户脚本实现的装上之后菜单、按钮、设置项会显示中文。这类脚本的维护状态差异很大有的作者很勤快界面一改版几天内就适配有的半年不更新装上之后会出现文字错位甚至按钮消失。我的经验是装之前先翻一下最近的提交记录如果最近两个月有更新基本可以放心同时一定要知道怎么关掉它因为脚本偶尔会和页面冲突出问题时第一时间禁用脚本能帮你排除一大半干扰。第二种是内容翻译项目。这类仓库做的事情是把某个英文资源的正文翻成中文常见于技术文档、经典教程、公开课讲义。它们质量参差不齐我一般会看两个信号一是有没有保留原文对照能对照说明译者比较克制二是有没有写清楚翻译所对应的原版版本号技术文档几个月就会变不标版本的翻译很容易误导人。另外公共机构提供的开源镜像服务里也会同步一部分文档和资源找资料时可以顺手看一眼。2.3 带可运行示例的活文档比文字教程更好用的是带示例代码的仓库。判断标准很简单这个仓库能不能通过两条命令跑起来。通常是先装依赖再启动比如用一个包管理器装完直接跑开发服务器。能跑起来意味着你能改一行代码看一行结果这个反馈循环对理解抽象概念的作用比读十篇博客都大。我挑这类仓库时会额外看几个东西。第一是示例目录的结构好的仓库会把每个知识点拆成独立的小目录互相不干扰你只想看路由就只进那个目录差的仓库把所有东西写在一个大文件里改一处崩一片。第二是有没有配套的测试哪怕是几个最简单的断言也说明作者在维护时验证过这些示例不是写完就扔。第三是依赖是否锁定版本有 lock 文件的仓库你半年后拉下来大概率还能跑没有的多半会因为依赖升级而报错那时候你得自己去降版本很烦。顺带说一句如果你的目标是看懂别人的项目怎么组织那一份结构清晰的示例仓库比任何架构文章都直观。它的目录树本身就是一份设计文档。3. 工具类仓库装完就回不去的效率利器3.1 终端三件套搜索、查看、跳转命令行工具是 GitHub 上更新最活跃、也最容易上瘾的一类。我自己的习惯是把它们归成三件事找文件、看文件、跳到目录。这三件事做好了终端效率会有肉眼可见的提升。找文件这一格核心是模糊搜索。传统做法是先记住路径再补全而现代工具的思路是你只记得文件名的一部分也能找到而且会按访问频率排序你常用的那个自然排在前面。这个按频次排序的细节很关键它意味着工具会越用越顺手。看文件这一格主要替代的是直接用文本查看器打开代码的场景。用一个带语法高亮、带行号、能自动分页的工具读日志和读源码的体验完全不一样。特别是看压缩过的长文件能自动识别并横向滚动的工具会省你很多时间。日志文件尤其明显带高亮的工具会直接把时间戳、错误级别标出来一屏就能扫完。跳转这一格讲的是目录跳转。传统方式是不断地进入父目录再一层层往下现代工具的做法是从当前目录直接跳到目标目录路径记不全也没关系。我用下来最大的感受是装完之后你会忘记以前是怎么忍过来的。下面几条命令是我常常推荐给别人的最小安装路径注意只是思路示例具体包名请以各项目 README 为准# 模糊查找文件按访问频次排序 # 查看文件内容带语法高亮和分页 # 智能目录跳转直接跳到高频目录 # 以上三个工具通常可通过系统包管理器或对应发行版渠道安装用这类工具有一个坑要提前说不要一次性装十个。每个工具都有自己的默认快捷键装太多会互相冲突比如两个工具都绑定了同一个组合键结果就是谁也没生效。我的做法是先装一个用两周形成肌肉记忆再装下一个。3.2 截图、剪贴板与图床这类的桌面小工具写文档和写文章的人桌面工具链里一定有三样东西截图、剪贴板历史、图片上传。这三件事在 GitHub 上都有很成熟的开源方案。截图工具我最看重的不是功能多而是标注顺手。一个理想的截图工具应该做到按下快捷键框选松开就进入编辑画箭头、画方框、打马赛克、加序号这几件事能在十秒内完成然后直接复制到剪贴板。很多功能强大的截图软件反而输在步骤太多你要先选保存路径、再选格式、再打开编辑窗口一套流程下来热情就没了。选的时候可以先想想自己最常用哪三个标注其余的可以忽略。剪贴板历史工具解决的是另一个问题你刚复制的东西被下一次复制覆盖了。这类工具会记录你最近复制过的内容包括文本、图片甚至文件路径需要的时候用一个快捷键唤出列表。我在写长文的时候几乎离不开它因为经常要反复粘贴同一段代码、同一个链接。这类工具的一个关键设置是是否保留剪贴板内容到磁盘考虑到里面可能有过密码、密钥这类内容我会把历史条数调小并且定期清空。图床工具则是把本地图片上传到某个存储位置并返回一个可引用的链接。开源方案通常支持多种存储后端你只要配好密钥就能用。用这类工具最需要注意的是密钥不要提交进仓库一旦推到公开仓库就相当于把钥匙挂在门口所以本地配置文件一定要写进忽略规则。3.3 浏览器端增强脚本与插件浏览器这一侧的生态完全是另一套玩法。用户脚本管理器加上各类脚本能把网页改造成你自己想要的样子。有意思的脚本类型大致有几种给页面加增强功能的、给页面做减法的比如去掉推荐流和弹窗、把多个网站的数据拼在一起的。这部分我踩过的坑比较集中说三条。第一脚本权限要看清一个去掉网页广告的脚本如果要求读取你所有网站的数据你就得掂量一下能不装就不装。第二脚本之间会打架两个脚本同时修改同一个元素页面就会错乱这时候用无痕窗口逐个开启来定位是最快的办法。第三脚本失效是常态网页改版是随时发生的所以别把某个脚本当成工作流的必经环节它只是锦上添花。至于浏览器扩展我的原则是能少装就少装。每多一个扩展就多一份内存占用和一份隐私风险。判断一个扩展值不值得留可以问自己一个问题过去一个月我用过它吗没用过就卸载需要的时候再装回来成本很低。4. 有意思的仓库纯粹为了好玩4.1 个人主页装饰类让首页动起来有一类仓库的存在理由非常单纯让你的 GitHub 个人主页不那么素。它们通常是一段配置加一个自动化任务每天定时运行抓取你的公开数据然后生成一张图片或者更新一段文本效果是别人打开你的主页能看到一个动态更新的图表、一段自动统计的代码行数、或者一张不断变化的小卡片。具体能玩出什么花样常见的有把一年的贡献记录画成一张日历热力图统计你主要用哪些语言并生成占比条形图生成一张展示你最近提交的卡片还有把贡献图做成一个小动画让一条小蛇把方块一个个吃掉。这类东西技术含量不高但仪式感很强写进个人主页看着确实舒服。不过这里有个很实际的提醒这类自动化任务会在你的账号下产生大量提交记录。如果它们被你加进了某个你日常也在用的仓库提交历史就会被这些机器人刷屏以后你想查一次真实的改动得翻几十页。正确的做法是单独建一个和用户名同名的仓库作为主页仓库让自动化任务只在这个仓库里活动和其他项目彻底隔离开。4.2 视觉与生成艺术类这一类仓库是我觉得最不像代码的代码。它们用前端技术画图有的生成随机海报有的把数学曲线画成动态图像有的把音乐转成可视化波形。你打开它的在线预览页面调整几个参数画面就变了整个过程不需要理解背后的公式。收藏这类仓库的价值在哪我觉得主要是两点。一是审美参考做技术产品的时候经常需要一些视觉灵感翻一翻这类仓库的演示页比翻设计网站更贴近工程实现。二是学习可视化的实现思路比如坐标怎么映射、动画怎么插值、性能怎么优化。如果你有做数据看板的需求把这些仓库的源码读一遍比看教程收获大得多。这类仓库通常有一个共同特点演示页面做得很好看但 README 非常短。所以别只看 README一定要点开演示链接或者本地跑一下很多项目的美感是截图传递不出来的。另外这类项目依赖的构建工具链往往比较新如果你本地环境比较旧可能会遇到构建报错这时候先看仓库有没有提供预构建的产物或者在线版本别一上来就跟构建配置死磕。4.3 冷知识与小玩具类最后一类纯粹是为了开心。有人把整本词典塞进代码里做成命令行查询工具有人写了一个只有几十行但能跑起来的像素游戏有人做了把任意文本转成奇怪字符画的工具还有人收集了各种程序员冷笑话、终端小彩蛋。这些东西对你完成工作没有任何帮助但它们让你想起写代码本来可以很好玩。我收藏这类仓库的标准很宽松只要打开演示页让我笑了三秒就收。不过我会给它们单独放一个目录绝不和效率工具混在一起因为混在一起的结果是——你在找今天的部署脚本时被一个像素小游戏吸走半小时。顺带一提这类仓库往往是最好的读源码入门材料。因为它们通常只有一个文件、依赖极少、逻辑自洽你能在一个下午完整读完并且真正理解每一行在干什么。对刚学编程的人来说读一个能完全看懂的小项目成就感远大于读一个看不懂的大项目。5. 把收藏用起来下载、访问与部署的实操细节5.1 镜像站、源站与就近下载的取舍链接收藏得再多下载不下来也是白搭。这部分讲讲资源获取的几条路径和它们的取舍。源站指的是项目自己的原始地址。优点是永远最新作者刚发的版本你立刻就能拿到缺点是如果你和服务器之间的网络路径很长小文件还好大文件就会很慢。所以我的策略是小文件、偶尔下载一次的直接用源站省得来回折腾。镜像站指的是第三方同步的副本。公共机构运营的开源镜像服务就是典型例子它有固定的同步周期把上游的资源定期拉过来一份。这类镜像的价值在于两个一是下载路径更近二是即使上游临时不可用你依然能拿到历史版本。代价是有同步延迟通常几小时到一天不等所以你如果是追最新版可能会发现镜像里还没有。用镜像的时候有个技巧优先找完整镜像而不是部分镜像。有些镜像只同步了部分包或部分操作系统版本你下到一半才发现缺东西。判断方式是看镜像站的说明页通常会写清楚同步范围。另外包管理器的源也可以换成镜像这是提速效果最明显的一步比如# 把包管理器的默认源换成就近的镜像 npm config set registry https://registry.npmmirror.com pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple这两条命令改的是全局配置团队协作时要注意如果你的配置文件被提交进了仓库队友拉到之后会被自动改源所以这类配置最好放在用户级配置里不要放进项目目录。5.2 Release 包 / 源码包 / CDN 引用三种获取方式的差别同一个仓库通常有三种拿到它的方式用错了场景会很别扭。第一种是源码包也就是把整个仓库的历史一起拉下来。它的好处是你能看到全部提交记录、能切到任意历史版本、能自己改代码再提交。坏处也很明显仓库越大拉取越慢一个有几万次提交的仓库轻松几百兆。如果你只是想看看代码或者跑一下完全没必要。浅克隆是最实用的解法# 只拉最近一次提交省掉大部分历史体积 git clone --depth1 https://github.com/owner/repo.git # 如果项目用了子模块一并浅克隆 git clone --depth1 --recurse-submodules --shallow-submodules 仓库地址第二种是Release 里的预编译包。很多项目尤其是图形界面工具和命令行工具会直接把编译好的可执行文件放在 Release 里你能找到对应你操作系统的版本下载解压就能用不需要任何编译环境。这是最省事的一条路我建议优先看这里。判断标准是文件名里带不带系统标识比如 windows、macos、linux、arm64 这类。选错架构的表现是打开就报格式错误或者直接被系统拒绝运行这时候回头看文件名就能发现装错了。第三种是通过 CDN 直接引用。如果你的目标是给自己的网页加一个图表库、一个动画库那完全不需要下载直接在页面里引入一个链接就行。这种方式的好处是零构建成本坏处是引入了外部依赖——如果那个链接挂了你的页面就白屏。所以生产环境用这种方式时最好再准备一份本地备份或者把文件下载下来自己托管。5.3 404、403、连接超时的排查顺序访问过程中最常见的三类报错是 404、403 和超时。它们的排查顺序是有讲究的按下面这个顺序走能避免大部分无效尝试。遇到404第一反应不要怀疑网络先怀疑链接本身。GitHub 上非常常见的情况是作者把默认分支从 master 改成了 main或者给仓库改了名、转移了归属你手里的老链接就失效了。这时候最有效的办法是访问那个用户或组织的主页搜一下仓库名通常一两分钟就能找到新地址。如果是文件级的 404还要检查分支名和路径大小写——GitHub 的路径是区分大小写的Docs/readme.md和docs/README.md是两个东西。遇到403一般是权限或者频次问题。可能性有几个你没有登录访问了私有资源你短时间内请求太频繁触发了接口限流或者你用的某个自动化脚本被识别成了异常流量。处理方式是先确认自己是否已登录然后停一会儿再试。写脚本批量抓取时尤其要注意加上合理的间隔和重试逻辑比硬刷要有效得多。遇到连接超时才轮到网络层面。这时候先分清是打开网页慢还是下载文件慢。网页慢一般是资源加载多下载慢则多半是文件体积大或者路径远。可以优先尝试前面说的镜像方案或者改用浅克隆减少数据量。另外有一个容易被忽略的点有些项目仓库本身就不大慢是因为你拉了一个包含大量二进制素材的分支这时候换分支比换网络有效。6. 判断一个仓库值不值得收藏6.1 五个指标快速过筛面对一个陌生的仓库我会在三十秒内扫五个指标基本能判断出它值不值得占用我一个收藏位。第一个是最近一次实质提交的时间。这个前面说过重点看是不是实质。如果最近一个月有功能性的提交说明项目活着。第二个是issue 的响应情况。不是看数量是看比例。一个有一千个 open issue 的项目不一定差——可能只是用户多但如果随机点开五个最近的 issue全都没有任何维护者回复那说明这个项目已经是只读状态了。反过来一个只有二十个 issue 但每条都有维护者认真回复的项目哪怕规模小用起来也踏实。第三个是文档的完整度。重点看有没有快速开始、配置说明、常见问题这三块。缺第一块说明作者默认你会读源码缺第二块说明配置项全靠猜缺第三块说明作者没被真实问题毒打过。第四个是依赖数量。一个只解决小问题的工具如果引入了几百个依赖我会很警惕一来安装体积大二来供应链风险高。小而专注的工具通常依赖很少。第五个是有没有替代品。如果同类工具你已经有一个用得很顺的那新工具除非明显更好否则没必要换。收藏夹里同功能存三个最后你一定只会用其中一个。6.2 从 issue 和 commit 看项目是否还活着要把项目还活着这件事判断得更准有几个不那么直观的信号值得留意。看 commit 的作者分布。如果全部提交来自一个人那这个项目的风险就是作者哪天不干了这在个人项目里非常普遍。如果有三五个活跃贡献者抗风险能力就强很多。看 issue 的标签使用情况也能说明问题有good first issue、help wanted、bug、enhancement这类规范标签说明维护者在认真管理社区一个标签都没用过的仓库通常意味着 issues 区就是个留言板。还有一个很实用的技巧去 issue 里搜你打算做的这件事。比如你想用这个工具做某个特定任务直接在 issue 和讨论区搜关键词。如果已经有人踩过坑并且贴出了解决方案你能省掉大量时间如果搜出来一堆同样的需求提了两年没人做那你就该重新评估了。反过来作为使用者你也可以做一点贡献解决问题之后回到 issue 里补一条结论。这个习惯不仅能帮到后来的人也会让维护者更愿意搭理你后续的问题。6.3 上传文件夹、跑起项目新手最容易卡住的两步有两件事几乎每个新手都会卡住一次我提前把路径写清楚。第一件是上传文件夹。网页端的文件上传现在支持直接拖拽文件夹浏览器会自动把里面的文件展开成一条条上传记录小文件和少量文件用这个方式很省事。但如果文件多、目录深网页上传会变得很慢甚至中途失败。这时候用命令行更靠谱git clone 你的仓库地址 cd 仓库目录 # 把要上传的文件夹复制进来然后 git add . git commit -m 添加 xxx 文件夹 git push有一点必须提醒仓库里默认不适合放大体积的二进制文件比如视频、数据集、安装包。单个文件超过一定大小就容易被拒绝而且一旦提交进历史想把体积瘦下去非常麻烦。真有这类需求应该用专门的附件存储方案而不是硬塞进代码仓库。第二件是把别人的项目在自己机器上跑起来。顺序是这样的先看 README 里有没有写环境要求确认你的语言版本对得上然后按说明装依赖注意这一步用不用锁文件有 lock 文件就用锁文件对应的命令接着按说明启动观察报错。绝大多数启动失败的原因集中在三个地方语言版本不对、依赖没装全、缺少必须的环境变量或配置文件。前两个看报错就能看出来第三个最隐蔽——很多项目需要你复制一份示例配置改成自己的忘了这一步会表现为启动时缺参数而且报错信息往往不直观。如果项目提供了容器配置那强烈建议优先用容器跑。它的价值在于把环境问题一次性隔离掉你不用在本地装一堆版本。代价是需要先装好容器运行时这一步是一次性成本装完受益很久。7. 常见问题速查与我的几条私房经验7.1 问题速查表下面这张表是我这几年被问得最多的问题的浓缩版按现象→原因→处理顺序排列遇到问题可以直接对照。现象大概率原因处理顺序页面显示 404仓库改名、转归属、分支名变了先搜仓库名找新地址再核对分支名和路径大小写页面显示 403未登录、权限不足、请求过于频繁确认登录状态暂停一段时间后重试脚本加间隔网页能开但很慢页面引用的外部资源多只取自己需要的部分减少一次性加载下载大文件很慢文件体积大、下载路径远换就近的镜像源或只下载需要的单个文件浅克隆后找不到某个文件该文件在更早的提交里取消浅克隆或单独拉那个分支依赖装不上默认源路径远、版本不匹配换就近镜像源按锁文件还原依赖版本项目启动就报错语言版本不符、配置未初始化对照 README 的环境要求逐条核对配置项仓库体积巨大历史提交里混入了大文件用浅克隆若只是看代码可直接在网页上浏览上传被拒绝单个文件体积超限改用附件存储方案不要把大文件塞进仓库命令行推送没反应认证方式或凭据过期重新配置凭据确认账号权限7.2 账号安全与两步验证这件事别拖有一件事我想单独拎出来说就是账号安全。你的 GitHub 账号绑定的不只是代码还有邮箱、可能的部署凭据、以及你贡献过代码的记录。一旦丢了找回过程相当麻烦。两步验证一定要开。开启之后除了密码还需要一个动态验证码密码即使泄露了别人也进不去。现在常见的形式是验证器应用生成六位数字或者使用硬件密钥。这里有个坑必须提醒开启时系统会给你一批恢复码这是你手机丢了之后唯一的救命稻草一定要单独存好不要放在这台设备上也不要截图丢在手机相册里。我见过太多人开完两步验证手机一换账号就进不去了。另外两个小习惯也值得养成。一是密码和验证码分开存不要用同一份备忘录记所有东西。二是定期看账号的安全设置页检查有没有陌生的登录记录、有没有你不知情的授权应用。顺手把不用的授权撤销掉这一步花不了两分钟。还有一点如果你写了脚本要访问自己的仓库别把令牌硬编码进代码。用环境变量的方式传进去本地配置文件写进忽略规则这是最基本的一条线。7.3 我自己的收藏夹维护节奏最后说说维护。收藏夹不维护三个月就会变成垃圾场这个我深有体会。我现在固定三个节奏。每周花十分钟做一次清扫。把这一周新存进来的链接过一遍问自己一个问题我在过去七天里用过它吗没用过就删或者挪到一个待验证目录里。这个动作看起来很随性但它是防止膨胀的唯一有效手段。每季度做一次验证。把效率工具类的收藏全部打开一遍看两件事项目最近有没有更新、我的系统上还能不能正常跑。这一步会淘汰掉一批已经停止维护的工具也能提醒你把过时的用法更新一下。每年做一次重构。重新审视分类骨架看看有没有哪一类变得特别臃肿。我最近一次重构就是把工具这一大类拆成了写代码用和写文档用两部分拆完之后找东西的速度明显快了。还有一个我坚持了很久的小习惯分享出来每加一个新链接当场写一句备注。格式很简单就是它能帮我做什么加当前版本大概什么状态。这句备注千万别省因为半年后你打开这个仓库看到的是一个完全陌生的界面唯一能让你快速回忆起来的就是当初写的那句话。我发现只要坚持了这一点我的收藏夹复用率能翻好几倍否则存进去的链接基本等于没存。另外如果你发现某个仓库解决了你一个长期存在的问题别只是收藏去给作者点个星、留一句感谢或者在 issue 里补充你的使用场景。开源项目的维护者绝大多数是业余时间在做这件事一句具体的反馈对他们来说就是继续下去的动力。这个习惯我保持了好几年也确实因此和不少作者建立了联系后来遇到问题时得到的帮助远比我当初付出的那几分钟多。