从 18 年开始，我写了好多日记，但是在这六年间，我换了好几个笔记软件，从 OneNote 到 Obsidian 再到 Logseq。这些日记跨越了不同软件、不同格式。之前不敢想像能把多年的日记能聚集在一起，因为确实抽不出来时间来写软件脚本，把他们之前的差异打平。

但是最近用上 Claude 之后发现这个 AI 确实不太一样，能写出来的代码确实很 work。在一顿操作之后，用 claude 写了十几个 one off脚本，，把不同格式、来源的笔记都转换成当前使用的 logseq 的格式。

正如之前所提到的，AI 将可能改变开发的范式，在之前写 one off 的脚本，大家都是用 Ruby，各种文件读写 API 调用的方便，写起来也是又短又快。但是在 AI 时代，这些语法糖、API带来的优势并不重要了，用 Python 反而有优势，一是语料大，二是懂的人多，用 Python 的优势大于 Ruby。

这样类似的事在 V0.dev 出来的时候我就想过，比如 Solid.js 很甜是吧，但是 React 的语料是你的数倍，用 AI 写前端，React 的质量就是会比 Solid.js 高、容易。这些后发的新语言/框架感觉更难出头了。

除非语法糖是对 AI 友好的，比如 Tailwind CSS，把 CSS 和 组件放在一起，这样 AI 写 Tailwind 就比写 SaSS 容易了。

除了对 AI 友好的编程语言会在未来脱颖而出，还有对 AI 友好的软件、内容格式也会在未来的竞争获得超乎想像的竞争优势。更容易与 AI 结合，再与其它工具联动，从而形成 1 + 1 > 2 的效果。

在现在很多软件通过数据库/私有格式来存储数据，但是这种私有格式对 AI 感觉太不友好了。就拿用书籍、文章来做来 AI 的知识库，用 Markdown 的书籍远比用 PDF(更甚是图片形式的PDF)好处理的多。

用可人类理解的文件还有很多好处，比如之前读 Obsidian 作者的 File over app 哲学，『如果你希望你的文章在 20 世纪 60 年代或 21 世纪 60 年代的电脑上仍可阅读，那么你的笔记在 20 世纪 60 年代的电脑上也能阅读』。用文件来存储数据，可以让数据活的更久。

但是同样可以看到像 Logseq、 Affine、Anytype 等等软件又转向了通过数据结构来存储数据，尽管他们也有难言之隐，比如用 Markdown 存储笔记的 Logseq 以在同步中丢失数据而出名。但是或许我们能在两者之间找到平衡点。

介绍

有好一段时间没有更新博客了，主要是因为从学校毕业之后转正的工作比较忙了。然后学习、沉淀了一段时间。最近又想开一个新的坑，与之前想到啥就做啥的 Side Project，这次我用上了学习各种 Indie Hacker 的方法。这篇文章主要还是记载一下我是怎么尝试 build 一个项目，而不是 PVE 本身和软件的介绍。

Build 之路

大概一个月前开始感觉 PVE 在手机上不太好用，如果能有一个手机端的客户端就好了。再从而觉得如果只有管理感觉没有啥意思，如果再有一些很酷的功能，比如一键显卡直通、一键安装 Windows 系统等等那就更好了。

但是调研完市场之后感觉这个市场算是比较蓝海的，产品的形式还没有定义出来，像 VidHub 直接抄 Infuse Pro 就很舒服，做为一个 PVE Client，我很难说我觉得这些痛点是否是真的用户所需要的东西。 所以开始漫长的调研。

市场调研

其实前面就是市场调研，先是调研了市面上所有的 PVE 客户端，然后是 PVE 现有的工具。这个其实没有啥价值，现有的市场很小，没有一家说能是成熟的。

首先第一步就是搞 SEO，我用了五分钟做了 Landing Page，然后部署上去，想看看能不能收集到一些 User。觉得有可能再开工，但是发现各种不太可能，当然包括我对 SEO 不太熟，官网上线谷歌和Bing之后一周之后依然没有任何流量。只能说没有搞外链啥的基本不太可能有权重。

然后开始研究 SEO，我最初的想法是比如我不清楚用户需要什么，就可以通过SEO来看看需求对应的搜索量。比如如果 PVE GPU pass-through 的搜索量很大，就说明这个功能是用户所需要的。然后我还能从中找到我想不到的各种用户需求。

