当我们发布新功能时，需要尽可能降低因新功能发布所导致的线上风险，通常会采取灰度放量的方式将新功能逐步发布给用户。在具体实施灰度放量时，我们可以根据业务需求选择相应的放量规则，常见如按白名单放量（如仅 QA 可见）、按特定人群属性放量（如仅某个城市的用户可见）亦或是按用户百分比放量。

当我们选择将功能以用户百分比放量时，如下图所示，会先将功发布给10% 内部用户，此时即便出现问题影响也相对可控，如观察没有问题后逐步扩大需要放量的用户百分比，实现从少量到全量平滑过渡的上线。

那么在 FeatureProbe 上要如何实现百分比放量？

下面将通过一个实际的例子介绍如何通过 FeatureProbe 实现按百分比放量发布一个新功能。

步骤一：创建一个特性开关

接着，配置开关百分比信息。以收藏功能百分比发布为例，设置 10%  的用户可用收藏功能，而另外 90% 的用户无法使用收藏功能。

步骤二：将 SDK 接入应用程序

接下来，将 FeatureProbe SDK 接入应用程序。FeatureProbe 提供完整清晰的接入引导，只需按照步骤即可快速完成 SDK 接入。

1、选择所使用的 SDK

2、按步骤设置应用程序

3、测试应用程序 SDK接入情况

步骤三：按百分比放量发布开关

开关信息配置和 SDK 接入都完成后，点击发布按钮并确认发布。这将会将收藏功能发布给用户，但只有10%的用户可以使用收藏功能。

如果希望逐步扩大灰度范围，可以在开关规则中配置百分比比例。

大部分情况下，我们希望在一个功能的灰度放量过程中，某个特定用户一旦进入了灰度放量组，在灰度比例不减少的情况下，总是进入灰度组。不希望用户因为刷新页面、重新打开APP、请求被分配到另一个服务端实例等原因，一会看到新功能，一会看不到新功能，从而感到迷惑。要达到用户稳定进入灰度组，只需要在上述代码第三步创建 User 时指定stableRollout 即可，具体使用详情见：docs.featureprobe.io/zh-CN/tutor…

总结

灰度按百分比放量是一种软件开发中常用的功能发布方法，它可以帮助提高软件可靠性，提高用户体验，在实施时也需要注意几个方面：

1、确定放量目标：首先需要确定放量的目标，例如增加多少百分比的数据量。这个目标需要根据实际情况进行制定，例如需要考虑数据量的大小、计算资源的限制等因素。

2、确定放量规则：你需要确定在放量过程中，哪些功能会被启用，哪些功能会被禁用。你可以根据开发进度、测试结果和市场需求等因素来确定放量规则。

3、监控放量过程：在实施放量操作时，需要监控放量过程，以确保放量结果的稳定性和可靠性。如果出现异常情况，需要及时采取措施进行调整。

若要了解有关FeatureProbe 灰度发布的更多信息，请查看其官方文档中的教程。该教程可以提供关于如何进行灰度发布的详细说明。文档中还包括其他相关主题的信息，例如如何进行服务降级和指标分析等。请访问以下链接以查看该文档：docs.featureprobe.io/zh-CN/tutor…

关于我们

FeatureProbe 是国内首家功能开关管理开源平台，它包含了灰度放量、AB实验、实时配置变更等针对『功能粒度』的一系列管理操作，完全开源，可以放心直接使用。

当前 FeatureProbe 作为一个功能开关管理平台已经使用 Apache 2.0 License 协议完全开源，你可以在 GitHub 和 Gitee 上访问源码，你也可以在上面给提 issue 和 feature 等。

GitHub: github.com/FeatureProb…

Gitee: gitee.com/featureprob…

体验环境: featureprobe.io/

过去这两年里完成管理角色转型，完成了移动端工程化建设，养成了早睡早起的习惯，还戒了烟，也看了不少书，学会了羽毛球，但这些都不是最重要的。

3月意料之中的最后裁员到来了，在充分了解个人意愿后留下两个不想看新工作的小伙伴，IOS Android各一个。我把自己也写进了名单，跟其他能力相对强一点的一起出来了。回顾过去2年我们做的事情，我对大家还是蛮有信心的。同时基于对《钱》这本书的学习，我从前两年开始就一直留有1年以上的备用金，所以暂时也没太大经济压力，不至于因为囊中羞涩着急找一份谋生的工作。

刚离开公司的前两周，先花了1000多找了两个职业咨询师，了解目前的招聘环境，招聘平台，招聘数据，以及针对性的帮助我修改简历。都准备好以后，开始选公司试投简历，认真看完大部分JD后大概清楚自己的能力所匹配的公司，薪资范围。机会确实不多，移动端管理岗位，架构岗位就更少，尤其是像我这样工作不到10年，架构跟管理经验都还未满5年的人，选择更是寥寥无几。

先后参加了两个2面试，一个是小团队的移动 TL，在了解后双边意向都不大。另一个是 Android 架构方向。虽然拿了offer，薪资包平移，但我最终没去。一是发生了一点小误会，发offer前电话没告诉我职级，我以为架构岗过了其实没有，差一点点到P7。回看面试记录，提升并不困难，有能力冲一冲的，这一次并不会影响我的信心。

另一个则是我真的冷静下来了，也就有了这篇文章。

在这两周里，陆续写了一些文章，做了一些开源项目。完全是出于助人为乐回馈社区，没想到也因此结识了几个做阅读业务的同学，纷纷向我抛来橄榄枝。其中包含一个已经在行业内做到Top3的产品。这让我有些受宠若惊，毕竟我觉得我给的技术方案并非有很大门槛，只是运气好站在巨人的肩膀上想到了不同的方案而已。

正是这些非常正面的反馈，帮助我消化了很大一部分所谓的焦虑（难说我本身一点不受环境影响）。在Zhuang的帮助下，我大概做了两次自我梳理，最后在前几天我从地铁回家大概3km的步行中想明白了很多事情。

每次出去旅游时，比如我躺在草原上，看着日落，说实话我欣赏不了10分钟。因为我的思绪停不下来，我就会去想一些产品或者是管理方面的问题。我很爱工作，或者说喜欢工作时可以反复获取创造性的快乐，比如做出一个新的技术方案或者优化工作流程解决一个团队问题，都让人很兴奋。但现在，我想强迫自己来思考一些更长期的事情。

我的30岁，难而且正确的事情是什么？

是找一份工作吗？这显然不难，作为技术人，找一份薪资合理的工作不难，这恰恰是最容易的

是找一份自己喜欢的工作吗？这有一点难，更多的是需要运气。职业生涯就十几年，有几次选择的机会呢？这更多的是在合理化自己对稳定性，舒适性的追求，掩盖自己对风险的逃避。

是找一个自己喜欢的事情，并以此谋生吗？这很难，比如先找到自己长期喜欢长期坚持投入的事情就很难，再以此谋生就需要更多的运气与常年积累去等待这个运气出现，比如一些up主。这可以是顺其自然的理想，但不适合作为目标。

上面似乎都是一个个的问题，或者说看到这些问题的时候我就看到了自己的天花板了。因为我可以预见我在这些方向上的学习能力，积累速度，成长空间，资源储备。

这半年涌出了太多的新事物，像极了02年前后的互联网，14前后的移动互联网。我从去年12月5日开始使用GPT，帮助我提高工作，学习效率，帮助我做UI设计，帮助我改善代码，甚至帮助我学习开网店时做选品，做策略，可以说他已经完全融入我的工作学习了。

开发自己的GPT应用要仔细阅读OPEN AI 的API，我再次因为英语的理解速度过慢严重影响学习效率，即使是有众多实时翻译软件帮助下丝毫不会有所改善。

翻译必然会对原文做二次加工，翻译的质量也许很高，甚至超过原文，但这样意味着阅读者离原文越远。

比如我在Tandem上教老外“冰雪聪明”这个词的意思，我很难解释给她，更多的是告诉她这个词在什么场景用比较恰当，比“聪明”更高级。但是如果用翻译软件，这个词会变着花样被翻译成“很聪明”，美感全无。

在Tandem跟人瞎聊时以涉及复杂事件就词穷，直到认识了一个 西班牙的 PHD 与另一个 印尼的大学生，她们帮我找到了关键点，基础语法知识不扎实，英语的思维不足。有些时候他们会说我表达的很棒，口语也行，有些时候他们会说我瞎搞。其实很好理解，就像他们学中文一样，入门也不难，难的是随意调动有限的词汇自由组织句子进行表达，而不是脑子里先想一个母语再试着翻译成外语，难的是在陌生场景下做出正确的表达，能用已经学的知识学习新知识，也就是进入用英语学习英语的阶段。

另外一个例子就是做日常技术学习的时候，尤其是阅读源码的时候，往往是不翻译看懂一部分注释，翻译后看懂一部分，两个一结合就半懂不懂，基于这个半懂不懂的理解写大量测试去验证自己的理解，反推注释是否理解正确，这个过程非常慢，效率极低。

这就是为什么很多东西需要依赖大佬写个介绍文档，或是翻译+延伸解释之后才能高效率学习，为什么自己找不到深入学习的路径，总是觉得前方有些混沌。

记得在刚入行的前几年写过一篇学习笔记，把自定义view 在view层测量相关的代码中的注释，变量名称整个都翻译了，备注2进制标记位变化结果，再去理解逻辑就非常简单了。跟读小说没啥区别（读Java代码就像读小说，我一直这么觉得），很快就理解了。但这个过程要花太多时间了，多到比别人慢10倍不止。

所以这第一个难而正确的事情是学习英语

达到能顺畅阅读技术资料与代码的地步，才能提高我在学习效率上的天花板。

第二个是有关生活的事情，增加不同的收入手段，主业以外至少赚到1块钱

裁员给我最大的感触就是，我很脆弱，我的职业生涯很脆弱，我的生存能力很脆弱，不具备一点反脆弱性。如果没有工作我就没有任何收入，只要稍微发生一点意外，就会面临巨大的经济压力，对于我和家庭都会陷入严重的经济困难中。

市场寒冬与我有关但却不受我影响，我无法改变。同时平庸的职业经历在行业内的影响微乎其微，大佬们是不管寒风往哪吹的，他们只管找自己想做的方向，或者别人找到他们。

我就认识这样的大佬，去年让我去新公司负责组新团队，连续一两周持续对我进行电话轰炸，因为当时正负责的团队处于关键期，我有很深的“良知”情节，我婉拒了，这是优点也是缺点。

而我只有不断提高自己的能力，让人觉得有价值才能持续在这个行业跟关系网里谋生。

但是我知道，大风之下我依然是树叶，我不是树枝，成为树枝需要天时地利人和。就像在公司背小锅的永远都是一线，因为如果是管理层背锅那公司就出了决策性的大问题了，对公司而言已然就是灾难。

这几周陆续跟很多人聊了各种事情，了解他们在做什么。有双双辞职1年多就在家做私活忙得不亦乐乎，有开网店有做跨境电商的，也了解了很多用Chat GPT,Midjourney 等AI工具做实物产品在网上卖的。包括去年了解的生财有术知识星球等等，真的花心思去了解，打开知识茧房确实了解到非常多不同的方向，有一种刘姥姥进大观园的感觉。

自己做了一些实际尝试，跑了下基本流程，确实有一些门槛但各不相同。同时在这个过程中，又因为英语阅读效率低而受阻，文档我也是硬看，不懂的词翻译一下，理解不透再整句翻译，再倒回来看原文。

比如网上midjourney的教程一大把，其实大多数都不如看midjourney官方文档来的快，我从看到用到商品上架，不过几个小时，这中间还包括开通支付跟调整模型。

至于赚到1块钱，有多难呢，当我试了我才有所体会。

种一棵树最好的时间是在10年前，其次是现在。

继续保持在社区的输出，保持技术学习。休假我都不会完全休息，Gap 中当然也不会。

后记

去年公司陆续开始裁撤业务线，有的部门直接清零，公司规模从几千人下降到千人以内不过是几个月的事情，有被裁的，也有为了降低自身风险而主动走裁员名单，这也是双赢的解决方案，公司能精简人员个人可以拿到赔偿。管理层的主要工作是尽力留下核心成员，温和的送走要离开的成员，最大程度降低团队的负面情绪，做人才盘点，申请HC做些人力补充，减少团队震动保障项目支撑。没错，一边裁员一边还会招人。

彼时我个人也才刚刚在管理岗上站稳脚跟不久，团队里没有人申请主动离职算是对我挺大一个宽慰。有的团队人员流失率接近70%，相比之下我压力小得多，但我依然要交出一个名字给到部门负责人。我当然很不舍同时也为他们担忧，过去一年多大家一起相互成长，很多人也才刚刚步入新职级。

我努力寻找第三选择，功夫不负有心人，之前做过的一个项目独立出去了，成立了独立的子公司运营，新团还没搭建完。当时跟那个项目团队的产品，后端负责人配合得相当不错，我便以个人的背书将一个曾重点负责过这个项目的成员推荐过去，加上直属上级的帮助，最终在所有HC都要HRD审批的环境下平滑的将裁员变成了团队调配。现在即使我离开了母公司，他们小团队依然还不错，没有受到后续裁员影响。这位小伙伴人特别实在，他是我见过执行里最强的人，他值得这样的好运气。

作为管理者，我有些单纯的善意，不满足于工作层面的帮助。因为我觉得个人能量实在是太小了，而未来无人知晓。

作为核心部门虽然裁员的影响波及较为滞后，但明显的感觉还是研发压力骤减，加上公司为了早点达到账面盈亏平衡，对部分薪资采取缓发，在这样的背景下整个部门的氛围变了，需求评审得过且过，项目质量得过且过，此类情况比比皆是，工作的宽容度也一再升高。

作为个人来讲这真是躺平型工作，工作任务骤减但薪资还照样发，绩效照发，每天到公司跟去上学一样。我心里就出现了一个声音「你喜欢在这里继续混吗？这里如此安逸」。

今年3月意料之中的新一轮裁员到来，我几乎没有犹豫就答复了部门负责人。团里谁想留下谁不想留我很清楚，过去我们一直也保持比较健康的氛围，始终鼓励能力强的人出去看看，也明确告知留下来与出去将面临的不同风险。大家都有心理准备，但大家都没有懈怠自己的学习，技术目标按部就班，丝毫没有陷入负面漩涡，偶尔还会因为讨论技术问题忘记下班时间。

这一次，我把自己放在了名单上，当然这并不突然。我与部门负责人一直保持着较高的工作沟通频率，就向上管理这一点上，我自认做得非常不错。

离职后大家都积极找工作，我对他们非常有信心，抛开头部大厂，中厂依然是他们的主阵地，他们在各自专精的领域里技术都很扎实，尤其是去年大家一起补足了深层次的网络层知识。不出意料部分人都很快拿了offer，有的更是觉得不想面试了匆匆就入职了，这我就不行使自己好为人师的毛病了。

