知识只有在产出地的时候才是最纯正的时候，当它经过其他人的脑子加工转播之后，它就失去了它最纯正的样貌，失去了它本来该有的样子。
我已经忘了我什么时候开始，很少从博客、视频、公众号、帖子、论坛这些平台上学习新的知识了，这并不仅仅是因为我已经成长，更重要的是我发现绝大多数时候这些途径只会让我接触到二手知识。
现在是一个知识大爆炸的时代任何人都可以从互联网上找到新的知识来学习，但因个人的水平差异、认知差异、思想差异等原因造成对其他人的知识产生分歧，以自己加工后的知识重新输出到网上，所以博客、视频、公众号、帖子、论坛等平台都是二手知识的重灾区。
差不多两个月前 go1.23 刚开始发布了，更新了新的标准库
unique，我在检索这个标准库的信息的时候发现了一个介绍
unique 的博客《Golang
1.23: 新的 unique 包》，博客的作者因自身的水平原因没有对
go 有一个很好的认知，对 unique
标准库得出一个十分荒谬的结果，他认为 unique.Make 出来后的
unique.Handle 使用方法 Value 是在对
unique 内部的 map
进行查询访问导致的性能损耗，其根据是他的测试中使用
unique.Handle 与顶级声明的字符串比较的 banchmark
结果与顶级声明的字符串自己与自己对比的 banchmark
结果对比出的结论。
显然博客作者自身能力不足且对 go
的认知不高也没有完整的查看 unique
的源码，才写出这样荒唐的测试来作证他的结论，unique.Make
只是一个从 weak ptr 中创建的普通指针，unique
很快就是因为在做相等运算的时候也只是比较 ptr
来达到的效果，go 在比较这些 string
等结构体包装的类型的时候也是先 比较 struct
中的内容，如果struct中的指针不相等但 len
相等就再比较指针指向的值，这样的优化来快速比较带来的开销。
综上所述，博客中使用 t.Value() == Token 比较慢是因为
t.Value() 得到的字符串中的指针与 Token
字符串中的指针并不相同，所以会比较慢，t == Token
比较快是因为它俩结构体是一样的，所以只比较了结构体。至于为什么存入unique.Make
中的字符串为什么与原来的不一样请自行去查看 unique 的源码。
并不只是这类名不经传的小博客才会有这种误人子弟的二手知识，比如知名的博主阮一峰，他的函数式编程入门，文中对函数和范畴论的错误理解，让人贻笑大方，函数式编程与范畴论并没有多大关系，范畴论也不是只能再函数式编程范式中使用，只要你愿意你可以应用到c语言中，函数式编程范式也并不强调纯，只有纯函数式编程语言才强调纯，即使纯函数式编程语言也只是把不纯和带有副作用的函数规范起来，并不是完全的摒弃了不纯和副作用，real
world
就是不纯的带有副作用的，阮一峰错误的认知把纯函数式编程语言和函数式编程给混淆了，纯函数式编程语言和函数式编程是两个东西，就好比面向对象编程语言和面向对象是两个东西。
知识经过其他人的脑子处理后很大几率会丢失其原有的精度，如果上面举的例子是个人水平和认知的问题以外还有一些“Descriptivist
theory of
names”的人，把原有的语义词义全都改变得面目全非，这类作者喜欢把自己的小聪明带到这上面来彰显自己的能力，这与在写代码中炫技没有任何区别，仿佛让人看不懂，误人子弟就是他们想做的事一样。
但二手知识也并非完全是坏的，当知识原文本身就是晦涩难懂或者以自身目前的能力没办法马上理解的时候也是可以通过别人的二手知识来知道应该怎么去理解这个知识，但要要多方验证地辨别什么二手知识是误人子弟的错误，什么二手知识是信达雅的佳酿。