但是发现这个市场实在是太小了，我用了谷歌趋势，还在淘宝上买了 Ahrefs 的工具都没有找到什么有用的信息。比如前几名是 How install PVE, 后面几位也是一些很基础的问题。根本无法定位有效的需求。

所以开始埋伏在 Reddit 和 QQ 群。然后依然发现大家的问题是非常非常的小众，很难提取出共同的需求。

在上面简单的都做完之后，一无所获的我只能开始用户调研，我用 The Mom Test 的方法开始我认识的 PVE 用户开始大量的谈话。

这一步之后我依然感觉非常痛苦，首先我没有采用引导式的对话，我都是尽可能简单的和他们聊天谈 PVE。但是从他们身上只能感觉到 PVE 用起来没有啥坑(除了Ceph)，也没有踩什么坑，现在东西也都够用的感觉。

是的，我根本没有办法从用户的聊天中得到哪怕一个他们觉得的痛点。就算我带点引导的提问，你上次搞那个硬盘直通，你感觉有坑吗? 难搞吗，他们都会说感觉不难呀，没有啥坑呀。🤔 我一度怀疑这个市场这么小，是不是就是大家根本不需要这个玩意。

但是回过头来想想或许现在存留下来的玩家都是被筛选过的，前期觉得难的用户已经消失了，所以我的调研对象的取样错了。所以在大概列出功能之后还是决定开始开发。

PVE Client 未来大概要做什么

大概关于 Marketing 的想法还是 SEO 先行，后续可以好好做 SEO，比如写一系列的文章，比如如何在 PVE 中显卡直通，内容就是使用我的软件一键配置 PVE 显卡直通。如何在 PVE 安装 Kail、Ubuntu、Windows。一系列文章来占领搜索引擎。

然后功能上先大概出一个 MVP，尝试拉一些早期用户起来，尽可能的通过倾听真实用户的需求，然后快速迭代来快速开发。目前最大的困难感觉就是倾听不到真实用户的需求。

比如第一个MVP中，我想给用户至少一个 ah moment。但是交付哪一个呢? 我没有提交 waitlist 用户的投票选项，也没有听到核心用户群的反应。所以在早期的 MVP 中会变得非常非常的迷茫。

今天用 VitePress 把 PVE Client的 Landing Page 重构了一下。这个比我之前用的那个模块好做 Content 的 SEO 和 sitemap。

预期下周能产出一个基本能用的 MVP，希望能做完 SEO 之后能收获一些早期用户吧。

做出决策

能挣大钱的事都是有风险的，在『美团清华产品课』中美团的王慧文说他们能成功有很大一部分原因是因为他们勇敢。

我在雷锋网读了到那些现在那些独角兽、成功的公司还有那些失败的公司的故事，其实各种调研、分析都很难说个对错，确实迈出第一步的勇敢是很重要的。

尽管现在复盘起来他们的当初的决策中会有看到各种判断、分析。从怎样的理论上来思考，但是当初谁不能肯定一定会成功。但是为什么他们能勇敢呢? 是因为他们的眼界更广吗、看到别人的成功，所以对自己能成功的信心更足、还是带点基因与原生家庭影响。

我看到一个关于房价的视频，中说房价是与负债率有关的，负债率低房价更容易涨起来，而到了20、21年中国的负债率已经居高不下了，所以房价很难涨了。正巧，前几天在公司翻到一本21年出版的书籍，里面同样通过一系列的逻辑推理，得出中国房价还会涨的结论。

所以很多理论调研就像是一个轮子，正说反说都说的通，所以最后的决策就是得看勇气。现在对看各种理论分析，什么抖音搞电商成功了是因为什么什么，快手化商业化做的不如抖音好又是什么用户量不够，导致的广告单价上不去。

我的越来越小的勇气

我感觉我的胆子越来越小了，这几天进了几次医院，先是健身导致了横纹肌溶解、然后回家骑车的时候摔了，再接着是打羽毛球的时候，头盖骨被狠狠的扣了一球拍。人们常说人教人教不会，事教人一教就会，我以后上重量肯定不会那么极限了，雨天骑车的时候速度会更慢、运动的时候也会更加小心。

在这些事上小心看起来确实没有问题什么，也对我不会有什么明显的害处，但是如果我对我的职业选择更加保守呢? 如果我要选择工作，我是选择一家创业公司还是一家大公司? 如果让我选择城市，我是选择去北上广深去漂还是回老家有房挣的少一点呢?