滑到底部可点赞评论

浏览橘子树其他文章：橘子树的飞书写作记录

作者：橘子没
来源：juejin.cn/post/7224068169341763643

(背景应景吗铁铁们)

🎤: 可以讲讲在北京这几年的经历吗？

  🙍‍♂️:5年多，算是大小厂都经历过了，大概是小-大-中的一个顺序，刚毕业的时候去了一家做线下教育的小公司，现已倒闭。
   后来去到了阿里的一个边缘业务，当不当正不正吧，那段时间我尽可能的提升自身的认知水平，想要跟上各位大佬们的思维，讲真，有的时候P8领导给我们开会，我get不到大部分会议内容的核心点和他表达的东西，最后让我明白了人和人之间的差距真的可能这一生都追赶不上。
   再后来就去到了一家中小厂吧，老板较有知名度，做知识服务的，在这里度过了我最后的北漂时光。

🎤: 在北京一定学习到了很多东西吧，最大的收获是什么？

  🙍‍♂️:这倒是不假，毕竟是帝都，确实让我见识到了很多很多新的东西和形形色色的人们，这是不曾在老家可以看见的。
   至于学习吧，我本身是一个很少会去主动学习的人，更多的情况是在工作需要，我才会去学习。所以不能说没有长进，只能说略微缓慢，但是我并没有觉得自己很差劲。还有一些生活技能，最多的就是做饭。
   除了自身的成长以外，要说最大的收获，我必须要很诚实的说，是一些精神问题，曾经有很长一段时间，甚至是到至今，我被自己内心的焦虑所控制，对自我有无数个疑问。我曾经因为一个需求难搞以至于我做梦都在梦我如何去写它的代码；无数次的凌晨钉钉或是飞书群的@消息，我一般是第二天起床才看到，但是看到那些的瞬间我头疼欲裂胸口紧缩。我的内心会一直问：“为什么？为什么不能让我睡一个好觉或者是起一个好早。”，大城市的节奏之快让我睁眼的第一件事就是想到工作，或者是带着工作入眠，开玩笑，入不了，根本入不了。种种原因吧，可能是我心态的问题，所以决定回到老家也是为了尽可能的调整一下自己的心态。

(自己做的炒鸡蛋和葱爆肉)

🎤: 在北京一定有攒钱吧？

  🙍‍♂️:攒钱是攒了一些，但是没有很多。当我真正开始月薪过万的时候，对于一个从来没有见过5位数进账的人来讲，我开始了一种报复性消费，我把之前不敢买的东西几乎都买了，游戏也充了很多钱，每个月都会买衣服和鞋，甚至如果有的东西我想要但是手里的钱不够，我也会分期买，前两年的消费很夸张，而且从来不记账，现在回想起来那时候真的是虚荣的、丑陋的。(仅对我个人而言)
   真正开始攒钱的时候是从我的女朋友来到北京找我开始，我们感情很好，所以就像两个人正常的在一起生活一样，总是要为生活和未来买单的，于是我每个月发完工资都会经过她的计算后留下基本的生活费，然后全部转给她，她掌管家里的财政，很让我安心。就这样后几年算是攒下了一笔小钱。
   在我的理解是爱情更多还是要责任更多一些吧，所以我不会觉得让我不再乱花钱也是一种约束。

🎤: 真正让你决定离开北京的原因是什么？

  🙍‍♂️:没有能绝对决定的原因，只有能压垮的最后一根稻草。
   从刚来北京的奋斗b到现在只想摆烂躺平的我是一个长期的心态上的变化。我最终得出一个结论：这里不适合我，或者说，我不适合它。 影响比较大的几件事都集中在了22年，三件事：
   1. 回家过年
   2. 奶奶过世
   3. 公司裁员
   这三件事贯穿了我整个2022年，可以说是一连串的事情打得我措手不及。于是经过了多次自我内心的审视、对答后，在过完23年的春节后，我做了这个决定，我要离开这里了。 电影的主角们总会说：“What does not kill me, makes me stronger.”，但是对于我来说，可以打倒我的东西太多了，我自认普通且平凡。

I just wanna be free.

🎤: 离开后你都做了些什么呢？

  🙍‍♂️:2月下旬开始处理离职交接的一些事情，同时还有面试一些老家那边的公司，然后租房子，收拾行李。每天真的是累到倒床就睡，感觉这次跨省搬家元气大伤、身心俱疲，掉了半条命一样。
   好在和女朋友的规划下，把时间节点安排的刚刚好，2月末把这些事儿都处理好了之后，3月初我和女朋友就开始了一周的云南之行，我俩称之为：心灵救赎之旅。
   路线是丽江-大理-西双版纳，选择去云南是因为我们马上要回到东北，以后像这种东北到西南斜跨全国的旅游机会应该没几次了...让我印象最深刻的是丽江，我最大的感觉就是：纯净(我着实是没有文本功底)。无论人、山、水、云，大家生活在这里，仿佛一片世外桃源。

(丽江的云，是让我觉得离自由和奶奶最近的时候)

🎤: 回到东北后感觉怎么样？

  🙍‍♂️:先说工作吧，我目前在大连一家做车载车机的小公司，因为之前没有做过这类工作，所以最近也是在学习一些相关的知识，在这里真的要特别感谢一位大佬：林栩link，他的文章对于我来说很有帮助。然后工资对于我来讲还算可观，因为对大连这边的就业环境不是很了解，先在这里稳一稳吧。
   我租的房子和公司在一条街上，距离不到300m，每天中午还可以回家吃口饭歇一歇。工作时间的话是早8点半到晚5点半，目前一个月我没有加过班，到点就走了(而且是同事们几乎都这样)，晚上和女朋友一起做饭，之后可以去市中心或者是海边溜达一圈，时间非常充足，周末的话会叫上朋友到家里吃饭或者是一起出去玩。
   距离我的老家鞍山也更近了一些，我妈说我自从回来了之后，她总有一种心里的石头落地了的感觉，我没事儿的时候就会和女朋友在周五晚上坐3个半小时的绿皮回去，然后周日的晚上再坐回来，回家吃自己爱吃的东西。
   算是找到了那种安安静静上班，认认真真生活的感觉。
   说这么多是因为这是我在北京这么多年从未体会过的生活，实在是没有发现生活的多样性(可能也是因为没钱吧hhh)。

(星海广场的灯光秀)

🎤: 未来有什么样的规划？

  🙍‍♂️:哈哈，想在2年内和女朋友领证结婚，首付买一套小房子和一台小鹏G3i或者是零跑C11。然后多去了解了解这边的市场，在这么多空余的时间去计划搞一些副业(万一以后能干成主业呢)。

🎤: 想说的话。

  🙍‍♂️:嗯...看了很多大佬的年终总结，收获颇多，于是也想自己去写出一些东西，表达一下，哈哈哈。
   如果让我来总结自己的每一年的话，我好像只能说：还行、凑合、就那样，又不温不火的过了一年。但是我很喜欢一句话：空想都是问题，落笔皆为答案。不论好坏对错，都是我选择的答案，可能以后还会遇到相同或者不同的问题，只要不会停滞不前就好了。
   最后欢迎大家来找我一起讨论玩耍摸鱼~ 祝好！

我们生來自由，所以希望我们都有勇气选择自由。

背景

五一就要来了，本来准备去淄博吃烧烤，结果发现根本抢不到机票。了解了一下原因，原来是黄牛的恶意爬虫把票都抢完了，现在买票，只能通过黄牛的渠道，多花几倍的钱来买了。

有鉴于此，想试试能不能针对这种爬虫防止相关问题，当然是站在航空公司的角度，就个人而言，躺平任嘲就得了。

恶意爬虫的相关特征

对于恶意爬虫的特征，航空公司自己有总结：

1、访问的目标网页比较集中：“爬虫”代理人目标明确，主要是爬取班次、价格、数量等核心信息，因此只浏览访问几个固定页面，不访问其他页面。

**2、查询订票等行为很有规律：**由于“爬虫”是程序化操作，按照预先设定的流程进行访问等，因此呈现出毫无思维、但很有规律、有节奏且持续的行为。

3、同一设备上有规模化的访问和操作：“爬虫”的目的是最短时间内抓取最多信息，因此同一设备会有大量离散的行为，包括访问、浏览、查询等。

**4、访问来源IP地址异常：**正常情况下用户在查询、购买时，用户的IP地址比较稳定，而且访问来源IP比较；“爬虫”、“虚假占座”等操作时，IP来源地址呈现不同维度上的聚集，而且浏览、查询、购票等操作时不停变化IP地址。

5、设置UA模拟浏览器和频繁使用代理IP：很多“爬虫”程序伪装成浏览器进行访问，比如在程序头或者UA中默认含有类似python-requests/2.18.4等固定字符串；并且通过购买或者租用的云服务、改造路由器、租用IP代理、频繁变更代理IP等进行访问。

6、操作多集中非业务时间段：“爬虫”程序运行时间多集中在无人值守阶段。此时系统监控会放松，而且平台的带宽等资源占用少，爬虫密集的批量爬取不会对带宽、接口造成影响。以下是顶象反欺诈中心监测到，凌晨1-5点是恶意“爬虫”的运行高峰时段。

浅谈防范措施

1.设备指纹的应用

设备指纹单独用的话，在恶意爬虫面前，会稍微较弱一些。因为攻击者会使用其他技术手段来绕过设备指纹的检测，例如使用虚拟机、代理服务器等来隐藏真实设备的指纹。所以可以考虑结合IP地址限制一起使用：

import fingerprintjs2

from flask import Flask, request, abort



app = Flask(__name__)



# 创建一个新的Fingerprint2实例

fp = fingerprintjs2.Fingerprint2()



# 白名单IP地址

IP_WHITELIST = ['127.0.0.1', '192.168.0.1']



@app.route('/book-flight')

def book_flight():

    # 获取设备指纹和IP地址

    device_fingerprint = fp.get()

    ip_address = request.remote_addr



    # 检查IP地址是否在白名单中

    if ip_address not in IP_WHITELIST:

        abort(403)



    # 其他业务逻辑代码...

    return "Flight booked successfully!"



if __name__ == '__main__':

    app.run()

2. 人机验证

人机验证肯定是一个阻挡办法，但是在这种恶意强攻击的情况下，我们可以试试语音验证码（但是可能对用户体验不大友好）：

from flask import Flask, request, jsonify

import random

from io import BytesIO

from captcha.audio import AudioCaptcha



app = Flask(__name__)



# 生成随机字符串作为验证码

def random_string(length):

    pool = 'abcdefghijklmnopqrstuvwxyz0123456789'

    return ''.join(random.choice(pool) for i in range(length))



# 生成语音验证码

def generate_audio_captcha():

    captcha = random_string(4)

    audio = AudioCaptcha().generate(captcha)

    return captcha, audio



# 创建一个全局变量，用于保存已生成的语音验证码

captcha_cache = {}



@app.route('/audio-captcha')

def audio_captcha():

    # 生成新的语音验证码

    captcha, audio = generate_audio_captcha()

    

    # 将验证码保存到缓存中，以便后续验证

    captcha_cache[captcha] = True

    

    # 返回语音验证码

    response = BytesIO(audio.read())

    response.headers['Content-Type'] = 'audio/wav'

    return response



@app.route('/book-flight', methods=['POST'])

def book_flight():

    # 获取表单中的验证码

    captcha = request.form['captcha']

    

    # 检查验证码是否正确

    if captcha not in captcha_cache:

        return 'Invalid captcha!'

    

    # 其他业务逻辑代码...

    return "Flight booked successfully!"



if __name__ == '__main__':

    app.run()

因为对用户体验不大友好，研发同学在设计的时候，最好考虑一下它的易用性和可访问性问题。需要权衡用户体验和恶意爬虫。

结语

“天下熙熙皆为利来，天下攘攘皆为利往。”因为这一块存在着巨大的利益，也就一直吸引着无数黑客从中牟利，而我们能做的，是“魔高一尺道高一丈”，希望能为安全世界尽一份力。

说个事情：滑动验证码 免 费

作者：shichuan

文末彩蛋等你揭晓 🤫

前言

在实际的开发工作过程中，积累了一些常见又超级好用的 Javascript 技巧和代码片段，包括整理的其他大神的 JS 使用技巧，今天筛选了 9 个，以供大家参考。

1、动态加载 JS 文件

在一些特殊的场景下，特别是一些库和框架的开发中，我们有时会去动态的加载 JS 文件并执行，下面是利用 Promise 进行了简单的封装。

function loadJS(files, done) {

  // 获取head标签

  const head = document.getElementsByTagName('head')[0];

  Promise.all(files.map(file => {

    return new Promise(resolve => {

      // 创建script标签并添加到head

      const s = document.createElement('script');

      s.type = "text/javascript";

      s.async = true;

      s.src = file;

      // 监听load事件，如果加载完成则resolve

      s.addEventListener('load', (e) => resolve(), false);

      head.appendChild(s);

    });

  })).then(done);  // 所有均完成，执行用户的回调事件

}



loadJS(["test1.js", "test2.js"], () => {

  // 用户的回调逻辑

});

上面代码核心有两点，一是利用 Promise 处理异步的逻辑，而是利用 script 标签进行 js 的加载并执行。

2、实现模板引擎

下面示例用了极少的代码实现了动态的模板渲染引擎，不仅支持普通的动态变量的替换，还支持包含 for 循环，if 判断等的动态的 JS 语法逻辑，具体实现逻辑在笔者另外一篇文章《面试官问：你能手写一个模版引擎吗？》做了非常详详尽的说明，感兴趣的小伙伴可自行阅读。

// 这是包含了js代码的动态模板

var template =

'My avorite sports:' +

'<%if(this.showSports) {%>' +

    '<% for(var index in this.sports) {   %>' +

    '<a><%this.sports[index]%></a>' +

    '<%}%>' +

'<%} else {%>' +

    '<p>none</p>' +

'<%}%>';

// 这是我们要拼接的函数字符串

const code = `with(obj) {

  var r=[];

  r.push("My avorite sports:");

  if(this.showSports) {

    for(var index in this.sports) {

      r.push("<a>");

      r.push(this.sports[index]);

      r.push("</a>");

    }

  } else {

    r.push("<span>none</span>");

  }

  return r.join("");

}`

// 动态渲染的数据

const options = {

  sports: ["swimming", "basketball", "football"],

  showSports: true

}

// 构建可行的函数并传入参数，改变函数执行时this的指向

result = new Function("obj", code).apply(options, [options]);

console.log(result);

3、利用 reduce 进行数据结构的转换

