不要重复发明*！
作者：deep learning
原文链接：http://dwz.date/bSQt
很多大牛推荐我们“造*”，但是造*的目的是为了学习，而不是使用，尤其不要用在生产环境。
正文
造个*很简单，但是你非要把自己的*安在汽车上，开上路，那肯定是一个安全隐患。
有很多人会说，“既然自己可以写一个，为什么非要用别人的？” 还有人觉得，有些非常小的功能不需要使用别人的。
很多人还会借此吐槽 leftpad 模块，但是平心而论，你自己能徒手这一个没有 bug 且高性能的 leftpad 函数吗？
前几天我们项目组就遇到了一次，其实功能很简单，一个页面分享出去，并使用 url 携带参数。
比如：aaa.html?id=123456 看似很简单的一个需求，但是真正自己写一个却不简单。
-
查找“=”字符，然后截取后面的？2. split(“=”)，然后去第二个 3. …… 不到 10 行代码就写完了。
第一次分享到微信是正常，把分享出去的页面再次转发分享，页面错误。
因为微信会在 URL 后面添加一些额外的参数，同样，不同的平台都会有不同形式的添加参数方式，有的加 &，有的加 #，不论加什么都会导致解析的失败。
归根结底是我们写的解析函数有 bug，我们重新造了一个有 bug 的*。
解决方式就是:
npm i qs
麻雀虽小，五脏俱全。看看 github 源码，“百行代码，千行测试”。
绝对比自己写的代码靠谱。这一百行代码很容易写出来，但是作者为了保证这一百行代码没有 bug 而写了几千行的测试代码。
这样的库我们才用着安心。
我写这篇文章不是为了推荐这个 qs 库，而是告诉大家不要重复造*用在生产环境，平时大家多造*用来学习。
阅读更多
B站UP主自制的开源OCR翻译器走红Github，用一次就粉了
重磅！Chrome 高级玩法，不装扩展，提前享受还未发布的功能
相信自己，没有做不到的，只有想不到的
在这里获得的不仅仅是技术！
喜欢就给个“在看”