我现在遇到的各种挫折可能就会让我变得保守，可能就让我放弃更好的机会。

踩在风口上的人

你们说那些在房价上涨之前做出决策的人，那些买房的人，他们敢做这么大的决策是因为他们有多聪明吗? 做出多少研究吗? 可能只是因为勇敢吧，那为什么会这样勇敢呢，可能是他们上一次做出勇敢的决定成功，所以他们这次又勇敢了。那些决策相对保守人，他们在做买房决策的可能就有更多的犹豫，错过了风口。

王兴在做出美团之前，考上清华大学，再做出校内网、饭否网。确实是一路成功，那么他在美团遇到各种风险的时候确实会有更多的勇气。如果他的前几个项目失败了，说不定他会变的更加保守，美团可能也没有今天这么成功了。

那些由于勇敢而成功的人，可能对比另一批失败者，他们只是之前的运气更好而已。

ToFree 是什么?

ToFree 是一个自动抓取 WARP+ 节点信息并将其转换成 Clash、Surge、WireGuard 等软件可订阅使用的工具。

为什么我要搞 ToFree?

WARP+ 应该是 2023 年推出的一款代理服务，因为能在中国大陆使用、并且免费的原因。很快就有大量的教程出来教大家如果在 Surge、Clash 上使用 WARP+ 的节点。我也在那时候尝试了一下。那时候我认识虽然免费而且速度勉强可以，但是这不值得我省下一个月几十块的机场钱。所以我再也没有用过了。但是这其实上是我忽略掉了 WARP+ 的一个很重要的价值。

我很早之前就看到编程随想教使用 Tor 匿名的文章，其中提到使用赛风、自由门等等软件做为 Tor 前置代理。在我短暂的使用 Tor 的经历中我从来没有用过这些软件，因为这些软件虽然免费，但是无不是又卡又慢。对于我来说根本无法使用。所以我一直使用付费的机场作为 Tor 的前置代理。

但是在前段时间，我意识到如果在 Tor 前使用这些机场的代理，那么匿名的效果就会很差多。因为你在机场留下了付费的信息。所以我一直忽略了免费的另一面: 匿名。

所以我就想尝试通过订阅的方式为不同的代理软件提供免费、匿名的 WARP+ 代理。其竞争对手并不是付费的机场，而是之前那些免费的 Tor 前置代理软件。

经历

我有了这个想法一起就爬了起来，先在 GitHub 上搜索有没有人已经有了实现。幸运的是我一下就搜索到了。我尝试了一下，其功能还是可以工作的，实在太棒了，说明这个 ToFree 项目不会消耗我的太多精力与时间。

然后我做了一些优化，加了一个好看的前端界面，写一些代码解决了一些小 Bug，然后支持了 Surge 的订阅。部署在 Zeabur 上。然后在 V2EX 上做 Launch。没想到收获到了意料之外的关注度。

随便在尝试在阮一峰的周刊与 HelloGitHub 上再 Launch 一次，可惜没有过审。

整体设计

我对 WARP CLASH API 的主要改造是对用户体验上的改造。首先是网站的上手难度，其次是订阅链接的简洁性。

原 WARP Clash API，只提供了订阅链接，而且是非常复杂，在 path 后面还有大量的 param。我先是加了一个无参数，尽可能简单的订阅链接。如https://subs.zeabur.app/clash，这样用户在一台新设备上就可以直接默写出来订阅链接，这个体验其实是非常棒的。特别是在比如别人的设备上，比如帮我对象翻个墙。

然后加了一些 url schema 自动导入订阅软件这些就没有什么额外说的。🤔

至于这些改动，已经通过数个 PR 渐渐反馈到上游的开源项目中去。这个我觉得是很重要的，如果你代码用了什么开源项目，做了优化与改动还是得尽可能的反馈给上游与社区。这个并不是出于什么道德。而是可以降低你的维护成本。后续上游有什么修复或者新功能，你同步回来也方便。很有趣，出发点是自私的，但是结果确是对大家都好的。😋

收获

我从中收获了一个新朋友和大约 5 个新的 Twitter 粉丝。我和该开源项目的开发者成了朋友确实很开心，但是 5 个新的 Twitter 粉丝。确实没有达到我的预期。我在设计之初，希望收获一些关注，比如Twitter 粉丝，然后通过拿马斯克的广告费来盈利。所以我做了一些改造，比如 ToFree 上顶部放上直达 Follow 按扭的 Twitter Link。但是转化效果依然不理想。后续可以研究一下，是什么原因，比如是没有点开，还是用户没有登陆无法关注，或者觉得关注并没有带来价值。🤔