有时候前端需要对后端传来的数据进行转换，以适配前端的业务逻辑，或者对组件的数据格式进行转换再传给后端进行处理，而 reduce 是一个非常强大的工具。

const arr = [

    { classId: "1", name: "张三", age: 16 },

    { classId: "1", name: "李四", age: 15 },

    { classId: "2", name: "王五", age: 16 },

    { classId: "3", name: "赵六", age: 15 },

    { classId: "2", name: "孔七", age: 16 }

];



groupArrayByKey(arr, "classId");



function groupArrayByKey(arr = [], key) {

    return arr.reduce((t, v) => (!t[v[key]] && (t[v[key]] = []), t[v[key]].push(v), t), {})

}

很多很复杂的逻辑如果用 reduce 去处理，都非常的简洁。

4、添加默认值

有时候一个方法需要用户传入一个参数，通常情况下我们有两种处理方式，如果用户不传，我们通常会给一个默认值，亦或是用户必须要传一个参数，不传直接抛错。

function double() {

    return value *2

}



// 不传的话给一个默认值0

function double(value = 0) {

    return value * 2

}



// 用户必须要传一个参数，不传参数就抛出一个错误



const required = () => {

    throw new Error("This function requires one parameter.")

}

function double(value = required()) {

    return value * 2

}



double(3) // 6

double() // throw Error

listen 方法用来创建一个 NodeJS 的原生 http 服务并监听端口，在服务的回调函数中创建 context，然后调用用户注册的回调函数并传递生成的 context。下面我们以前看下 createContext 和 handleRequest 的实现。

5、函数只执行一次

有些情况下我们有一些特殊的场景，某一个函数只允许执行一次，或者绑定的某一个方法只允许执行一次。

export function once (fn) {

  // 利用闭包判断函数是否执行过

  let called = false

  return function () {

    if (!called) {

      called = true

      fn.apply(this, arguments)

    }

  }

}

6、实现 Curring

JavaScript 的柯里化是指将接受多个参数的函数转换为一系列只接受一个参数的函数的过程。这样可以更加灵活地使用函数，减少重复代码，并增加代码的可读性。

function curry(fn) {

  return function curried(...args) {

    if (args.length >= fn.length) {

      return fn.apply(this, args);

    } else {

      return function(...args2) {

        return curried.apply(this, args.concat(args2));

      };

    }

  };

}



function add(x, y) {

  return x + y;

}



const curriedAdd = curry(add);



console.log(curriedAdd(1)(2)); // 输出 3

console.log(curriedAdd(1, 2)); // 输出 3

通过柯里化，我们可以将一些常见的功能模块化，例如验证、缓存等等。这样可以提高代码的可维护性和可读性，减少出错的机会。

7、实现单例模式

JavaScript 的单例模式是一种常用的设计模式，它可以确保一个类只有一个实例，并提供对该实例的全局访问点，在 JS 中有广泛的应用场景，如购物车，缓存对象，全局的状态管理等等。

let cache;

class A {

  // ...

}



function getInstance() {

  if (cache) return cache;

  return cache = new A();

}



const x = getInstance();

const y = getInstance();



console.log(x === y); // true

8、实现 CommonJs 规范

CommonJS 规范的核心思想是将每个文件都看作一个模块，每个模块都有自己的作用域，其中的变量、函数和对象都是私有的，不能被外部访问。要访问模块中的数据，必须通过导出（exports）和导入（require）的方式。

// id：完整的文件名

const path = require('path');

const fs = require('fs');

function Module(id){

    // 用来唯一标识模块

    this.id = id;

    // 用来导出模块的属性和方法

    this.exports = {};

}



function myRequire(filePath) {

    // 直接调用Module的静态方法进行文件的加载

    return Module._load(filePath);

}



Module._cache = {};

Module._load = function(filePath) {

    // 首先通过用户传入的filePath寻址文件的绝对路径

    // 因为再CommnJS中，模块的唯一标识是文件的绝对路径

    const realPath = Module._resoleveFilename(filePath);

    // 缓存优先，如果缓存中存在即直接返回模块的exports属性

    let cacheModule = Module._cache[realPath];

    if(cacheModule) return cacheModule.exports;

    // 如果第一次加载，需要new一个模块，参数是文件的绝对路径

    let module = new Module(realPath);

    // 调用模块的load方法去编译模块

    module.load(realPath);

    return module.exports;

}



// node文件暂不讨论

Module._extensions = {

   // 对js文件处理

  ".js": handleJS,

  // 对json文件处理

  ".json": handleJSON

}



function handleJSON(module) {

 // 如果是json文件，直接用fs.readFileSync进行读取，

 // 然后用JSON.parse进行转化，直接返回即可

  const json = fs.readFileSync(module.id, 'utf-8')

  module.exports = JSON.parse(json)

}



function handleJS(module) {

  const js = fs.readFileSync(module.id, 'utf-8')

  let fn = new Function('exports', 'myRequire', 'module', '__filename', '__dirname', js)

  let exports = module.exports;

  // 组装后的函数直接执行即可

  fn.call(exports, exports, myRequire, module,module.id,path.dirname(module.id))

}



Module._resolveFilename = function (filePath) {

  // 拼接绝对路径，然后去查找，存在即返回

  let absPath = path.resolve(__dirname, filePath);

  let exists = fs.existsSync(absPath);

  if (exists) return absPath;

  // 如果不存在，依次拼接.js,.json,.node进行尝试

  let keys = Object.keys(Module._extensions);

  for (let i = 0; i < keys.length; i++) {

    let currentPath = absPath + keys[i];

    if (fs.existsSync(currentPath)) return currentPath;

  }

};



Module.prototype.load = function(realPath) {

  // 获取文件扩展名，交由相对应的方法进行处理

  let extname = path.extname(realPath)

  Module._extensions[extname](this)

}

上面对 CommonJs 规范进行了简单的实现，核心解决了作用域的隔离，并提供了 Myrequire 方法进行方法和属性的加载，对于上面的实现，笔者专门有一篇文章《38 行代码带你实现 CommonJS 规范》进行了详细的说明，感兴趣的小伙伴可自行阅读。

9、递归获取对象属性

如果让我挑选一个用的最广泛的设计模式，我会选观察者模式，如果让我挑一个我所遇到的最多的算法思维，那肯定是递归，递归通过将原始问题分割为结构相同的子问题，然后依次解决这些子问题，组合子问题的结果最终获得原问题的答案。

const user = {

  info: {

    name: "张三",

    address: { home: "Shaanxi", company: "Xian" },

  },

};



// obj是获取属性的对象，path是路径，fallback是默认值

function get(obj, path, fallback) {

  const parts = path.split(".");

  const key = parts.shift();

  if (typeof obj[key] !== "undefined") {

    return parts.length > 0 ?

      get(obj[key], parts.join("."), fallback) :

      obj[key];

  }

  // 如果没有找到key返回fallback

  return fallback;

}



console.log(get(user, "info.name")); // 张三

console.log(get(user, "info.address.home")); // Shaanxi

console.log(get(user, "info.address.company")); // Xian

console.log(get(user, "info.address.abc", "fallback")); // fallback

上面挑选了 9 个笔者认为比较有用的 JS 技巧，希望对大家有所帮助。

🎁 文末彩蛋 >>

码上掘金编程比赛火热进行中，同时为大家推出「报名礼 & 完赛奖」活动～

报名即有机会瓜分上百万掘金矿石奖池！提交作品更可参与精美奖品的抽取哦！

🎁 抽奖攻略请戳这里

🎡 更多大赛特别活动请看这里

扫码关注公众号 👆 追更不迷路

我报名参加金石计划1期挑战——瓜分10万奖池，这是我的第2篇文章，点击查看活动详情

前言

事情是这样的，由于七八月份的晚上时不时就坐在地摊上开始了喝酒撸串的一系列放肆的长肉肉项目。
这不，前段时间女朋友痛下决心（心血来潮）地就去报了一个健身的私教班，按照教练给的饮食计划中，其中有一项是每天需要喝 2.6L 的水来促进体内的新陈代谢。
作为伴侣肯定要十分支持的呀，不过因为平时工作也是十分费脑筋的，不会专门去记录每天喝了多少水，特别容易忘记。所以做了这个喝水记录本给她。

开发需求

整体的开发需求和前言里描述的差不多，整体功能拆分一下就非常清晰了。

一、定义变量

1. 大杯子：我们需要一个总量目标，用于定义每天的计划值。


2. 小杯子：一个单次目标，我们不会一次接一大桶水来喝，即使用小杯子喝水时，每个杯子的刻度值。

二、逻辑整合

1. 点击每个小杯子时，从大杯子的总量中扣除小杯子的刻度并记录，对应UI水位升高。


2. 首次点击小杯子时，展示百分率刻度值，提升水位。


3. 当完成目标值后，隐藏剩余水量的文字。


4. "清空"按钮，消除本地记录值，恢复UI水位，展示剩余量。

创建流程和主要代码

 此模块代码是应用于小程序使用的，所以代码部分使用wx框架。（下面有普通代码部分）

wxml

构造整体布局，布局和制作大杯子和小杯子。

在上一段开发需求部分中提到的隐藏内容时，注意不要使用 wx:if 直接删除整个标签，这样会导致画面跳动，无法实现动画的平滑过渡。

用三元运算符隐藏文字可以实现较好的过渡

<view class="body">

  <text class="h1">喝水记录本</text>

  <text class="h3">今日目标: 2.6升 </text>



  <view class="cup">

    <view class="remained" style="height: {{remainedH}}px">

      <text class="span">{{isRemained ? liters : ''}}</text>

      <text class="small">{{isRemained ? '剩余' : ''}}</text>

    </view>



    <view class="percentage" style="{{percentageH}}">{{isPercentage ? percentage : ''}}</view>

  </view>



  <text class="text">请选择喝水的杯子</text>



  <view class="cups">

    <view class="cup cup-small" bindtap="cups" data-ml="700">700 ml</view>

    <view class="cup cup-small" bindtap="cups" data-ml="400">400 ml</view>

    <view class="cup cup-small" bindtap="cups" data-ml="600">600 ml</view>

    <view class="cup cup-small" bindtap="cups" data-ml="500">500 ml</view>

    <view class="cup cup-small" bindtap="cups" data-ml="50">50 ml</view>

    <view class="cup cup-small" bindtap="cups" data-ml="100">100 ml</view>

    <view class="cup cup-small" bindtap="cups" data-ml="150">150 ml</view>

    <view class="cup cup-small" bindtap="cups" data-ml="300">300 ml</view>

  </view>



  <view class="cancle" bindtap="update">清空</view>

</view>

wxss

css就是简单的画杯子和布局，值得说的就是往大杯子里加水的动画 transition 一下就可以了

.body {

  height: 108vh;

  background-color: #3494e4;

  color: #fff;

  display: flex;

  flex-direction: column;

  align-items: center;

  box-sizing: border-box;

}



.h1 {

  margin: 10px 0 0;

}



.h3 {

  font-weight: 400;

  margin: 10px 0;

}



.cup {

  background-color: #fff;

  border: 4px solid #144fc6;

  color: #144fc6;

  border-radius: 0 0 40px 40px;

  height: 330px;

  width: 150px;

  margin: 30px 0;

  display: flex;

  flex-direction: column;

  overflow: hidden;

}



.cup.cup-small {

  height: 95px;

  width: 50px;

  border-radius: 0 0 15px 15px;

  background-color: rgba(255, 255, 255, 0.9);

  cursor: pointer;

  font-size: 14px;

  align-items: center;

  justify-content: center;

  text-align: center;

  margin: 5px;

  transition: 0.3s ease;

}



.cup.cup-small.full {

  background-color: #6ab3f8;

  color: #fff;

}



.cups {

  display: flex;

  flex-wrap: wrap;

  align-items: center;

  justify-content: center;

  width: 280px;

}



.remained {

  display: flex;

  flex-direction: column;

  align-items: center;

  justify-content: center;

  text-align: center;

  flex: 1;

  transition: 0.3s ease;

}



.remained .span {

  font-size: 20px;

  font-weight: bold;

}



.remained .small {

  font-size: 12px;

}



.percentage {

  background-color: #6ab3f8;

  display: flex;

  align-items: center;

  justify-content: center;

  font-weight: bold;

  font-size: 30px;

  height: 0;

  transition: 0.3s ease;

  box-sizing: border-box;

}



.text {

  text-align: center;

  margin: 0 0 5px;

}



.cancle {

  cursor: pointer;

}

js

逻辑注释写在了代码中

Page({

  data: {

    liters: '2.6L',

    isPercentage: true,

    isRemained: true,

    percentage: '',

    percentageH: 'height: 0',

    RemainedH: 0,

    goal: 2600

  },



  // 每次进入页面后加载记录的值，执行动画

  onShow() {

    this.setData({ goal: Number(wx.getStorageSync('goal')) })

    this.updateBigCup(2600 - this.data.goal)

  },



  // 点击小杯子时的触发逻辑

  cups(data) {

    const ml = Number(data.currentTarget.dataset.ml);

    const goal = this.data.goal - ml;

    const total = 2600 - goal;

    this.setData({ goal })

    wx.setStorageSync("goal", goal);

    this.updateBigCup(total)

  },



  // 更新 UI 数据

  updateBigCup(total) {

    const { goal } = this.data;

    if (goal != 2600) {

      this.setData({

        isPercentage: true,

        percentage: `${(total / 2600 * 100).toFixed(0)}%`,

        percentageH: `height: ${total / 2600 * 330}px`

      })

    }



    if (goal <= 0) {

      this.setData({

        remainedH: 0,

        isRemained: false,

      })

    } else {

      this.setData({

        isRemained: true,

        liters: `${goal / 1000}L`

      })

    }

  },



  // 清空记录值

  update() {

    wx.removeStorage({ key: 'goal' })

    this.setData({

      goal: 2600,

      isPercentage: false,

      isRemained: true,

      remainedH: 0,

      percentageH: 'height: 0px',

      liters: '2.6L'

    })

  }

})

码上掘金

  上面的代码部分主要用于小程序使用，码上掘金可在网页中使用。

结语

  感谢大家能看到这里！！本篇的代码本身没有什么技术含量，可能是比较会偏向实用性的一篇，对！是有一些的对吧！可以自己改装成Chrome插件使用会更方便更实用。啥？你问我为什么不直接写Chrome插件？有没有一种可能不是我不想，而是😭。

  好啦，如果你身边有健身的朋友也可以给他做

制作了一个图片像素风转换器，可以将图片转换成像素风格，并可转换为 css box-shadow 进行输出。前排先放效果图、转换器地址和 GitHub 地址：

转化器地址：pixel.heyfe.org/

GitHub 地址：github.com/ZxBing0066/…

转换器功能

