上不了 GitHub 的那些人，也在用我的插件

事情是这样的。

我的 Obsidian 插件做了一段时间，一直托管在 GitHub 上。版本一直往前走，每发一个版，我都会顺手看一眼后台的下载数字，心里大概有个数。

然后有天晚上，我盯着那个跳动的数字，忽然想到一个之前被我忽略的盲区，这些数字背后，会不会有一部分国内的朋友，其实根本就没能点进来过？

国内访问 GitHub 一直是件看运气的事。有时候挺顺，有时候图片刷不出来，有时候干脆连不上。我自己的插件发布页里，恰好放了几张功能截图，还有几个仓库内的跳转链接。对一个网络顺畅的人来说，这些都是顺理成章的事，但对一个时不时遇到连接失败的人来说，可能每一步都算一道坎。

我不是被谁在群里提醒的，也没有收到过什么抱怨。完全是那天深夜自己突然预判了一下，如果我是一个普普通通的国内用户，我想装这个插件，我能不能顺顺当当装完？

答案其实挺尴尬的。

先把问题界定清楚

动手改东西之前，我先逼自己坐下来琢磨了一件事，分清楚「访问不了网站」和「装不上插件」，其实是两件截然不同的事。

如果只是访问不了 GitHub 网页，那我给国内用户备一个镜像站，让代码能看见、文档能翻阅，这就足够了。

但如果用户是想用上这个插件，单单把源码镜像一份过去，其实帮不上太大的忙。绝大多数人不是来读代码的，大家最迫切的需求，是能顺顺当当地拿到可以直接装进软件里的成品安装包。

对我来说，最要紧的其实是后一半，让那些打不开 GitHub 的人，也能真真切切地拿到安装包。

我想过迁走，但最后没有

顺着这个问题，我最开始确实动过一个念头，既然国内访问不顺畅，要不干脆把整个仓库搬到国内的代码托管平台上去？

我还真去认真研究了一圈。国内的主流平台，代码搬迁这件事本身并不难，甚至很多平台都带了一键导入功能，把 GitHub 仓库地址往里一填，代码、分支、历史版本顺顺当当全带过来了，也就是几分钟的事。

但研究到一半，我发现了一个绕不过去的现实，我这个插件，根本离不开 GitHub。

因为我这个插件走的是官方渠道，收录在 Obsidian 自己的社区插件市场里。而官方市场的整套分发机制，是完全建立在 GitHub Release 之上的。你就算把仓库整体搬到了别的地方，只要插件还在官方市场里，它后台照样还是会从 GitHub 去拉取文件。也就是说，仓库可以搬家，但生态的根基搬不走。

这一下就把整体迁移这条路给堵死了。剩下的选择，只能是让 GitHub 继续当主仓库，国内再另做一份镜像。

这个思路我觉得是对的。毕竟大多数开发者在习惯上，还是在 GitHub 上更顺手。

不过在这个关口，我顺便还撞见了一个更现实的问题，我的仓库里，原来一直躺着大量构建出来的成品文件。

一笔被忽略的技术债

插件这类东西，写的是源码，用户真正装进软件里的是一份打包出来的成品。为了图省事，我过去一直习惯把打包好的成品文件，跟着源码一起提交进 git 仓库里，源头可能还是因为没有专业的工程经验。

这在平时改动少的时候不痛不痒，直到那天下决心查了一下仓库的体积，我才发现事情不太对劲。

一个几百 KB 的源码，打包出来是 3 MB 多的成品。而我这个项目前前后后迭代了五百多次，里面有非常多次小改动，都顺带重新提交了这份成品。把它们全累加在一起，仓库的压缩体积竟然膨胀到了一百多 MB，而其中绝大部分空间，全都被那些不断被重复提交的成品二进制文件给吃掉了。

坦率地讲，源码只改了几行，成品就得整份换新，每次一换，仓库里就硬生生多存了一份 3 MB 的历史包袱。

这大概不是我一个人的毛病。很多写前端、做插件的朋友，仓库里都难免塞过这么一份跟着源码住在一起的成品。平时自己拉代码不觉得慢，一旦要推到别处或者让网络不好的人去 clone，才会发现怎么这么臃肿。

所以这次在给国内用户补安装包之前，我先顺手做了一件事，把成品从「跟着源码走」，改成了「跟着发行版走」。

用户安装的时候，本来就是从发行版 Release 里拿文件，仓库里留的那份，其实只是一堆历史遗留的备份。改完之后，仓库不再被成品无休止地撑大，而每一个版本依然完整可查，只是仓库回归了纯粹的源码。

这一步看似跟国内镜像没有直接的因果，但它让镜像这件事变得利落了，各归各位，技术债也算理清了一笔。

最后落地的样子

理清楚了这些弯弯绕绕，事情反而变得异常简单。

GitHub 继续坐镇主仓库的位置，所有的日常开发、分支合并、版本发布都在这里，这是唯一的真相源。国内这边，我在 Gitee 上建了一份镜像，地址是 https://gitee.com/david_lin1002/obsidian-wechat-converter ，它平时只干一件事，安安静静地跟着主仓库同步源码。

至于原来那一百多 MB 的历史体积，我没有去动它。用工具暴力重写历史，所有版本的 commit 编号全都会跟着乱掉，对别人已经拉取过的使用、对过去的发布引用，都是没必要的折腾。留在那里就在那里，只要从现在这一刻开始不再膨胀，这就够了。

然后，为了照顾那些确实打不开 GitHub 的国内朋友，我多做了一小步自动化，每次我在 GitHub 上打一个版本标签，流水线在同步源码的同时，会自动把编译好的安装包同步一份到国内平台的发行版页面上。

这样一来，一个网络不太顺畅的人，也能在国内的页面上，顺顺利利地找到和官方一模一样的安装包。

整个流程就收敛成了一个最自然的动作，我依然只在 GitHub 上打一个版本标签，剩下的事情全交给自动化。

写完这段，我在想什么

这件事其实不算大，就是一个在职的独立构建者，在业余时间给一部分用户多铺了一条稍微平整点的路。

但整个折腾的过程里，有两句话我自己深深记了下来。

第一句话是，先分清问题，再动手。

如果一开始我就凭着直觉奔着「我要把库迁走」去，我大概会花很多时间去折腾搬迁，最后却发现插件市场根本不认，白忙一场。反而是逼着自己停下来，先去琢磨用户到底卡在哪一步，才把「看代码」和「装插件」理成了两回事，各自找到了最轻巧的解法。

第二句话是，那些上不了某个网站的人，也是你的用户。

这一点我以前其实想得不够深。很多时候我们做工具，很容易下意识地默认别人也跟自己一样，有顺畅的访问环境，点击下载就能瞬间拉下来。

但世界不是平的。

同样一个插件，在顺畅的网络里是几秒钟的丝滑体验，在一个处处碰壁的环境里，可能就是一堵让人放弃的墙。

多铺一条路的成本其实并不高，难的是克服自己的认知惯性，先意识到，原来还有人在需要这条路。

这大概是我这次折腾里最大的收获，不是多建了一个镜像，而是多了一份不傲慢的视角。