(Update: 后续长尾运营带来的粉丝还是不少的，大概有 20 ~ 30 个) (Update: 后续长尾运营又带来了大约 300 个粉丝，这回舒服了)

帮助上游项目 WARP Clash API 的 Star 大概翻了四倍。 (Update: 后续翻了59倍)

反思与总结

最后大概来个总结，首先我在 UI/UX 上做的改造不错，解决 WARP 用起来麻烦的痒点，其次是在 Launch 上做的不错。做的还不够好的地方，主要就是后面两次在其它网站的 Launch 没有通过，可能是题材比较敏感或者写的内容不够吸引人。

这个模式也大概也有个雏形，我可能后面也会尝试继续挖掘生活中感受到的痛点，然后寻找是否有开源项目，解决开源项目常出现的 UX 不够友好的问题。然后发布，帮助到大家，收获关注。

TechStack 是什么?

TechStack是我去年开发的一款浏览器插件。大约收获了 400+ 的 Star 与 900 的日活。这个插件可以在 GitHub 仓库旁边显示当前仓库的技术栈。这个插件的初衷是为了帮助开发者更好的了解一个项目的技术栈，以便更好的学习和使用。

但是我最近减少对插件的开发与维护，并且在最近进行了一些小重构以降低成本。在这里我想谈谈为什么这不是一款好的软件和我为什么减少维护。

TechStack 为什么不是一个好软件?

TechStack 算是我第一款『完成的 Side Project』。收获了一点点小关注。但是现在事后回过头来看，这个并不是一个『好软件』，我从来没有进行过市场分析、调研。也没有研究过开发者的需求。只是觉得这样一定很酷很有用，所以就开始做了。

但是事实上，虽然我每天都在使用(被动地)，但是我感觉我没有被帮助到，解决掉我的什么痛点或者痒点。对于这个插件，我最初的设想也很宏伟，不仅仅只是一个插件，还是一个入口、起点。我可以通过收集到的数据进行各种分析与分享。

比如我还可以再做一个网站来分析技术栈的使用情况，比如被应用到实际开发中的增长趋势。对比不同的技术栈应用情况来帮助用户在选择技术上时更好的决策。

以及用户可以选一些技术栈，找到一个项目，看看别人的代码是怎么写的。比如选择 Flink 和 Pulsar、 gRPC 和 SWR 这样通过拼接技术栈来找到一个项目。学习应该怎么写。

但是最后都没有实现，主要不是技术原因，还是我觉得这些并没有解决掉什么痒点和痛点，大家其实并不需要这个。

TechStack 需要降低成本?

因为 TechStack 已经停止功能开发了，而且也绝不会从中获得任何收益。所以我觉得我需要必须降低运行成本，这里主要指服务端的成本。本来这个 TechStack 的运营成本确实很低，但是随着数据量的增长，已经高到一个让我难以接受的地步。

这些图是我一个 Zeabur 的账号的费用用量图，可以看到最大的成本支出是 TechStack 的数据库 MongoDB 所占用的。光数据库一个月的支出就将近 200+ 人民币。这个成本对于我来说是不可接受的。

这里谈谈 TechStack 在 MongoDB 中存了什么和为什么这么大的用量。TechStack 的最初的设计上使用两级缓存的机制，一级缓存是存储一个仓库对接的技术栈，有 1 天的过期时间。然后二级缓存是仓库对应的依赖文件，其就存储在 MongoDB 中。这样做的原因是因为早期我对 TechStack 的依赖项对应技术栈更新很频繁。所以我觉得这样做可以减少对 GitHub 的依赖文件的请求次数，缓存过期之后就可以用新的解析器对缓存好的依赖文件进行重新解析。

TechStack 是如何降低成本的?

首先已经找出最大的问题所在，就是 MongoDB 的存储成本。我现在不需要存储这些依赖文件的内容了，所以我就用rockscache做了二级缓存，现在只缓存解析出来的结果，

所以现在可以把 MongoDB Compass 也给一起删掉啰! 我一点也不喜欢这个 electron 应用。又卡又慢一点也不好用，除了好看。