转换器会将传入的图片转换为像素风格，并将像素风格的图片以 box-shadow 进行转换，借助 box-shadow，我们可以直接用 css 来渲染该图片，且可以通过 box-shadow 的一些特性来达成一些比较好玩的效果，比如用间隙来加重像素风格：

或者直接将间隙拉到顶，达成类似点阵图的效果：

又或者借助 border-radius，实现圆点图效果：

制作出想要的效果后，可以在右侧点击 复制 box-shadow 样式 按钮复制其样式。

实现原理

关于 box-shadow 实现像素图的原理之前有一篇文章中有提到，这里不再赘述。此处大概说一下图片转换为像素图再转为 box-shadow 的过程。

转换器在拿到图片后，会将图片绘制在一个非常小的画布中，以此来降低图片的精度，然后将画布中绘制的低精度图片进行二次渲染，渲染到较大的画布中，此时由于图片被拉伸，就会形成一定的像素效果。随后为了将像素效果图转换为 box-shadow，转换器会去读取画布中的绘制信息，将其生成为一组二维数组，再根据其中的颜色转换为 box-shadow 中的属性。至此转换器的功能就完成了。

当然其中还有一些细节（浏览器会默认启用平滑绘制导致像素效果消失等问题），本篇不打算细说，会在下篇专门写一篇来讲一下具体实现。

最后

本转换器原先是在码上掘金挑战赛某次文章中构想 ，然后在第二次制作类似效果时干脆使用脚本来完成了，最近有空就将其稍微优化了一下进行开源。目前一些细节还有点欠缺，待改进。

再贴一下地址：

转化器地址：pixel.heyfe.org/

GitHub 地址：github.com/ZxBing0066/…

相关文章

• 给我一个 div + 三行 css，还你一个超级马里奥

1.缘起：

为啥想学习es，主要是在工作中会用到，但是因为不了解原理，所以用起来畏手畏脚的，就想了解下es是怎么存储数据，以及es是怎么搜索数据的，我们平时应该如 何使用es，以及使用时候需要注意的方面。
es:github.com/elastic/ela…
lucene:github.com/apache/luce…

2.es的一些基础概念

es是一个基于lucence的分布式的搜索引擎，它使用java编写，并提供了一套RESTful api，是一款流行的企业级搜索引擎

2.1 es的特点

1. 横向可扩展性: 作为大型分布式集群, 很容易就能扩展新的服务器到ES集群中; 也可运行在单机上作为轻量级搜索引擎使用.


2. 更丰富的功能: 与传统关系型数据库相比, ES提供了全文检索、同义词处理、相关度排名、复杂数据分析、海量数据的近实时处理等功能.


3. 分片机制提供更好地分布性: 同一个索引被分为多个分片(Shard), 利用分而治之的思想提升处理效率.


4. 高可用: 提供副本(Replica)机制, 一个分片可以设置多个副本, 即使在某些服务器宕机后, 集群仍能正常工作.


5. 开箱即用: 提供简单易用的API, 服务的搭建、部署和使用都很容易操作.

2.2 es的重要概念

1.cluster(集群)
可以通过为多个节点配置同一个集群名来创建集群，通过elasticsearch.yml文件配置。
2.node(节点)
运行了单个es实例的主机被成为节点，一个集群里会包含一个或者多个节点。可以用来存储数据，搜索数据，操作数据。有三个主节点，三个数据节点。

3.shard(分片)
一个索引会分成多个分片，并存储在不同的节点中。每个shard都是一个最小工作单元，承载部分数据，对应一个lucene实例，具有完整的建立索引和处理请求的能力。shard分为primary shard和replica shard，其中replica shard 负责容错，以及承担读请求负载。一个document只会存在一个primary shard及其replica shard中，而不会存在于多个primary shard中。shards:5*2，表示有五个primary shard 以及五个replica shard。一旦创建完成，其primary shard的数量将不可更改。

4.index（索引）
一堆类型数据结构相同的document的集合。类似于数据库中的表
5.document( 文档)
es中的最小数据单元。比如一条纠纷单的数据，存在es中就是一个document。但是存储格式为json。类似于数据库中的一行数据。
6.type
类型，一个索引会存在一个或者多个 type，一个type下的document有相同的field。7.x后废弃
7.field
一个field就是一个数据字段
8.term
field的内容在经过analyze后，会被分词为term，是数据中最小的存储单位
9.数据库和es概念类比Elasticsearch 关系型数据库

3.es是如何存储数据的

3.1 es写入数据过程

1. 用户发送的请求会随机打到某一node，此时这个node为coordinate node


2. coordinate node通过路由策略找到对应的主分片 shard = hash(routing) % number_of_primary_shards，其中routing为docId，如果docId不存在，es会生成一个id来实现路由。主分片也会把请求转发到副本分片，实现数据备份。索引的primary shards在索引创建后不可更改也是因为路由策略，举个例子，对于同一个docId，原本存在primary shard 0 中，但是primary shard num修改后，就被路由到primary shard 3，这样就出现数据查不到的情况了。


3. 主分片&副本分片会构建索引以及将索引落盘

3.2 es近实时特性的原理

1. 写请求将数据写入buffer中，此时数据是不能被搜索到的，此时会同时将写操作记录在translog中，translog的落盘如果配置成同步，此时就会落盘，如果配置成异步，会在配置间隔时间进行落盘。


2. 默认1s一次的refresh操作，es会将buffer里的数据存入os cache中，并把buffer中的数据转化成segment，此时document便可以被搜索到了。每次refresh都会生成一个segment，es会定期进行segment合并。refresh数据到os cache后，buffer会被清空。


3. 每隔30min或者segment达到512M 后，会把os cache中的segment写入到磁盘中，这个过程叫做flush。此时会生成一个commit point文件，用来唯一标识该segment。执行flush操作时，会把buffer和os cache里的数据清空，此时translog也会被落盘。原有的translog会被删除，会在内存中创建一个新的translog。

3.3 segment的数据结构以及索引的原理

segment是lucene的概念，也是实现搜索的关键。名称 扩展名 简要描述
Term Dictionary .tim term词典，存储term信息
Term Index .tip 指向term词典的索引
Frequencies .doc 包含了有term的频率的文档列表
Positions .pos 存储了每个出现在索引中的term的位置信息
Payloads .pay 存储了额外的每一个位置的元数据信息如一个字符偏移和用户的负载
Field Index .fdx 包含field data的指针
Field Data .fdt 存储docs里的field表1 segment文件

其中和倒排索引相关的是.tim、.tip、.doc、.pos、.pay文件，而和正向索引相关的是.fdx、.fdt文件。下面先讲下倒排索引

3.3.1 lucene的倒排索引结构

倒排索引，其实从字面意义上很容易理解错，但是看英文就会好理解一些，inverted index，反向的索引。为什么称之为反向的索引，那应该有正向索引，正向索引指的是文档id和文档内容的映射关系，mysql的主键索引就是一个正向索引，而倒排索引，就是把这种对应关系颠倒，指的是，索引词（关键词）和文档之间的对应关系，即通过一个关键词，可以得到包含这个关键词的所有文档的文档id。

1. 通过对查询语句的解析，得到需要查找的term，找到该term对应的.tip文件和.tim文件。lucene会默认为每一个term都创建对应的索引


2. term index主要由FSTIndex和indexStartFP组成，FST(Finite State Transducer)有限状态转移机。我觉得可以理解为一个词语前缀索引。通过对前缀索引的搜索，就可以缩小搜索的范围，提高搜索的效率。


3. indexStartFPn里存的是FSTIndexn的地址， 为啥要存indexStartFPn，是因为每个FSTIndexn的大小不一样，为了节省存储空间，密集存储FSTIndexn，但是这样就没办法快速查找FSTIndexn。因此使用空间换时间，存下每个FSTIndexn的起始地址，而indexStartFP的大小都一样，这样就可以通过indexStartFPn进行二分查找了。


4. 通过term的前缀匹配定位到该term可能存在的block，此时就需要到.tim文件里去查找。可以看到.tim文件我们比较关注的是三部分。一是suffix；二是TermStats；三是TermsMetaData。其中suffix里存放的就是该term的后缀长度和suffix的内容。TermStats里包含的是该Term在文档中的频率以及所有 Term的频率，这部分是为了计算相关性。


5. 第三部分TermsMetaData里存放的是该Term在.doc、.pos、.pay中的地址。.doc文件中存放的是docId信息，包括这个term所在的docId、频率等信息。.pos文件里包含该term在每个文档里的位置。通过.tim文件里存放的这些地址，就可以去对应的文件里得出该term所在的文档id、位置、频率这些重要的信息了。

3.3.2 lucene的正向索引结构

通过倒排索引拿到的docId后，如何去拿到文档的其他字段信息，这时候就需要用到正向索引了

● fdt文件里每个chunk里包含压缩后的doc信息。fdx文件里存放的是每组chunk的起始地址
● fdx文件较小，直接加载到内存
● 通过fdx文件拿到对应的docid所在chunk的地址，再加载doc的数据信息。
● 通过正向索引拿到doc的数据类似于mysql里的回表操作

3.3.3 和mysql索引的对比

● 默认设置情况下 lucene会为doc里的每个term都创建对应的倒排、正向索引，而mysql只会为你指定的列创建索引，因此对于复杂查询场景，使用es来查询更合适，mysql无法构建索引覆盖所有的查询情况
● mysql的索引是存放在磁盘里的，检索时需要分页加载到内存再检索；lucene的.tip文件很小，可以直接放入内存，在检索时候，通过term index来快速定位到term可能存在的block。相当于给索引（词典表.tim文件）又建立了一层索引，查询效率更高

4.es是如何搜索数据的

1. 用户发送的搜索请求会随机达到任意一个node上，该node即为coordinate node。


2. coordinate node会将请求转发到该索引对应的所有的primary shard或者replica shard中


3. 每个shard处理query请求，通过lucene的搜索能力，将搜索结果返回给coordinate node


4. coordinate node将所有的结果处理后，根据排序要求取topk，再返回给client。

每一个分片中发生的搜索过程

1. 对用户的请求语句进行词法、语法分析，生成查询语法树，把文本请求转换为Lucene理解的请求对象


2. 按照查询语法树，搜索索引获取最终匹配的文档id集合


3. 对查询结果进行相关性排序，获取Top N的文档id集合，获取文档原始数据后返回用户
   5.一些关于es的使用思考


4. 对于复杂的查询场景，es查询优于mysql，对于实时性要求高，或需要实现事务操作的场景，需要使用mysql。


5. 由于es是通过查询所有分片，合并后再给出最终查询结果，所以也和mysql一样，需要注意深分页的问题，不过这块es已经做了限制，默认只返回前1w条的查询结果


6. 索引过大也会导致查询慢，可以从上面讲的索引结构看出，虽然term index是可以加载到内存的，但是最终的term dict也是存在磁盘里的，对于具体term的查询需要花费很多时间。此时可以考虑重建索引，使用更多的分片来存储/查询数据。


7. 尽可能地使用filter来代替query，query需要对查询结果进行相关性排序，而filter则不需要。

往前翻翻才意识到已经很长很长时间没有写文章，大概具体有多长？感觉上有一光年那么长。

今天，刚好是入职九周年，竟然遇到周末，省了奶茶钱。是的，没错，我在一个窝里面趴了九年。

这些年，彷徨过，迷茫过，孤独过，也充满热血的奋斗过，激情的追求过，有犹豫，有脆弱，也有失落。在悠悠岁月中，能及时不断做出调整，让自己学会享受工作带来的乐趣，学会慢慢成长。在当下浮躁的时代，写些闲言碎语，给诸君放松下心情，缓解压力。

过去的那些年

入职那天，阳光明媚，清风柔和，大厦旁边的道路开满迎春花，连空气都是甜的，让人不由自主地深呼吸，可以闻到花香草香，还有阳光的味道。

那一天也是为数不多来上班较早的一天，哦吼有大草坪，哦哟还有篮球场，这楼还波浪线，牛批，B座这个大厅有点大，有点豪华，牛批牛批，头顶上这看着怎么像熊掌，12345，设计真不孬啊。慢慢的大厅上聚集了很多人，有点吵，咋也没人组织一下呢，大家都很随意的站着等待，陆陆续续有员工来上班。

“XXX”，听到有人喊我名字，吓我一跳，还以为偷看小姐姐被发现了。

“站到靠近电梯入口的最右一列，第一个位置上”，“XX，去站在他后面”，“大家按我叫名字的顺序排好队，咱们准备上楼了”。

那会儿，AI 还不会人脸识别过闸机。

呦呵，这公司真牛批，还有扶手电梯。跟着带路的同学来到三楼五福降中天会议室，一个挺老大的屋子，还有各种数不过来的高大上仪器电子设备，一周后，也是在这里，我和厂长面对面聊聊人生。坐稳扶好后，HR 同学开始入职培训，我摸摸新电脑，摸摸工卡牌，心里美滋滋，想到未来几年，将在这样美妙的环境中度过，喜不胜收，甚至我都闻到了楼下食堂啵啵鱼的香味。

培训刚结束。

“我叫到名字的同学，跟我来。XXX，XX……”，纳尼？？？中午还管饭？？这福利也太好了吧，真不用吧，我自己能找到食堂，再说，你知道我喜欢吃什么吗？“跟着我走，咱们去北门做班车，去另一个办公楼，你们的工位不在这儿。”不在这？还坐班车？what？被外包了？她刚刚喊我了吗？？？差不多六七个同学，跟着楼长鱼贯而出，下楼，走小路，几分钟后，上了班车。司机大哥，一脚油门，就带着我远离啵啵鱼。

大约10分钟，也有可能是5分钟，或者15分钟，按照现在萝卜快跑无人车的速度，是7分钟。来到一栋圆了咕咚的，长的像长南瓜的楼，它有一个很科技感的名字，“首创空间”，就是这个空间，不仅给我带来技术的成长，还有十几斤的未来多年甩也甩不掉的肥肉。没有啵啵鱼的日子，相见便成为世上最奢侈的愿望。

大约是两年后的初春 ，准确的说，不到两年，记得是二、三月份，北京的PM2.5比较严重的时候，鼻子还不会过敏，也没学会发炎，眼睛也不知道怎么迎风流泪，总之，我们要搬家了。

