共计 875 个字符，预计需要花费 3 分钟才能阅读完成。
先说结论
使用 go 开发并且正在使用 logrus 库的小伙伴，请检查你引入的包是不是官方的包。
然后开始细说
import (log "github.com/siruspen/logrus")
func foo() {log.Warningf("bar")
}
我的这两段代码看起来没有什么问题的样子，我就引入了一个日志库 logrus，然后输出了一点日志，能有啥问题。
然而实际上，这段代码没有引入 logrus 官方库，官方库的地址应该是 github.com/sirupsen/logrus
仔细看看，你看出两个地址的区别了吗？
这就是可怕的地方，这两个地址仅仅是其中两个字母的顺序换了一下，但凡输入的时候来个笔误，就引入了非官方库。
目前，这个非官方库仅仅从官方库 fork 了出来，只有两次提交，改了一下包名，添加了一个无关紧要的日志输出。在功能上，和官方库几乎完全一致。即使写错了库名，我也能够正常使用，很难发现我实际上写错了库名。
这就让我想到之前 xz 库被发现的那个供应链攻击，这个仓库现在的行为就很相似，蛰伏，然后等待合适的时机。
也许我只是杞人忧天，说不定这个库就真的只是正常 fork 了一下，名字又正好非常接近，那这样最好不过。不过不管怎么说，本来想引入官方库，结果引入了一个 fork 出来的仓库，总不是什么好事情。用了 logrus 库的小伙伴还是检查一下自己的代码吧。
PS: 这个 fork 出来的库会在初始化的时候 fmt.Println(“INIT!!!”)，一个比较方便的方法是看看自己的程序启动的时候有没有打印 INIT!!!。之前我在本地库里面搜索到了这个输出代码，还暗自吐槽这库这么会有这么不专业的行为，结果原来是我自己的锅。
最后再补充一下我是怎么发现这个问题的。今天 AI 帮我导入了 logrus 库，结果我发现我对 log 输出格式的设置在一些文件里面生效了，在另一些文件里面没生效。最后排查了好久，终于发现原来我引入了两个不同的库。
再顺便说一下，如果 CoPilot 之类的工具会用本地代码去学习的话，我本地好多个引入了错误仓库的代码可能已经被学习进去了，AI 也有可能给你引入错误的库……