当然 TechStack 是一个非常大的异构项目，像 Request TechStack 的后端、Gradle Parser 等等是用 Java 来实现的，内存占用也是十分的大。尽管这次我还没有移除它们，但是在未来我也会考虑降本增效(笑)🤣。

我从 TechStack 学到了什么?

前面提到 TechStack 算是我第一款『完成的 Side Project』。所以我在这里开发中，还是学到特别特别多的东西。包括工程化的开发、监控还有很多很多工具，像是 Prometheus、Grafana、Flink、 Nest.js、Prism 等等。而且很多时间是为了学新技术而去用新技术。所以在很多地方采用了不是最优实践，也图增成本。

抛开技术不谈，就是学到运营与宣发，确实找到了很多平台。知道哪些平台能有流量，哪些没有。和应该怎么发。还有在这期间尝试去学习产品经理的理论与方法论。

在下一篇文章我可能谈谈ToFree，这也是一个免费、开源的项目。这个项目虽然是冷启动，但是收获了不少的关注，也帮助一个开源项目的 Star 翻了数倍。我想谈谈我是怎么想到，付了一个很低的成本，然后收获了一些不小的关注与用户，但是为什么我没有从中得到我想要的。做一些反思与总结。

PS: 本文写于 2023-08-25 ，但是因为最近基本所有的下班时间都趴在 TechStack 上，再加上本人的拖延症一直犯，所以在咕了两个月之后才写好。🤣

谷歌插件无法过审

我的浏览器插件已经两周没有更新了，倒不是我没有写代码，而是总是被不停的拒绝并且没有任何的理由😭。所以我在不停的尝试代码中的各种地方，但是就是不能过审

最早以为是我的代码中有一个feedback(用了mailto)，点击就触发邮箱应用。是因为这个原因不能过审。

但是在每天晚上被拒绝一次之后我又提交一次之后并且每天晚上骂谷歌十分钟之后的今天我终于发现几封未读的邮件。🤯原来谷歌在这里把拒绝原因分开来发，倒不是我没有想到，主要是行为的不一致性，因为有时候拒绝原因是写在 Developer Dashboard 中的，如下图。 让人容易产生误解。以为就是只在 Developer Dashboard 通知开发者，根本没有想还会通过邮件通知开发者。

解决办法

既然知道问题了就要解决问题。大概就是我提交的代码中不能混淆。但是我的插件是基于 GitHub 上的 boilerplate ，别人怎么就能用这个 boilerplate ，我不行?😅

首先看一眼代码，确实感觉混淆在一起了把这里 minimize 改掉。 现在来看看效果，感觉还不错。大概有了代码的样子，但是这个应该还是babel转义过了🤔但是确实没有被混淆了。估计能过。

结果还是不行。认真看邮件，原来不是说我代码混淆过了。而是说我代码有『混淆』的代码。🤯 这里是指有一些代码是base64的，然后通过base64解密后再eval执行。这怎么可能，我怎么会写这种代码呢?

定位到原因的代码。原来是 Fingerprint 搞的鬼，定位一下issue，问题找到了，Fingerprint 在代码中用了Base64又编码了一些代码。无奈只能退回老版本。

改了之后终于可以比较正常的通过审核了

Firefox 的 插件 ID

Firefox 的拓展是需要一个插件ID的，但是如果你没有给他，其实也是能用的，它会自动分配一个临时ID。但是一定要记的，自己手动分配一个ID。不然就会像我一样惨😭

我这里遇到的问题是如果调用 Storage 相关的 API 就一定不能用自动分配的临时ID，而我在做 Options 页的时候会用到 Storage，但是无奈新旧版本的 ID 不一样，不能更新，只能无奈放弃旧的插件用户，不过幸好 Firefox 的用户还少。不至于让一批用户无法更新。

不同浏览器的API兼容问题

这个主要就是做 Storage，Chrome 和 Firefox 关于插件存储的 API 不一致导致的。 这个通过web polyfill很简单就能解决了。

问题背景

不得不说 Golang 的 DX 做的很舒服，比如在测试有问题的并发代码中会提醒你 Data Race 。这样就不用等你发现数据出问题了，再去找代码的问题。👀 最近开始用的一个很有帮助的工具就是 Goleak。来帮助我们找到泄漏的 goroutine。可以理解成其它语言的线程👀，泄漏意思就是工作做完之后，还有些这个工作开的 goroutine 没有结束。就像申请的内存在使用完之后没有释放一样。