$\color{#333333}“科技园”$，听听，听听，多好的名字，长得像无穷大与莫比乌斯环，楼顶带跑道，位置也牛批，毗邻猪厂、鹅厂、渣浪，北邻联想，西靠壹号院，远眺百望山，低头写代码，啧啧，美滋滋的日子又来了。当时还没有共享单车，晚饭时蹭着班车和一群小伙伴过去看新工位，喏，不错不错，挺大，位置离厕所不远，不错不错，会议室安静舒适好多个，不错不错。重点来了，食堂大的离谱，还有很多美食，连吃几个月，基本不重样。吃过几次啵啵鱼，与大厦简直天壤之别，怀念。

机会说来就来，几个月后的一天，发生了一件大事。我回到了梦开始的地方，那让人朝思暮想的啵啵鱼，那让人魂牵梦绕的味道，那让人无法忘怀的美妙口感。

命运说变就变，国庆休假回来，食堂换了运营商，我他么……￥#%@%#！@#@！&%

一直没变的：不忘初心，砥砺前行。

曾经觉得自己无所不能，可以改变世界，总幻想像蝴蝶一样扇扇翅膀，亚马逊的雨林就会刮起大风。食堂吃的多了，越来越认识到自己的影响力微乎其微，我们能做到，是把交代的工作做好，做到极致，应该就是对公司最大的回馈了，也对得起日渐增多的白发。

早些年，搞视频直播，课程学习，每天研究各种编解码技术，与视频流打交道，看过不少底层技术原理书籍，探索低延迟的 P2P 技术，枯燥，乏味，也跟不上时代变化，觉得自己会的那些早晚被淘汰，技术乏陈革新的速度超乎想象，而你所负责的，恰恰不是那些与时代贴合度较高的业务，边缘化。

怎么破？

$\color{red}从来没有人限制你，不允许你去学习。$

因为恰巧在做课程的直播、录播，需要特别关注课程内容，主要担心出现线上问题，刚好利用这个契机，了解到很多跨专业，跨部门的业务，当时给自己的宗旨是，“只要有时间，就去听课”，“凡是所学，皆有收获”。前后积累近千小时的学习时长，现在想想，觉得都有些不可能，怎么做到的，是人吗？这是人干的事？

日常工作，专心不摸鱼，积极努力提高工作效率，解决研发任务，配合 peer 做好产品协同。晚饭后，专心研究 HTML大法，通勤路上手机看文档，学 api 用法，学习各种牛批的框架，技巧，逛各大论坛，写博客做积累，与各种人物斯比，每天晚上十点，跑步半小时，上床睡觉，生活很规律。

机缘巧合下，我终于从一个小坑，成功跳到一个大坑，并至今依然在坑中。那天，我想起了啵啵鱼。

一直在变的

团队在变，用两只手数了数，前前后后换了七次 leader，管理风格比五味杂陈还多一味，有的事无巨细，有的不闻不问，有的给你空间让你发挥，有的完全帮不上忙。怎么破？尊重，学习，并努力适应，不断调整心态，适应环境的变化。

业务在变，这么多年数过来，参与过的产品没有一百也有八十了，真正能够长期坚守下来的产品不多，机会可遇不可求，能得一二，实属幸运。把一款产品从零做到一，很容易；再做到十，很难但能够完成；再从十到百，几乎不可能。互联网公司怎么会有这样的产品存在，少之又少。

技能在变，经历过前端技术栈井喷的同学都深有体会，学不动的感受。

时代在变，社会在变，人心也在改变。

曾经多次想过换个环境，换一个坑趴着，毕竟很多机会还是很诱人的。印象最深的一次，是在某年夏天，对手头的工作实在是感到无聊。由于前一年小伙伴们的共同努力，产品架构设计相当完美，今年的工作接近于智力劳动转变为纯人力的重复的机械的体力劳动，对产品建设渐失激情，每天如同行尸走肉般的敲键盘，突然意识到，自己到了职业发展瓶颈期。如何抉择，走或留，临门一脚的事，至于这一脚踢向何方，还未知。

忧思几天后，去找 leader 沟通，好家伙，他让我呆在这里别动，帮他稳住团队，他要撤，一两个月的事。好家伙，你不殿后掩护我们，自己先撂了，还说可以试试带团队，我说大哥，也没几个人呀。他说你还能招兵买马，试试新的角色，体会下不同的视角，很好的机会。坑，绝对的大坑，我他么竟然义不容辞的答应了。

好在，不枉大家这么多年的认可，团队战斗力很强大。

你觉得什么是幸福

• 有独处的时间


• 有生活的追求


• 工作能给你带来乐趣

前些日子，给娃拿药请了半天假，工作日人不多，十点多就完事了，看看时间地铁回去差不多到公司刚好中午饭。医院出来看到很多小黄车，美团那种新式的自行车，看着很不错，还没体验过，特别想兜几圈。查地图，距离公司有22公里，按照骑行的速度推算，70分钟也差不多到了。打定主意后，书包里翻出俩水煮蛋（鬼知道我为什么早上去公司拿了俩鸡蛋）和一瓶水（鬼使神差的早上往书包放的），算是吃过早饭了。于是一个人，一条狗，开局一把刀，沿着滨河路，经过木樨地，二里河，中关村南大街，北大街，信息路，上地西路回来了。您还别说，就是一个地道。竟然还路过玉渊潭，还遇到了封路限行，静悄悄的圆明园东路，过国图，还有数不清的大学，附中，有那么一瞬间好想回母校去看看，总之，重点是顺路吃到心心念的煎饼果子。

路上给媳妇打电话，这小妞竟然说我疯了，疯了？你懂个屁，这叫幸福。

人生的乐趣

人生的乐趣何在？你的答案和我的答案可能不一样，作为打工人，我知道，肯定不是工作。但似乎又不能没有工作，不工作我们怎么活着？怎么在这个社会上，换取资源，立足于当下，着眼于未来。说回工作，最后悔的事，曾经有那么一小段，人际关系没有处理好，可能造成误会，当时来自于我对某些事情的不表态，默许的态度，十周年前修复它。最快乐的时光，是和大家一起沉浸在技术点的探讨，Bug的跟进定位，发现问题解决问题的成就感；参与产品的规划，出谋划策，影响他人；挑灯夜战，专注于产品的 DDL，为上线争分夺秒的努力前行，感受团队的力量。

这个春天，爬过许多京郊的小山头，站在山顶，凝视着壮丽的景色，总以为自己是秦始皇。不惑之前，去征服贡嘎雪山。

总之，故事太多讲也讲不完，作为一个九年的老东西，我是不会爆金币的。

到结尾了，给点建议吧

建议？给不了给不了，我自己还没活明白。

历史的滚滚车轮中，每个生命都很渺小，时代一直在变，抓住机遇，让自己成长，多读书，沉下心，慢慢来。

在线体验

项目 github 仓库

前一阵子在刷抖音时，看到一个通过左右歪头选择两侧图片的视频，感觉很有趣。顿时想到了 n 年前的face-api.js，那就基于这个来做吧。总体做好后，有很多细节需要改进，不够细腻丝滑。

1. 需求分析

直接开搞吧！

1. 页面基本布局，左右两侧图片，而且有缩放和移动动画


2. 需要打开摄像头，获取视频流，通过 video 展现出来


3. 需要检测人脸是向哪一侧歪头

2. 具体实现

2.1 页面布局和 animation 动画

这个不难，布局好后，就是添加 css 动画，我这里写的很粗糙，不细腻，但勉强能用，例如下面 leftHeartMove 为中间的小爱心向左侧移动动画

.heart {

  width: 30px;

  height: 30px;

  padding: 4px;

  box-sizing: border-box;

  border-radius: 50%;

  background-color: #fff;

  position: absolute;

  top: -15px;

  left: 50%;

  transform: translateX(-50%) rotateZ(0deg) scale(1);

  animation: leftHeartMove 0.5s linear;

  animation-fill-mode: forwards;

  z-index: 2;

}



@keyframes leftHeartMove {

  from {

    top: -15px;

    left: 50%;

    transform: translateX(-50%) rotateZ(0deg) scale(1);

  }



  to {

    top: 65px;

    left: -13%;

    transform: translateX(-50%) rotateZ(-15deg) scale(1.2);

  }

}

2.2 打开摄像头并显示

注意点

1. 关于 h5navigator.mediaDevices.getUserMedia 这个 api，本地开发localhost是可以拉起摄像头打开提示的，线上部署必须是https节点才行，http不能唤起打开摄像头

2. 
   

   关于获取到视频流后，video视频播放，需要镜面翻转，这个可以通过 css 的transform: rotateY(180deg)来翻转

   
   


3. 
   

   关于video播放不能在手机上竖屏全屏，可以给 video 设置 cssobject-fit:cover来充满屏幕

   
   

<video id="video" class="video" playsinline autoplay muted></video>

.video {

  width: 100%;

  height: 100%;

  transform: rotateY(180deg);

  object-fit: cover;

}

• 获取摄像头视频流

async getUserMedia() {

  if (navigator.mediaDevices && navigator.mediaDevices.getUserMedia) {

    try {

      // https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia#examples

      const stream = await navigator.mediaDevices.getUserMedia({

        audio: false,

        video: true,

        video: {

          facingMode: "user", // 前置摄像头

          // facingMode: { exact: "environment" }，// 后置摄像头

          width: { min: 1280, max: 1920 },

          height: { min: 720, max: 1080 },

        },

      });



      return Promise.resolve(stream);

    } catch (error) {

      return Promise.reject();

    }

  }



  const errorMessage =

    "This browser does not support video capture, or this device does not have a camera";

  alert(errorMessage);

}

• video 播放视频流

async openCamera(e) {

  try {

    const stream = await this.getUserMedia();

    this.video.srcObject = stream;

    this.video.onloadedmetadata = async () => {

      this.video.play();

    };

  } catch (error) {

    console.log(error);

    alert("打开摄像头失败");

  }

}

• 关闭视频

async closeCamera() {

  // https://developer.mozilla.org/en-US/docs/Web/API/MediaStreamTrack/stop

  const tracks = this.video.srcObject.getTracks();



  tracks.forEach((track) => {

    track.stop();

  });



  this.video.srcObject.srcObject = null;

}

2.3 检测人脸左右倾斜

通过face-api.js拿到人脸landmarks特征数据后，可以直接拿到左右眼的数据，分别通过求 Y 轴方向的平均值，然后比较这个平均值，便可以简单得出人脸向左还是向右倾斜，简单吧，角度都不用求了！

<div style="position: relative;width: 100%;height: 100%;">

  <video

    id="video"

    class="video"

    playsinline

    autoplay

    muted

    style="object-fit:cover"

  ></video>

  <canvas id="overlay" class="overlay"></canvas>

</div>

.video {

  width: 100%;

  height: 100%;

  position: absolute;

  top: 0;

  left: 0;

  z-index: 0;

  transform: rotateY(180deg);

}



.overlay {

  position: absolute;

  top: 0;

  left: 0;

}

• 加载模型

import * as faceapi from "face-api.js";



async loadWeight() {

  // 加载模型

  await faceapi.nets.ssdMobilenetv1.load(

    "./static/weights/ssd_mobilenetv1_model-weights_manifest.json"

  );

  // 加载人脸68特征模型数据

  await faceapi.nets.faceLandmark68Net.load(

    "./static/weights/face_landmark_68_model-weights_manifest.json"

  );

  // await faceapi.nets.faceExpressionNet.load(

  //   "/static/weights/face_expression_model-weights_manifest.json"

  // );

  // await faceapi.nets.faceRecognitionNet.load(

  //   "./static/weights/face_recognition_model-weights_manifest.json"

  // );

  await faceapi.nets.ageGenderNet.load(

    "./static/weights/age_gender_model-weights_manifest.json"

  );



  console.log("模型加载完成");

}

• 计算人脸左右倾斜

handleFaceLeftOrRight(landmarks) {

  const DIFF_NUM = 15; // 偏差

  let leftEye = landmarks.getLeftEye(); // 左眼数据

  let rightEye = landmarks.getRightEye(); // 右眼数据

  // let nose = landmarks.getNose();



  let leftEyeSumPoint = leftEye.reduce((prev, cur) => ({

    x: prev.x + cur.x,

    y: prev.y + cur.y,

  }));



  let rightEyeSumPoint = rightEye.reduce((prev, cur) => ({

    x: prev.x + cur.x,

    y: prev.y + cur.y,

  }));



  // let noseSumPoint = nose.reduce((prev, cur) => ({

  //   x: prev.x + cur.x,

  //   y: prev.y + cur.y,

  // }));



  let leftEyeAvgPoint = {

    x: leftEyeSumPoint.x / leftEye.length,

    y: leftEyeSumPoint.y / leftEye.length,

  };



  let rightEyeAvgPoint = {

    x: rightEyeSumPoint.x / leftEye.length,

    y: rightEyeSumPoint.y / leftEye.length,

  };



  // let noseAvgPoint = {

  //   x: noseSumPoint.x / leftEye.length,

  //   y: noseSumPoint.y / leftEye.length,

  // };



  // console.log(leftEyeAvgPoint, rightEyeAvgPoint, noseAvgPoint);

  let diff = Math.abs(leftEyeAvgPoint.y - rightEyeAvgPoint.y);



  return diff > DIFF_NUM

    ? leftEyeAvgPoint.y > rightEyeAvgPoint.y

      ? "left"

      : "right"

    : "center";

}

• 处理 video 视频

async handleVideoFaceTracking(cb) {

    if (this.closed) {

      window.cancelAnimationFrame(this.raf);

      return;

    }



    const options = new faceapi.SsdMobilenetv1Options();



    let task = faceapi.detectAllFaces(this.video, options);

    task = task.withFaceLandmarks().withAgeAndGender();

    const results = await task;



    // overlay为canvas元素

    // video即为video元素

    const dims = faceapi.matchDimensions(this.overlay, this.video, true);

    const resizedResults = faceapi.resizeResults(results, dims);



    // console.log("options==>", options);

    // console.log("resizedResults==>", resizedResults);

    cb && cb(resizedResults);



    this.raf = requestAnimationFrame(() => this.handleVideoFaceTracking(cb));

  }

3. 参考资料

1. 
   

   face-api.js

   
   


2. 
   

   getUserMedia MDN

   
   

Prompt对用好ChatGPT的重要性毋庸置疑，我们在上篇文章中介绍了写好Prompt的通用原则和一些基础技巧，在本文中，我们将继续探索一些Prompt的高阶技巧。

在介绍这些高阶技巧前，我们先对之前介绍的基础技巧做一个简单回顾。

首先作为通用原则，我们的Prompt应该尽可能简单、具体、准确，有话直说，在此基础上，我们有Zero-shot, Few-shot, Instruction, CoT以及分而治之等基础技巧，在Few-shot中，例子的多样性和排序对结果有较大的影响，在CoT中，例子的复杂度和描述方式对结果也有很大影响。这些技巧还可以组合起来使用如Few-Shot Instruction, Zero-shot CoT, Few-Shot CoT等，CoT还衍生出来一个叫做Self-Ask的技术，通过ChatGPT提问，调用外部API回答的方式，我们可以帮助ChatGPT逐步推导出复杂问题的答案。

接下来，我们开始介绍高阶Prompt技巧。

Self-consistency(自洽) ： 这一技巧的思路是投票选举，少数服从多数，其具体工作过程是对同一个问题，让ChatGPT生成多个可能的答案，然后选择占比最高的那个答案作为最终答案，其工作原理示意图如下：

这个技巧很容易理解，但是有几个要注意的点：

• 
  
  
  
  • 为了让ChatGPT生成多个答案，如果你是通过API对其进行调用的，请把temperature参数设置得大一些以增加API输出的多样性
  
  
  • 为了生成多个答案，需要进行多次ChatGPT调用，这会大大增加成本(gpt-3.5-turbo降价10倍，这个问题好了一些)
  
  
  • 这个方法只适用于那些只有有限答案可供选择的情况，像开放式的问题，比如给我写一首诗这种问题，这个技巧肯定不适用
  
  
  
  

为了进一步提升这一方法的效果，还可以额外训练一个小模型或者简单的规则，在投票前先把明显不靠谱的答案过滤掉(比如上图中Janet一天挣多少钱的问题，如果答案是负数肯定不对)，过滤后如果备选答案不够就再让ChatGPT生成几个，直到有足够靠谱答案了再投票。

Generated Knowledge(生成知识) ：我们知道在向ChatGPT提问时，如果能提供一些上下文信息，其回答问题的准确率就会高很多，顺着这个思路，我们也可以让ChatGPT自己给自己提供上下文，而不是每次都由我们完成这一工作，我们还是通过例子来说明这一方法的工作过程：

Part of golf is trying to get a higher point total than others. Yes or No?

得到的答案是

Yes.

这显然是个错误的答案，因为打高尔夫杆数越少越好。

我们可以让ChatGPT回答问题前首先自己生成一些知识，下面是用few-shot技术来让ChatGPT生成知识的例子：

Input: Greece is larger than mexico.

Knowledge: Greece is approximately 131,957 sq km, while Mexico is approximately 1,964,375 sq km, making Mexico 1,389% larger than Greece.

Input: Glasses always fog up.

Knowledge: Condensation occurs on eyeglass lenses when water vapor from your sweat, breath, and ambient humidity lands on a cold surface, cools, and then changes into tiny drops of liquid, forming a film that you see as fog. 

Input: A fish is capable of thinking.

Knowledge: Fish are more intelligent than they appear. In many areas, such as memory, their cognitive powers match or exceed those of ’higher’ vertebrates including non-human primates. Fish’s long-term memories help them keep track of complex social relationships

Input: Part of golf is trying to get a higher point total than others.

Knowledge:

ChatGPT返回如下知识片段：

The objective of golf is to play a set of holes in the least number of strokes. A round of golf typically consists of 18 holes. Each hole is played once in the round on a standard golf course. Each stroke is counted as one point,  the total number of strokes is used to determine the winner of the game.

接下来，我们把这个知识作为上下文，再次向ChatGPT提问：

Question: Part of golf is trying to get a higher point total than others. Yes or No?

Knowledge: The objective of golf is to ...and the total number of strokes is used to determine the winner of the game..

Explain and Answer:

得到如下答案：

No,  the objective of golf is not to get a higher point total than others. Rather, the objective is to play a set of holes in the least number of strokes. The total number of strokes is used to determine the winner of the game, not the total number of points.

可以看到我们让ChatGPT自己生成的知识帮助它给出了正确的答案。

Program of Though(程序式思考) ：ChatGPT最近推出了Plugin，其思路是把一些问题交给外部的工具来完成，和这一思路类似，有些问题涉及复杂的计算，ChatGPT可能并不适合进行这类计算，我们可以让它为要解决的问题写一段程序，我们运行这个程序以得到最后的答案，下面是一个计算斐波那契数列的例子： 

Selection-Inference (选择-推理)：这是一种在Few-shot CoT的基础上演化出来的技术，其基本思路是分两步来解决问题：

• 
  
  
  
  • 
    

    第一步：Selection, 从上下文中选择和问题相关的事实，作为回答问题的证据/原因

    
    
  
  
  • 
    

    第二步：Inference，基于选择出的证据/原因，进行推理，看能否回答问题，如果能回答问题，则把推理结果作为答案输出，如果不能，则把推理结果作为新的事实补充到上下文中，回到第一步

    
    
  
  
  
  

下图是来自论文中的工作原理介绍图：

图中的几个颜色说明如下：

• 
  
  
  
  • 黄色：    上下文
  
  
  • 绿色：    问题
  
  
  • 浅蓝色：原因
  
  
  • 红色：    推理结果或答案
  
  
  
  

论文中的图不是特别好理解，我在图上加了3个红框，接下来详细介绍下如何理解这张图：

• 
  
  
  
  • 
    

    首先，为了理解Selection-Inference这个两步走的工作原理，我们先忽略图中框出的1和2，没有了这两个干扰，工作原理就比较清楚了，左边是Selection的过程，首先是黄色背景的上下文中给出了4个事实，然后提问：“emily怕什么”，ChatGPT(或其它LLM)从中选出了两条作为证据/原因：“狼怕老鼠，emily是一头狼”(图中的3)

    
    
  
  
  • 
    

    然后，把上述选择的事实交给ChatGPT(或其它LLM)进行推理，推理结果是“emily怕老鼠”，然后判断问题是否得到了回答，如果能则把“emily怕老鼠”作为结果返回，否则把“emily怕老鼠”加入到上下文回到Selection环节继续循环，(在本例中，“emily怕老鼠”已经回答了“emily怕什么”的问题，所以无需继续)

    
    
  
  
  • 
    

    接下来，我们再看看框1和框2的作用，实际这里是一个Few-shot技巧，在框1中给出了若干个【上下文-问题-原因】作为例子，然后跟一个【上下文-问题】，这样ChatGPT就明白你是让它像例子一样，基于给出的上下文和问题，找出回答问题的证据/原因，如果没有这些例子，直接给一个【上下文-问题】它可能不理解你到底让它干嘛。框2也是类似，通过给出几个【原因-推理】的例子让ChatGPT明白，它需要根据给出的原因，进行推理

    
    
  
  
  
  

明白了工作原理后，我们再次忽略细节，其整个工作过程如下图所示(Halter模块决定是继续循环还是给出最终答案)：

虽然图看着比较复杂，但其思路和基础技巧中介绍的分而治之的思路很像，先求解中间过程，然后推导最终答案。这个技巧在处理比较复杂的问题时效果比较明显，如果问题本身不涉及太多步骤的推导，一些简单技巧就能解决问题。

一些更复杂的技巧

下面的几个技巧比较复杂，大家平时也不一定能直接用得到，我将简单介绍下其思路，不详细展开，大家知道有这个技巧，真的觉得需要使用时再深入研究就好(我在下面会为大家附上论文链接)。

Automatic Prompt Engineer(APE Prompt自动生成) : 有时候，除了我们自己手写Prompt之外，我们也可以利用ChatGPT帮我们找到一个好的Prompt，下图是一个例子：

这个例子中，我们想找到一句好的Prompt(指令)，这个指令可以让ChatGPT更好地为一个输入词给出反义词。上图的工作过程是，首先给出一堆正-反义词，然后让ChatGPT给出若干候选指令，接着评估这些候选指令，看哪一个能让ChatGPT在测试集上有更好的表现，然后选择其中得分最高的作为答案。

这里还有一个可选的优化步骤是，把上述最高分的候选指令，让ChatGPT在不改变语义的情况下，生成几个变种，然后重复上面的过程，从这几个变种中选出最优的那个。

有兴趣的同学可以在这里看论文：arxiv.org/pdf/2211.01…

Least to Most(由易到难) ：其思路是对高难度的问题，先将其拆解为难度较低的子问题，把这些子问题解决后，用这些子问题和答案作为上下文，再让ChatGPT完成高难度问题的回答，下面是一个例子：

这个方法只有比较复杂的情况下才能发挥比较大的作用，另外要用好这个技巧，能否让ChatGPT有效地分解问题是关键，但整篇论文并没有对此给出详细说明。

有兴趣的同学可以在这里看论文：arxiv.org/pdf/2205.10…

Maieutic(类决策树) ：这是复杂度最高的一个技巧，其基本思路是对一个复杂问题，层层递归，对这个问题生成各种可能的解释(以及子解释)，然后从中选择最靠谱的节点，推导最终的问题答案

工作过程如下：

1. 
   
   
   
   1. build一棵maieutic树，树上的每个树叶都是一句True/False的陈述：
   
   
   2. 
      
      
      
      • 从一个多选问题或者true/false问题开始(比如：战争不能有平局)
      
      
      • 对每一个可能的答案，让ChatGPT生成一个解释(Prompt类似：战争不能有平局吗？True，因为）
      
      
      • 然后让ChatGPT用上一步生成的解释来回答最初的问题，接着再颠倒上述解释(比如：这么说是不对的，{上一步生成的解释})，再次让ChatGPT回答问题，如果答案也能颠倒过来，则认为这个解释是逻辑自洽的，反之则递归上述过程，把每个解释变成一个True/False的子问题，然后生成更多的解释
      
      
      • 上述递归完成后，我们就能得到一棵树，每个叶子节点都是一个逻辑自洽的解释
      
      
      
      
   
   
   3. 把这棵树转化为一个关系图
   
   
   4. 
      
      
      
      • 对每个叶子节点计算其置信度
      
      
      • 对每一对节点，判断他们是一致的还是矛盾的
      
      
      
      
   
   
   5. 用一个叫做MAX-SAT的算法，选择一组一致的、置信度最高的节点，从中推导出最后的答案
   
   
   
   

下面是一个例子：

这是另一个例子：

有兴趣的同学可以在这里看论文：arxiv.org/pdf/2205.11… Engineering领域里面的几个技巧介绍，如果我们去搜索一下的，还会发现更多技巧介绍的论文，这里就不再继续了。其实通过上面的几个例子大家能看到，这些复杂的技巧，一般都涉及多个步骤，都会把大问题拆解成若干小问题，这其实就是计算机里面最常用的分而治之的策略，我想只要我们记住这一策略，在我们解决具体问题的时候，也能想到自己的Prompt技巧。

前言

文章提供视频版啦，点击直接查看

hello，大家好，我是 sunday。

今天遇到了一个非常有意思的问题，跟大家分享一下。

咱们来看这段代码：

a===1 && a===2 && a===3 

假设上面的表达式成立，那么问：a 是什么？

正文

ok，我们来说一下这个问题的解答。

想要解决这个问题，那么我们首先要知道 JavaScript 中的类型转换和比较运算符的优先级。

在 JavaScript 中，表达式的运算顺序是 从左到右。因此，在这个表达式中，先执行 a===1 的比较运算符，如果它返回 false，整个表达式就会返回 false，也就是逻辑中断。

如果 a 的值是 1，则比较运算符返回 true，那么就会继续执行下一个逻辑运算符 &&，接着执行 a===2 的比较运算符，如果它返回 false，则整个表达式返回 false，逻辑中断。

以此类推，以此类推，所以 a 的值应该是动态变化的，并且应该依次为 1、2、3。只有这样才会出现 a===1 && a===2 && a===3; 返回 true 的情况。

那么 如何让 a 的值动态变化，就是咱们解决这个问题的关键。

我们在 一小时读完《JavaScript权威指南（第7版）》上 和 一小时读完《深入理解现代 JavaScript》，彻底掌握 ES6 之后 JavaScript 新特性！ 中都讲到过，对象的方法存在 get 标记，一旦方法存在 get 标记，那么我们就可以像调用对象的属性一样，调用这个方法。

那么说到这里，肯定很多小伙伴都想到这个问题怎么解决了。

我们直接来看代码：

 const obj = {

      // get 标记

      get a() {

        this.value = this.value || 1;

        return this.value++;

      }

    };

    ​

    console.log(obj.a === 1 && obj.a === 2 && obj.a === 3); // true

在这段代码中，我们创建了一个对象 obj，它包含一个被 get 标记的方法 a。那么此时只要执行 obj.a 就会调用 a 方法，完成 value 自增的操作。从而得到咱们期望的结果。

总结

这是一个非常有意思的问题。除了上面这种方案之后，还有很多其他的实现方案。大家可以开动脑筋，想一想别的方案都有什么呢？

答案留在评论区，咱们

认识蓝牙

蓝牙技术是一种无线数据和语音通信开放的全球规范，它是基于低成本的近距离无线连接，为固定和移动设备建立通信环境的一种特殊的近距离无线技术连接。

传统蓝牙和低功耗蓝牙

根据蓝牙的发展历程，将蓝牙普遍分为两种规格，即传统蓝牙模块(BT) 和低功耗蓝牙模块(BLE)。传统蓝牙模块常用在对数据传输带宽有一定要求的场景上。低功耗蓝牙是从蓝牙4.0起支持的协议，特点是耗电极低、传输速度更快，常用在对续航要求较高且只需小数据量传输的各种智能电子产品中。

蓝牙技术目前已经发展到5.0+版本，为现阶段最高级的蓝牙协议标准。BLE技术更契合新时代物联网的需求：更快、更省、更远、更便捷，也是我们小程序开发者在物联网项目最常用的技术。

蓝牙通信概述

低功耗蓝牙协议给设备定义了若干角色，其中最主要的角色是：外围设备（Peripheral） 与中心设备（Central）。

• 
  

  外围设备：用来提供数据，通过不停地向外广播数据，让中心设备发现自己。

  
  


• 
  

  中心设备：扫描外围设备，发现有外围设备存在后，可以与之建立连接，之后就可以使用外围设备提供的服务（Service）。

  
  

在两个蓝牙设备建立连接之后，双方的数据交互是基于一个叫做 GATT (Generic Attribute Profile，通用属性配置文件) 的规范，根据该规范可以定义出一个配置文件（Profile），描述该蓝牙设备提供的服务（Service）。

在整个通信过程中，有三个最主要的概念：配置文件（Profile） 、服务（Service） 、特征（Characteristic） 。

Characteristic：在 GATT 规范中最小的逻辑数据单元。实际上，在与蓝牙设备打交道，主要就是通过读写 Characteristic 的 value 完成。Characteristic 是通过一个 16bit 或 128bit 的 UUID 唯一标识。

Service：可以理解为蓝牙设备提供的服务，一个蓝牙设备可以提供多个服务，比如电量信息服务、系统信息服务等。每个 Service 又包含多个 Characteristic 特性值，比如电量信息服务就会有个 Characteristic 表示电量数据。同时也有一个 16bit 或 128bit 的 UUID 唯一标识该服务。

Profile：并不真实存在于蓝牙设备中，它只是被蓝牙标准预先定义的一些 Service 的集合。如果蓝牙设备之间要相互兼容，它们只要支持相同的 Profile 即可。一个蓝牙设备可以支持多个 Profile。

Desciptor: 描述符是描述特征值的已定义属性。例如，Desciptor 可指定人类可读的描述、特征值的取值范围或特定于特征值的度量单位。每个 Desciptor 由一个 UUID 唯一标识。

总结：每个蓝牙设备可能提供多个 Service，每个 Service 可能有多个 Characteristic，根据蓝牙设备的协议，用对应的 Characteristic 进行读写，即可达到与其通信的目的。

蓝牙开发实践

蓝牙通信过程介绍

整体上看，蓝牙通信的开发主要分为三部分：

1. 蓝牙资源和状态管理：包括蓝牙生命周期管理、蓝牙状态管理（开关、适配器、设备连接、数据接收等）、错误异常处理。


2. 搜寻外围设备并建立连接：包括搜寻设备、监听设备发现、处理获取到的设备信息、连接/断开设备等。


3. 读写数据：包括寻找目标服务和特征值、订阅特征值、监听并接收设备数据、分包处理数据等。

蓝牙数据读写

在小程序蓝牙开发联调中，推荐使用TLV协议对数据进行封包，TLV协议（Tag、Length、Value）是常见的一种面向物联网的通讯协议，对于不同的传输场景，甚至演变出混合型、指针型、循环型等不同类型的格式。

比如，在实践中往往只需要最简单的L-TLV格式，以下使用十六进制(Hex)表示：

• 数据包总长（L）


• 数据的类型Tag/Type（T）


• Value的长度Length（L）


• 数据的值Value（V）

[0x07, 0x01, 0x01, 0x01, 0x02, 0x01, 0x01]

[数据总长，type，length，value，type，length，value] 

举例

假设业务规定各字段type如下

想要向设备传输一条写入account的指令，value为ABC。

ABC 通过 UTF-8 编码转 Hex String 分别是0x41、0x42、0x43。

那么数据包总长6字节，type是0，value总长3字节。

字符集编码

实际业务场景中，如果需要传输中文字符，则需要通过协商好的字符集进行转换。

常见字符集有：ASCII字符集、GB2312字符集、GBK字符集、 GB18030字符集、Unicode字符集等。

比如小写字母a，ASCII编码对应的Hex值是0x61，而GB2312字符集编码对应的Hex值是253631

将文本字符串转换为Hex字符串的时候，不同的字符集编码对应的Hex值不一样，所以小程序与蓝牙设备应当使用同一套字符集编码。推荐统一使用Unicode的UTF-8标准。

以下是字符转换示例:

// 中文转UTF-8

encodeURI('好').replace(/%/g, ''); // 'E5A5BD'



// UTF-8转中文

hex2String('E5A5BD'); // '好'

/**

 * * read UTF-8

 * @param { number[] } arr

 * @returns {string}

 */

const readUTF = (arr: number [] ) => {

    let UTF = '';

    const _arr = arr;

    for (let i = 0; i < _arr.length; i++) {

        // 10进制转2进制        

        const one = _arr[i].toString(2);

        const v = one.match(/^1+?(?=0)/);

        if (v && one.length == 8) {

            const bytesLength = v[0].length;

            let store = _arr[i].toString(2).slice(7 - bytesLength);

            for (let st = 1; st < bytesLength; st++) {

                store += _arr[st + i].toString(2).slice(2);

            }

            // 二进制序列转charCode，再拼接

            UTF += String.fromCharCode(parseInt(store, 2));

            i += bytesLength - 1;

        } else {

            UTF += String.fromCharCode(_arr[i]);

        }

    }

    return UTF;

};



/**

 * * transfer hex to string

 * @param { string } str

 * @returns {string}

 */

const hex2String =  (hex: string) => {

    const buf = [];

    // 转10进制数组

    for (let i = 0; i < hex.length; i += 2) {

        buf.push(parseInt(hex.substring(i, i + 2), 16));

    }

    

    return readUTF(buf);

};

蓝牙分包

但是实际场景往往不是传输几个字母这么简单。虽然小程序不会对写入数据包大小做限制，但与蓝牙设备传输数据时，数据量超过 MTU （最大传输单元） 容易导致系统错误，所以要主动对数据进行分片传输。

参考各小程序开放平台文档：

分包的过程，需要用到 ArrayBuffer

ArrayBuffer 对象用来表示通用的、固定长度的原始二进制数据缓冲区。

ArrayBuffer 是对固定长度的连续内存空间的引用。

在 Web 开发中，当我们处理文件时（创建，上传，下载），经常会遇到二进制数据。另一个典型的应用场景是图像处理。这些都可以通过 JavaScript 进行处理，而且二进制操作性能更高。

ArrayBuffer 只是一个内存区域，里面存储着一些原始的字节序列，它和普通的Array完全不是一个概念，它的长度是固定的，无法增加或减少，也无法直接用buffer[index]进行访问。

要想写入值、遍历它或者访问单个字节，需要使用视图（View） 进行操作，以下为一些常用的视图：

Uint8Array ：将 ArrayBuffer 中的每个字节视为 0 到 255 之间的单个数字（每个字节是 8 位，因此只能容纳那么多）。称为 “8 位无符号整数”。

Uint16Array：将每 2 个字节视为一个 0 到 65535 之间的整数。称为 “16 位无符号整数”。

所有这些视图（Uint8Array，Uint32Array 等）的通用术语是 TypedArray（类型化数组）。它们都享有同一组方法和属性，类似于常规数组，具有索引，并且是可迭代的。

实际上，不同平台的小程序API定义的数据接口，都多少会用到ArrayBuffer

微信小程序-写入特征值

飞书小程序-获取设备信息

但也不排除有些操作，开发平台已经帮忙处理了

飞书小程序-写入特征值

因此学习并使用 ArrayBuffer，可以：

1. 
   

   方便操作分包，方便读取设备返回的数据、向设备写入数据。

   
   


2. 
   

   在不同小程序平台灵活处理，更好地兼容

   
   

回到主题，蓝牙分包的思路是：

Text String --> Hex String --> ArrayBuffer(分包)

举个例子，上文中想要向设备传输一条写入password的指令，value为bytedance123456789ABC。

[数据总长，type，length，value] MTU为20字节

[0x14, 0x01, 0x11, 0x62, 0x79, 0x74, ...] 第一个包 bytedance12345678

[0x07, 0x01, 0x04, 0x39, 0x41, 0x42, ...] 第二个包 9ABC

设备端会将多个相同type的包的值追加，而不是覆盖。

如何与设备端协商分包交互机制？

1. 规定服务、特征值UUID，建议不同操作使用不同的UUID，读、写、订阅分开。


2. 遵循TLV协议，双方协商好Type对应的字段类型和含义。


3. 双方使用同一套字符编码集。


4. 约定连在一起的两次（或多次）相同类型的设置，应该把它们的值追加连接，而不是覆盖


5. 可约定在一次涉及业务逻辑的通信过程中，发送“开始”和“结束”的蓝牙包，告知设备处于这两个信号之间的蓝牙包为一次完整的通信数据流。


6. 双方共同约定一个超时时间，若在此时间内由于各种原因未能完成读/写通信，则认为通信失败，小程序端必须给予用户友好提示。

问题排查手段

在开发过程中可能会遇到调用API失败、连接断开等问题

1. 检查API调用顺序

小程序的蓝牙API使用起来比较简单，但是需要严格遵循一定的调用顺序（参考上文的流程图）。比如检查是否在开关蓝牙适配器之外进行操作，或者是否在特征值发生变化后才进行事件监听等

2. 对比测试

• 业务小程序、开放平台官方蓝牙demo 对比


• 开放平台(非微信)官方蓝牙demo、微信官方demo 对比


• 同厂商设备、同芯片、同蓝牙模组，多台设备对比


• iOS、Android，蓝牙调试软件 与小程序的对比 （iOS：LightBlue，Android：BLE调试宝、nRF Connect）

经过以上对比测试，基本可以缩小问题范围，定位问题究竟是出在哪一方。但并不百分之百准确。

3. 
   

   一些Tips：

   
   
   
   
   • 设备Server端在自定义特征值UUID时未遵循GATT的Attribute Structure，而蓝牙服务iOS的实现会比Android更严格。
   
   
   • 外围设备使用deviceId作为唯一标识，但iOS 和 Android在拿到的信息上有所差异。Android上获取到的deviceId为设备MAC地址，iOS上则是系统根据外围设备 MAC 地址及发现设备的时间生成的 UUID，因此deviceId不能硬编码。
   
   
   • 蓝牙模块比较耗费系统资源，做好生命周期管理必不可少，比如建立连接和断开连接应该成对出现，如果未能及时关闭连接释放资源，容易导致连接异常。另外，大多数蓝牙模组只支持单链路，最大连接数量为1，若未能及时断开连接，必然出现设备搜寻不到或连接不上的情况。
   
   
   
   


4. 
   

   日志排查

   
   

作为小程序的开发者，很多疑难问题往往不能直观看出。如果你有对应的资源可以联系到开放平台的维护人员，即可拿到日志。我们项目组曾与飞书开放平台建立蓝牙专项问题解决渠道，结合开平和设备端同学捕获的日志，可以加快排查速度。

参考文章

http://www.bluetooth.com/learn-about…
http://www.cnblogs.com/chusiyong/p…
http://www.jianshu.com/p/62eb2f540…
zh.javascript.info/arraybuffer…

HTML5+CSS3实现闪亮的玻璃图标悬浮效果，光与玻璃的碰撞，好有质感的玻璃图标。

先看效果：

源代码：

<!DOCTYPE html>

<html>



<head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">

    <meta name="viewport" content="width=device-width,initial-scale=1,maximum-scale=1,user-scalable=no">



    <title>闪亮的玻璃图标悬浮效果</title>

    <link href="https://cdn.bootcdn.net/ajax/libs/font-awesome/4.7.0/css/font-awesome.css" rel="stylesheet">

    <link rel="stylesheet" href="../css/5.css">

</head>



<body>

    <div class="container">

        <div class="color"></div>

        <div class="color"></div>

        <div class="color"></div>

        <ul>

            <li>

                <a href="#"><i class="fa fa-qq" aria-hidden="true"></i></a>

            </li>

            <li>

                <a href="#"><i class="fa fa-weixin" aria-hidden="true"></i></a>

            </li>

            <li>

                <a href="#"><i class="fa fa-weibo" aria-hidden="true"></i></a>

            </li>

            <li>

                <a href="#"><i class="fa fa-tencent-weibo" aria-hidden="true"></i></a>

            </li>

            <li>

                <a href="#"><i class="fa fa-telegram" aria-hidden="true"></i></a>

            </li>

        </ul>

    </div>

</body>



</html>

*{

    margin: 0;

    padding: 0;

    /* 这个是告诉浏览器：你想要设置的边框和内边距的值是包含在总宽高内的 */

    box-sizing: border-box;

}

body{

    /* 溢出隐藏 */

    overflow: hidden;

}

.container{

    position: absolute;

    width: 100%;

    /* 100%窗口高度 */

    height: 100vh;

    /* 弹性布局 水平垂直居中 */

    display: flex;

    justify-content: center;

    align-items: center;

    /* 渐变背景 */

    background: linear-gradient(to bottom,#2193b0,#6dd5ed);

}

.container::before{

    content: "";

    position: absolute;

    bottom: 0px;

    width: 100%;

    height: 50%;

    z-index: 1;

    /* 背景模糊 */

    backdrop-filter: blur(5px);

    border-top: 1px solid rgba(255,255,255,0.5);

}

.container .color{

    position: absolute;

    /* 模糊滤镜 数值越大越模糊 */

    filter: blur(200px);

}

.container .color:nth-child(1){

    background-color: #fd746c;

    width: 800px;

    height: 800px;

    top: -450px;

}

.container .color:nth-child(2){

    background-color: #cf8bf3;

    width: 600px;

    height: 600px;

    bottom: -150px;

    left: 100px;

}

.container .color:nth-child(3){

    background-color: #fdb99b;

    width: 400px;

    height: 400px;

    bottom:50px;

    right:100px;

}

ul{

    position: relative;

    display: flex;

    z-index: 2;

}

ul li{

    position: relative;

    list-style: none;

    margin: 10px;

}

ul li a{

    position: relative;

    width: 80px;

    height: 80px;

    display: inline-block;

    border-radius: 10px;

    display: flex;

    justify-content: center;

    align-items: center;

    text-decoration: none;

    color: #fff;

    font-size: 32px;

    border: 1px solid rgba(255,255,255,0.4);

    border-right: 1px solid rgba(255,255,255,0.2);

    border-bottom: 1px solid rgba(255,255,255,0.2);

    /* 阴影 */

    box-shadow: 0px 5px 45px rgba(0,0,0,0.1);

    /* 背景模糊 */

    backdrop-filter: blur(2px);

    /* 动画过渡 */

    transition: all 0.5s;

    overflow: hidden;

}

ul li a:hover{

    /* 鼠标移入元素沿Y轴上移 */

    transform: translateY(-20px);

}

ul li a::before{

    content: "";

    position: absolute;

    top: 0px;

    left: 0px;

    width: 50px;

    height: 100%;

    background-color: rgba(255,255,255,0.5);

    /* 元素沿X轴45度横切，沿X轴右移150px */

    transform: skewX(45deg) translateX(150px);

    /* 动画过渡 */

    transition: all 0.5s;

}

ul li a:hover::before{

    /* 元素沿X轴45度横切，沿X轴左移150px */

    transform: skewX(45deg) translateX(-150px);

}

前言

在实际工作中，我们经常需要在项目中调用第三方API接口，获取数据，或者上报数据，进行数据交换和通信。

那么，调用第三方API接口会遇到哪些问题？如何解决这些问题呢？

这篇文章就跟大家一起聊聊第三方API接口的话题，希望对你会有所帮助。

1 域名访问不到

一般我们在第一次对接第三方平台的API接口时，可能会先通过浏览器或者postman调用一下，该接口是否可以访问。

有些人可能觉得多次一举。

其实不然。

有可能你调用第三方平台的API接口时，他们的接口真的挂了，他们还不知道。

还有一种最重要的情况，就是你的工作网络，是否可以访问这个外网的接口。

有些公司为了安全考虑，对内网的开发环境，是设置了防火墙的，或者有一些其他的限制，有些ip白名单，只能访问一些指定的外网接口。

如果你发现你访问的域名，在开发环境访问不通，就要到运维同学给你添加ip白名单了。

2 签名错误

很多第三方API接口为了防止别人篡改数据，通常会增加数字签名(sign)的验证。

sign = md5(多个参数拼接 + 密钥)

在刚开始对接第三方平台接口时，会遇到参数错误，签名错误等问题。

其中参数错误比较好解决，重点是签名错误这个问题。

签名是由一些算法生成的。

比如：将参数名和参数值用冒号拼接，如果有多个参数，则按首字母排序，然后再将多个参数一起拼接。然后加盐（即：密钥），再通过md5，生成一个签名。

如果有多个参数，你是按首字母倒序的，则最后生成的签名会出问题。

如果你开发环境的密钥，用的生产环境的，也可能会导致生产的签名出现问题。

如果第三方平台要求最后3次md5生成签名，而你只用了1次，也可能会导致生产的签名出现问题。

因此，接口签名在接口联调时是比较麻烦的事情。

如果第三方平台有提供sdk生成签名是最好的，如果没有，就只能根据他们文档手写签名算法了。

3 签名过期

通过上面一步，我们将签名调通了，可以正常访问第三方平台获取数据了。

但你可能会发现，同一个请求，15分钟之后，再获取数据，却返回失败了。

第三方平台在设计接口时，在签名中增加了时间戳校验，同一个请求在15分钟之内，允许返回数据。如果超过了15分钟，则直接返回失败。

这种设计是为了安全考虑。

防止有人利用工具进行暴力破解，不停伪造签名，不停调用接口校验，如果一直穷举下去的话，总有一天可以校验通过的。

sign = md5(多个参数拼接 + 密钥 + 时间戳)

因此，有必要增加时间戳的校验。

如果出现这种情况，不要慌，重新发起一次新的请求即可。

4 接口突然没返回数据

如果你调用第三方平台的某个API接口查询数据，刚开始一直都有数据返回。

但突然某一天没返回数据了。

但是该API接口能够正常响应。

不要感到意外，有可能是第三方平台将数据删除了。

我对接完第三方平台的API接口后，部署到了测试环境，发现他们接口竟然没有返回数据，原因是他们有一天将测试环境的数据删完了。

因此，在部署测试环境之前，要先跟对方沟通，要用哪些数据测试，不能删除。

5 token失效

有些平台的API接口在请求之前，先要调用另外一个API接口获取token，然后再header中携带该token信息才能访问其他的业务API接口。

在获取token的API接口中，我们需要传入账号、密码和密钥等信息。每个接口对接方，这些信息都不一样。

我们在请求其他的API接口之前，每次都实时调用一次获取token的接口获取token？还是请求一次token，将其缓存到redis中，后面直接从redis获取数据呢？

很显然我们更倾向于后者，因为如果每次请求其他的API接口之前，都实时调用一次获取token的接口获取token，这样每次都会请求两次接口，性能上会有一些影响。

如果将请求的token，保存到redis，又会出现另外一个问题：token失效的问题。

我们调用第三方平台获取token的接口获取到的token，一般都有个有效期，比如：1天，1个月等。

在有效期内，该API接口能够正常访问。如果超过了token的有效期，则该API接口不允许访问。

好办，我们把redis的失效时间设置成跟token的有效期一样不就OK了？

想法是不错，但是有问题。

你咋保证，你们系统的服务器时间，跟第三方平台的服务器时间一模一样？

我之前遇到过某大厂，提供了获取token接口，在30天内发起请求，每次都返回相同的token值。如果超过了30天，则返回一个新的。

有可能出现这种情况，你们系统的服务器时间要快一些，第三方平台的时间要慢一些。结果到了30天，你们系统调用第三方平台的获取token接口获取到了token还是老的token，更新到redis中了。

过一段时间，token失效了，你们系统还是用老的token访问第三方平台的其他API接口，一直都返回失败。但获取新的token却要等30天，这个时间太漫长了。

为了解决这个问题，需要捕获token失效的异常。如果在调用其他的API接口是发现token失效了，马上请求一次获取token接口，将新的token立刻更新到redis中。

这样基本可以解决token失效问题，也能尽可能保证访问其他接口的稳定性和性能。

6 接口超时

系统上线之后，调用第三方API接口，最容易出现的问题，应该是接口超时问题了。

系统到外部系统之间，有一条很复杂的链路，中间有很多环节出现问题，都可能影响API接口的相应时间。

作为API接口的调用方，面对第三方API接口超时问题，除了给他们反馈问题，优化接口性能之外，我们更有效的方式，可能是增加接口调用的失败重试机制。

例如：

int retryCount=0;

do {

   try {

      doPost();

      break;

   } catch(Exception e) {

     log.warn("接口调用失败")

     retryCount++;

   }

} where (retryCount <= 3)

如果接口调用失败，则程序会立刻自动重试3次。

如果重试之后成功了，则该API接口调用成功。

如果重试3次之后还是失败，则该API接口调用失败。

7 接口返回500

调用第三方API接口，偶尔因为参数的不同，可能会出现500的问题。

比如：有些API接口对于参数校验不到位，少部分必填字段，没有校验不能为空。

刚好系统的有些请求，通过某个参数去调用该API接口时，没有传入那个参数，对方可能会出现NPE问题。而该接口的返回code，很可能是500。

还有一种情况，就是该API接口的内部bug，传入不同的参数，走了不同的条件分支逻辑，在走某个分支时，接口逻辑出现异常，可能会导致接口返回500。

这种情况做接口重试也没用，只能联系第三方API接口提供者，反馈相关问题，让他们排查具体原因。

他们可能会通过修复bug，或者修复数据，来解决这个问题。

8 接口返回404

如果你在系统日志中发现调用的第三方API接口返回了404，这就非常坑了。

如果第三方的API接口没有上线，很可能是他们把接口名改了，没有及时通知你。

这种情况，可以锤他们了。

还有一种情况是，如果第三方的API接口已经上线了，刚开始接口是能正常调用的。

第三方也没有改过接口地址。

后来，突然有一天发现调用第三方的API接口还是出现了404问题。

这种情况很可能是他们网关出问题了，最新的配置没有生效，或者改了网关配置导致的问题。

总之一个字：坑。

9 接口返回少数据了

之前我调过一个第三方的API接口分页查询数据，接入非常顺利，但后来上线之后，发现他们的接口少数据了。

一查原因发现是该分页查询接口，返回的总页数不对，比实际情况少了。

有些小伙伴可能会好奇，这么诡异的问题我是怎么发现？

之前调用第三方API接口分页查询分类数据，保存到我们的第三方分类表中。

突然有一天，产品反馈说，第三方有个分类在分类树中找不到。

我确认之后，发现竟然是真的没有。

从调用第三方API接口的响应日志中，也没有查到该分类的数据。

这个API接口是分页查询接口，目前已经分了十几页查询数据，但还是没有查到我们想要的分类。

之前的做法是先调用一次API接口查询第一页的数据，同时查出总页数。然后再根据总页数循环调用，查询其他页的数据。

我当时猜测，可能是他们接口返回的总页数有问题。

于是，可以将接口调用逻辑改成这样的：

• 从第一页开始，后面每调用一次API接口查数据，页数就加1。然后判断接口返回的数据是否小于pageSize，


• 如果不小于，则进行下一次调用。


• 如果小于，则说明已经是最后一页了，可以停止后续调用了。

验证之后发现这样果然可以获取那个分类的数据，只能说明第三方的分页查询接口返回的总页数比实际情况小了。

10 偷偷改参数了

我之前调用过某平台的API接口获取指标的状态，之前根据双方约定的状态有：正常和禁用 两种。

然后将状态更新到我们的指标表中。

后来，双方系统上线运行了好几个月。

突然有一天，用户反馈说某一条数据明明删除了，为什么在页面上还是可以查到。

此时，我查我们这边的指标表，发现状态是正常的。

然后查看调用该平台的API接口日志，发现返回的该指标的状态是：下架。

what？

这是什么状态？

跟该平台的开发人员沟通后，发现他们改了状态的枚举，增加了：上架、下架等多个值，而且没有通知我们。

这就坑了。

我们这边的代码中判断，如果状态非禁用状态，都认为是正常状态。

而下架状态，自动被判断为正常状态。

经过跟对方沟通后，他们确认下架状态，是非正常状态，不应该显示指标。他们改了数据，临时解决了该指标的问题。

后来，他们按接口文档又改回了之前的状态枚举值。

11 接口时好时坏

不知道你在调用第三方接口时，有没有遇到过接口时好时坏的情况。

5分钟前，该接口还能正常返回数据。

5分钟后，该接口返回503不可用。

又过了几分钟，该接口又能正常返回数据了。

这种情况大概率是第三方平台在重启服务，在重启的过程中，可能会出现服务暂时不可用的情况。

还有另外一种情况：第三方接口部署了多个服务节点，有一部分服务节点挂了。也会导致请求第三方接口时，返回值时好时坏的情况。

此外还有一种情况：网关的配置没有及时更新，没有把已经下线的服务剔除掉。

这样用户请求经过网关时，网关转发到了已经下线的服务，导致服务不可用。网关转发请求到正常的服务，该服务能够正常返回。

如果遇到该问题，要尽快将问题反馈给第三方平台，然后增加接口失败重试机制。

12 文档和接口逻辑不一致

之前还遇到一个第三方平台提供的API查询接口，接口文档中明确写明了有个dr字段表示删除状态。

有了这个字段，我们在同步第三方平台的分类数据时，就能够知道有哪些数据是被删除的，后面可以及时调整我们这边的数据，将相关的数据也做删除处理。

后来发现有些分类，他们那边已经删除了，但是我们这边却没删除。

这是啥情况呢？

代码逻辑很简单，我review了一下代码，也没有bug，为什么会出现这种情况呢？

追查日志之后发现，调用第三方平台获取分类接口时，对方并没有把已删除的分类数据返回给我们。

也就是说接口文档中的那个dr字段没有什么用，接口文档和接口逻辑不一致。

这个问题估计好多小伙伴都遇到过。

如果要解决这个问题，主要的方案有两种：

1. 第三方平台按文档修改接口逻辑，返回删除状态。


2. 我们系统在调用分类查询接口之后，根据分类code判断，如果数据库中有些分类的code不在接口返回值中，则删除这些分类。

13 欠费了

我们调用过百度的票据识别接口，可以自动识别发票信息，获取发票编号和金额等信息。

之前是另外一个同事对接的接口，后来他离职了。

发票识别功能上线，使用了很长一段时间，一直都没有出问题。

后来，某一天，生产环境用户反馈发票识别不了了。

我查询了相关服务的日志，没有发现异常，这就奇怪了。

打开代码仔细看了一下，发现那位同事的代码中调用第三方的API接口，接收响应数据时，直接转换成了对象，没有打印当时返回的字符串。

莫非，接口返回值有问题？

后来，我增加了日志，打印出了该接口真正的返回内容值。

原因一下查到了，原来是欠费了。

如果出现该了异常，百度的API接口返回的数据结构，用之前那位同事的实体有些参数没法获取到。

这是一个不小的坑。

我们在接收第三方API接口返回数据时，尽可能先用字符串接收返回值，然后将字符串转换成相应实体类，一定要将该返回值在日志中打印出来，方便后面定位问题。

不要直接用实体对象接收返回值，有些API接口，如果出现不同的异常，返回的数据结构差异比较大。

有些异常结果可能是他们网关系统直接返回的，有些异常是他们业务系统返回的。

其实，我们之前还遇到过其他坑，比如：调用分类树查询接口，但第三方返回的数据有重复的id，我们这边该如何处理这种异常数据呢？

我们在job中循环调用第三方API接口获取数据，如果其中某一次调用失败了，是try/catch捕获异常呢？继续执行后面的调用，还是直接终止当前的程序？如果try/catch如何保证数据一致性？终止当前程序，该如何处理后续的流程？

最后说一句(求关注，别白嫖我)

如果这篇文章对您有所帮助，或者有所启发的话，帮忙扫描下发二维码关注一下，您的支持是我坚持写作最大的动力。

今日正能量: 当奇怪的需求越做越多的时候，证明你的眼光也正在变得广阔。

产品经理：加个需求，用户电脑设备如果快没电，我要暖心的告诉他该插上电源。

前端攻城狮：。。。他电脑不会自己提醒吗？

产品经理：你做不做？

前端攻城狮：做！

前言

随着技术的日益发展，web前端技术远比我们想象的强大。浏览器允许网站获取用户设备的电池状态信息，例如电量百分比，剩余电量，充电状态等等。我们可以使用这些信息，根据用户设备的电量调整我们的应用行为。在这篇中，我们将探讨如何在前端中获取电池信息，用到的就是关于 Battery Status API。

Battery Status API的使用

Battery Status API 是一个 Web API，允许 Web 应用程序访问用户设备的电池状态信息。使用这个 API，我们可以在不安装任何应用程序的情况下，从 Web 浏览器直接读取设备的电量信息。

获取设备电池信息的主要步骤如下：

// 请求电池信息

navigator.getBattery().then(function (battery) {

  // 后续代码

})

将返回一个 Promise 对象，它会解析为一个 BatteryManager 对象，我们可以使用它来读取设备的电池属性。

navigator.getBattery().then(function (battery) {

  // 获取设备电量剩余百分比

  var level = battery.level //最大值为1,对应电量100%

  console.log('Level: ' + level * 100 + '%')



  // 获取设备充电状态

  var charging = battery.charging

  console.log('充电状态: ' + charging)



  // 获取设备完全充电需要的时间

  var chargingTime = battery.chargingTime

  console.log('完全充电需要的时间: ' + chargingTime)



  // 获取设备完全放电需要的时间

  var dischargingTime = battery.dischargingTime

  console.log('完全放电需要的时间: ' + dischargingTime)

})

监听电池状态变化

为了更好地反映用户设备的电池状态，我们可以在前端中添加事件来监视电池状态的变化。例如，当设备的电池电量改变时，会触发事件。一些给大家列举几个常用事件：

navigator.getBattery().then(function (battery) {

  // 添加事件，当设备电量改变时触发

  battery.addEventListener('levelchange', function () {

    console.log('电量改变: ' + battery.level)

  })



  // 添加事件，当设备充电状态改变时触发

  battery.addEventListener('chargingchange', function () {

    console.log('充电状态改变: ' + battery.charging)

  })



  // 添加事件，当设备完全充电需要时间改变时触发

  battery.addEventListener('chargingtimechange', function () {

    console.log('完全充电需要时间: ' + battery.chargingTime)

  })



  // 添加事件，当设备完全放电需要时间改变时触发

  battery.addEventListener('dischargingtimechange', function () {

    console.log('完全放电需要时间: ' + battery.dischargingTime)

  })

})

兼容性

兼容性方面，Battery Status API 并不适用于所有的设备和操作系统，开发人员需要进行兼容性处理，以确保我们的应用可以在所有的设备上运行。以下是该API对应的兼容性视图：

通过 Battery Status API 获取设备电池信息是一种很强大的方法，可以根据设备电池状态来优化应用程序的行为。需要注意的是，此 API 不适用于所有设备和操作系统，并且某些设备生产商可能不允许共享电池信息。