按教程给我的代码测试加个了 goleak 测试。

但是一下测试， goleak 和我说我的代码有 goroutine 泄漏。🤯 我代码有不少并发代码，但是都是用的 sync.WaitGroup 来控制的。没有网上常见的什么 channel 导致的问题，所以我很奇怪为什么会有 goroutine 泄漏的问题。

通过给子函数加单元测试二分查找一下，我很快定位问题的位置，并不是我写的并发代码产生的 goroutine 泄漏。这个泄漏居然产生一个 Http 请求的代码里面。🤯

代码通过简化大概如下 👇

代码:

package httptest

import (
    "net/http"
)

func HttpGet(url string) error {
    resp, err := http.Get(url)
    if err != nil {
        return err
    }
    defer resp.Body.Close()
    return nil
}

测试:

package httptest_test

import (
    "fmt"
    "runtime"
    "testing"

    "github.com/stretchr/testify/assert"
    "go.uber.org/goleak"

    httptest "test"
)

func TestFail(t *testing.T) {
    fmt.Println("开始时goroutine的数量:", runtime.NumGoroutine())

    defer goleak.VerifyNone(t)

    err := httptest.HttpGet("https://raw.githubusercontent.com/Get-Tech-Stack/TechStack/main/package.json")
    assert.NoError(t, err)
    fmt.Println("结束时goroutine的数量:", runtime.NumGoroutine())
}

测试结果: 可以看到结果时的 goroutine 数量比开始时多了一个。说明有一个 goroutine 泄漏了。

开始时goroutine的数量: 2
结束时goroutine的数量: 3
--- FAIL: TestFail (0.52s)
    /Users/ctrdh/zeabur_reproduce/main_test.go:22: found unexpected goroutines:
        [Goroutine 36 in state IO wait, with internal/poll.runtime_pollWait on top of the stack:
        goroutine 36 [IO wait]:
        internal/poll.runtime_pollWait(0x109273fc0, 0x72)
            /opt/homebrew/Cellar/go/1.21.0/libexec/src/runtime/netpoll.go:343 +0xa0
        internal/poll.(*pollDesc).wait(0x140000de480?, 0x140001c2000?, 0x0)
            /opt/homebrew/Cellar/go/1.21.0/libexec/src/internal/poll/fd_poll_runtime.go:84 +0x28
        internal/poll.(*pollDesc).waitRead(...)
            /opt/homebrew/Cellar/go/1.21.0/libexec/src/internal/poll/fd_poll_runtime.go:89
        internal/poll.(*FD).Read(0x140000de480, {0x140001c2000, 0x1300, 0x1300})
            /opt/homebrew/Cellar/go/1.21.0/libexec/src/internal/poll/fd_unix.go:164 +0x200
        net.(*netFD).Read(0x140000de480, {0x140001c2000?, 0x1400018e340?, 0x102242674?})
            /opt/homebrew/Cellar/go/1.21.0/libexec/src/net/fd_posix.go:55 +0x28

如果看到我该 close 的都 close 的🤔，在好几个群里问来问去，我尝试换 URL 之类的还出过几个乌龙。最后谷歌了一下，在 stack overflow 找到了问题所在，这个原因是由于http.Get(url)导致的。第二天另一个 Zeabur 的同学也找到了同样的帖子帮我解决了这个问题。🤣这里不得不感谢 Zeabur 了，经常遇到啥技术问题都发在他们工单群里，他们没有踢掉我不说还经常帮我解决问题。

解决方案

直接上解决该问题之后的代码:

func HttpGet(url string) ([]byte, error) {
    req, err := http.NewRequest("GET", url, nil)
    if err != nil {
        return []byte{}, err
    }
    client := http.Client{}
    resp, err := client.Do(req)
    if err != nil {
        return []byte{}, err
    }
    defer resp.Body.Close()
    defer client.CloseIdleConnections() // <-- 把空闲的连接关闭掉

    result, err := io.ReadAll(resp.Body)
    if err != nil {
        return []byte{}, err
    }

    return result, nil}

这样就能通过测试了。🎉

原因

上面的 Stack overflow 其实也说了这个问题是因为http.Client使用了Transport，而这个会维护一个连接池保持那些kept-alive的连接。所以我们需要在defer里面调用CloseIdleConnections来关闭这些连接。