绑定大量的的v-model，导致页面卡顿的解决方案

设计图如下：

页面布局看着很简单使用element组件，那就完蛋了，因为是大量的数据双向绑定，所以使用组件，延迟非常高，高到什么程度，请求100条数据到渲染到页面上，要10-12s，特别是下拉选择的时候，延迟都在2-3s，人麻了老铁！！！

卡顿的原因很长一段时间都是在绑定v-model，为什么绑定v-model会很卡呢，请求到的每一条数据有14个数据需要绑定v-model，每次一请求就是100个打底，那就是1400个数据需要绑定v-model；而且组件本身也有延迟，所以这个方案不能采用，那怎么做呢？
我尝试采用原生去写，写着写着，哎解决了！！！惊呆了

做完后100条数据页面渲染不超过2s，毕竟还是需要绑定v-model，能在2s内，我还是能接受的吧；选择和输入延迟基本没有

下面就来展示一下我的代码，写的不好看着玩儿就好了：

请求到的数据：

methods这两个事件做的什么事儿呢，就是手动将数据绑定到数据上去也就是row上如图：

当然还有很多解决方案

大家好，我是程序员马晓博，目前从事前端行业已有5年有余，而近期由于被裁员有一段时间，也开始回顾自己的过往，发现自己以前在职场中，做过不少傻事，这里就写篇文章来记录下。曾经的犯傻已不可避免，索性公之于众，坦然面对。

ps: 像一直戴工牌，故意露个工牌带子在外面就不说了，谁还没年轻过呢？还真谁也别笑话谁哈哈。

自诩正义强出头

这是我在腾讯实习的时候遇到的，故事很简单，有个同事加了一个全局错误捕获的逻辑，导致原本有报错但是能够正常运行的程序，出现了线上 bug。

此时团队间要追究责任，认为是加了全局捕获错误的同事的责任。从现在的视角看，加了全局错误捕获同事自然是有问题的，但是当时的我，非常正义的认为，写 bug 的人才应该承担责任，而为了让代码更健壮写了全局错误捕获的同事是没有错的。

现在回想起当时自己义正严辞的发言，真是太年轻啦。

更何况这事我连当事人都算不上，只能安慰自己：谁还没年轻过呢？

平易近领导

这个事，也是发生在腾讯实习期间。

在来实习之前的我，深受互联网扁平化管理，工位不做区别，这些非常先进的思想影响，到了腾讯之后，听领导说，自己平时喜欢游泳，我一想我也喜欢啊，就直接跑领导工位上问，你平时在哪里游泳？

吓的我的直属上级，直接跑出来拉住我，我给你推荐，我带你游泳。

还有一次是，午休一起打王者荣耀，人多了把我空出来了，我就指导领导玩亚瑟，上来就说你这出装太肉了，没一点伤害，要怎么怎么玩。

我现在还能想起来他当时的眼神，你，是在教我做事？

对于领导，毫无距离感。这应该是很多年轻人都会有的心态，还会认为这就是年轻人的本色，是互联网的特色，而且会对奉承领导的人嗤之以鼻。

当然，互联网公司文化本身也都提倡这种，没有上下级，大家都能上。也就是倡导所谓扁平化管理，工位也是领导普通员工没区别。

曾经的我认为这一切都是问题不大的，就是扁平化，互联网就是不一样，但是透过一些其他行业的人，我虽不介意工位情况，但是难免对其底层所宣扬的扁平化产生一定的怀疑。

ps: 这里放一个其他行业的人的对互联网工位的一些看法，我妹妹(中国移动打过一段时间工)来参观了我的工位之后说了一句话：这是工位？牛马间吧这是，我不以为然。直到我看到了她的工位，差别还真不是一般的大，好歹有隔间。这里应该放一张图，但是我没有，大家自行脑补吧哈哈。

自诩性格真诚直率

可谓是初生牛犊不怕虎吧，看到认为拉垮的代码，就会找同事当面聊，应该怎么怎么样，不应该怎么怎么写。

但是实际上，代码写成你认为的不合理的样子，往往是很多因素导致的，或工期，或对方当时也是初学者，或团队风格，或当时环境，或仅仅是对方对新方案的尝试。

上下文不了解，就开始吐槽。但是实际上人家的代码线上运行毕竟没有问题，没有故障的代码，本身就是一份合格的代码以及对方能力的认证。

而我的当面不友好交流，真是一点礼貌没有。还美名其曰，性格比较直率真诚。

好在当时的同事比较友好，并未计较，还在我后来选房子的时候还提供了很大的帮助，可叹没有仔细聆听对方的教诲终究还是没有十全十美。

夜郎自大而不自知

这是在我工作两年左右时候产生的一种感觉，觉得自己完成业务没有任何压力，而且还承担了一些比较重要的工作，从而有一种觉得自己很行的错觉。

但是当时面试很快就泼了一盆冷水，一般来讲，这个阶段做业务的同学，应对业务开发其实基本都没有什么问题。

但是国内对程序员的面试根本不限于业务，深挖一些知识点，理解其原理才是及格线。

而当时的我就是一直停留在使用阶段，用好本身没有问题，但是奈何不足以应对面试。

当然，心态还是最重要的。半瓶水晃荡而不自知才是最可怕的。

开弓来个回头箭

这个事，说实话有点羞于启齿。

是我工作大概第四个年头发生的，那时我在网易工作有一年多一些。

由于自己做了一个还算比较有技术难度的项目，想要寻求晋升，结果当时的晋升期答辩都结束了自己还不知晓。

心里有闷气，就开始面试找工作，也顺利拿到了几个涨幅非常不错的 offer。

开始跟上级提离职，哈哈，对方聊了下，也答应了。

结果我自己晚上就是睡不着，始终觉得自己这个时候走，是逃避，是逃兵。而且这个时候走，之前的积累就全部白费，新公司还得从零做起。

网上都说开弓没有回头箭。但是我就还是厚着脸皮来个回头箭。

不得不说，这个决定并不算蠢事，我在整件事里最蠢的是没有想好就和上级提了离职，虽然拿了 offer，但是没有想清楚就离职，是非常不成熟的表现。

好在我的上级，也主打一个真诚，也明确说明，想清楚了就行。

接下来一年的合作非常愉快，既有可视化埋点平台这样的业务技术都有挑战的项目，也有团队状态管理方案的产出，顺利在第二年迎来了自己的晋升。

这一次，愚蠢更多是在于自己没有想清楚就开弓，而真诚待人在我看来是双向必杀技，但真诚也为我后来吃亏埋下了种子。

整体而言，在网易的几年，领导，同事，大家都比较真诚，不屑于暗地里去做一些掉份的事情，也让我在职场上，形成了真诚而缺少防范的一个问题，这在我的下一步职业生涯中，给我带来了比较大的打击和跟头。

和同事交往讲真诚

这是我在离开网易后，选择的一家规模比较小的公司。

这时候，我工作已经整整 5年了，但是我过往的经历终究让我缺少了一些对同事的防范，大公司还好，大家相互之间，利益冲突不大，更多的是合作关系，同时由于大家或多或少都有自己的一点点的"骄傲"，所以其实并没有遇到一些因为利益冲突而导致的暗箭。

而过往的经历也在告诉我，真诚，并不会带来什么问题。

真诚无错，但是说者无意听者有心。

到新公司之后，也到了该带人的职级，此时，我还是主打真诚，很快就和团队融为一片。

几个关系近的同事和下属，知道我家里买了几套房，知道我平时看的书，知道我平时都在干啥，知道我对生活和工作的态度，知道我在工作上的安排。

这些事情，平时没有什么问题，但是当和有心的同事出现利益冲突的时候，这些事情就成为一把利剑，间接导致我失去了这份工作。

而这些利剑，是我亲手递给了对方。

对职场恶意的容忍

如果说真诚是给别人递了一把利剑，那么自己的容忍和锋芒的隐藏，是我自己收起了盾牌。

我在周围的同事身上，总能看到自己的影子，所以对于他们的恶意，往往有一定程度的容忍，我觉得，年轻人嘛，有点锋芒，很正常。

比如，当他们吹嘘自己写了一篇文章，获得了几个赞的时候，我往往是进行倾听并表示赞赏，虽然几个赞的文章其实真的很简单。又或者公开场合提出质疑，虽然我会讲道理，理可以辩明，但是对于这其中的恶意，我一般会选择包容。

但是就是这一步，自身锋芒的隐藏，在对方眼里却是得寸进尺的机会。

个人觉得，作为级别比对方高的，还是需要适时的漏出自身的锋芒，而不是仅仅倾听加赞赏，同时由于私下交往的密集，更导致对方的肆无忌惮。

从而亲手递给对方利剑，又自己收起盾牌。

只能说，在这条路上，我还是太稚嫩。

最后

以上，就是我个人认为在职场中，做过的一些蠢事。虽然已经工作了五年之久，但是这条路上，还是觉得太过稚嫩，谨以此文，纪念哪些蠢事！

ps: 不知道看完这篇的你，有没有回忆起一些类似的事情呢？欢迎交流哈。

// 还是那句话，都年轻过，谁也别笑话谁～

大家好，我是程序员晓博，目前从事前端行业已经有将近 6年。这六年，从最初的互联网鼎盛时期，到今年是未来十年内最好的一年，再到疫情时期的回暖，再到如今年年都喊寒冬的寒冬。从最初的 20k，到最近的一份 50k 的工作，再到如今的 "政府补贴" 2k，可谓是感悟颇多。

刚好最近 gap 一段时间，有所空闲，就整理下这几年的经历以及我所看到的行业的兴衰。

学生见闻

我是 2011 年读的大学，当时是电子科学与技术这个专业，并非计算机科班出身，更偏向于硬件编程，单片机，嵌入式，FPGA 这些会更多一些。

所以当时对于互联网行业的前端后端，并没有特别明确的概念，也对于 c++， java 这些语言的地位和适用性其实也没有明确的认知。

记得是 2012， 2013 年的时候，学校里经常有 java 培训班的宣传，说实话，那会还看不上 java，虽然自己也不会，但是学校里教的都是 c, c++， java 那会在我看来，更多的是一个 c++ 简化后的语言，所以对于我这个非科班的并没有提起兴趣。

现在回想起来，那时可真是入行的好时期，当然也是风云变换的几年。那会学校流传着一个段子: 你只要会安装 eclipse，就能找到一份美团的工作。而之后的一年，你得开发过自己的 app，才能找到安卓开发工作。

不过当时更多的观念告诉我至少得读个研究生出来，所以我选择了读研而非直接工作。可以说是错过了互联网飞速发展的黄金时期，直接毕业就来到了今年是未来十年里最好的一年。

也就是在研究生阶段，我才慢慢了解到，外界的互联网大厂，其实已经分化出了移动端，前端，后端这样的岗位，当时的前端圈最为活跃，而移动端，后端，似乎都已经定型。而前端圈的新框架此起彼伏，从 react, vue, webpack，还有很多已经消失在历史中的框架。

在当时的就业情况下，前端的工资似乎是最高的，在加上当时的前端圈确实很活跃，而学习起来也比较简单。作为非科班的学生，自学前端上手最快，所以我选择了前端作为自己的就业方向。专业对口的硬件开发就不说了，工资实在是大相径庭。

但是话说回来，硬件开发如今的热门程度，并不亚于当时的软件开发。硬件开发培训，挑战 30w 年薪这样的培训班，在 2022 年左右也出现了，一如当时 2015 年左右 java 开发包就业那样的火热。

不过这个专业，其实还给我带来了一份现在看起来可以称为副业的东西：代写课程设计和毕业设计，因为是比互联网前后端更细分的赛道，所以竞争并不激烈，我还是接到了不少的单子，但是由于自己本身也是学生，所以定价很低，基本按照 100/h 的费用在收，也有做代码复用的整合，但是在硬件这一块，它的售后并不像软件这样，往往需要花费时间帮用户在板子上走通，这一部分是比较花费时间的。也在研究生阶段尝试过转项目的方式来获取收益，但是由于定价过低以及单子并不多的问题，而没有继续。不过如今想来，借助 chatgpt 等 AI 工具，定价确实还能更低(尤其是包含论文的单子)。

第一份实习

出于提升自身竞争力的考虑，我在研究生阶段就开始了边自学，边找实习。好在自学的时间比较早，准备的也比较充分，顺利拿到了腾讯等几家公司的实习。

当时虽说还处于互联网发展的时期，但是竞争其实就已经比较激烈了，没有实习进大厂基本就是 hard 模式，我也是面试了 n 家公司，才拿到的 offer。

不过腾讯这个部门虽然在面试的时候，会问一些比较现代技术的问题，但是实际进去后，是写的 php 和 jquery。我的收获其实并不多，但是简历上好看一点，后来也顺利拿到了转正的 offer。

当时给的薪资应该是 16k 左右，还会加上城市的补贴大概 2k。不过最终因为房价的原因，并没有考虑留在深圳。

ps：我在实习的时候专门考察了深圳腾讯总部附近的房价，好像是 6w，确认过眼神，是掏光 6 个钱包也买不起的房子。不过据说一度涨到了 10w，现在没有再关注了，可能有所下跌吧。

说起来当时还有一个事让我印象比较深刻，也因此对阿里有了一些抵触。就是 2017：众多应届生被阿里毁了 offer。而对于这种事情，阿里给的解释是：拥抱变化。

可能马爸爸从那时就嗅到了危机，但这却是我第一次听说毁应届生 offer，非常败好感。ps: 现在这种毁应届生 offer 的事是非常常见啦。

似乎那时警钟已经敲响，但是我并没有未雨绸缪。

第一份工作

我是 2018 年毕业的，那会北京，上海，都有落户的限制，甚至还有一些积分制等似乎不欢迎应届生去上班的感觉。

那会刚毕业，可谓是心比天高，落个户都这么麻烦，我还不想去呢！还不如人深圳的口号，来了就是深圳人。而当时阿里的总部，就在杭州，而且杭州只要是大学生，立马就能落户，立马能摇号买房。而当时房价也比较亲民 (确认过眼神，是掏光钱包可以买得起的价格)。

所以基本上只找杭州的工作。最终入职了当时比较热门的 p2p 领域的独角兽，51 信用卡。

当时的 51信用卡，可以说是 p2p 领域的一只牛逼独角兽，甚至这家公司的缩写就是 51NB。

不过以我当时的认知，入职 51信用卡，纯粹是因为 20k 的薪资，以及全额报销来回路费。要知道当时 BAT 虽然有报销，但是实际上都有各种限制和上限。

ps: 以我当时的认知，几乎没有任何犹豫，我就关闭了我的副业通道，因为我觉得，精进前端技术，带来的收益更大，毕竟一个月 20k 的收入，更别提还有 4个月加的年终收入了。而这份副业，一方面对主业没有提升，同时还要消耗比较大的精力(主要集中在给学生讲解代码以及售后上)，收入也就几千块而且时间比较集中，很难兼顾。

现在回过头来看，真的是误打误撞赶上了 p2p 行业的末班车。起始薪资确实不错，但是很快就来到了国家严控 p2p 行业的开端。

最终，入职当年，就遇到了一波一波的裁员，从开始的 n + 3，到 n + 2 再到 n + 1，可谓是一波一波的裁员。也包括了应届生。一如现在，应届生也还是裁员重灾区。

也因为 51 当时是杭州互联网第一波开启的裁员，还裁了应届生。口碑急转直下，但是很快就迎来了反转，隔壁滴滴，微店等也迅速开启裁员模式，仅仅只有 n + 1。

ps: 在 51 的第一年，是有年会的。第二年，年会倒是有，但是主题就是一句话，今年将是接下来十年内，最好的一年。也是这一年 2019，p2p 彻底宣告结束，51 也出现了警车上门的事件。最终借贷业务转型为依赖于银行的借贷业务。也结束了接近 10% 的储蓄利率时代。

短暂的阿里之旅

2020 年年初，p2p 行业宣告结束叠加疫情之初，悲观情绪四处蔓延。我在 51 的旅程也渐渐走到了尾声。

当时面试了字节和阿里。彼时的字节跳动，在杭州名气和规模还没有如今这么大。权衡之下选择了名气更盛，当时口碑更好的阿里。但是我对于字节的判断，实在是偏差的离谱，看着如今蒸蒸日上的字节，真是后悔莫及。

但是进了阿里，说实话是真有些不适应。

一方面生活上，不提供纸巾，让我颇为诧异，而时不时的团队聚餐竟然是 AA 也让我非常不适应。

当然，对方看我也很奇怪，说了一句话，感觉你是外企来的 (ps: 如今的 51信用卡还是有点小而美的感觉，各项业务依托也还在继续，也有露营等新业务的开拓，老板自由后也还在继续折腾着)。

因为疫情的原因，我并没有经历百阿培训。但是有一本小册子，写着价值观。让我印象深刻的是，"此时此刻，非我莫属" 和 "不难，要你做什么"。

这两句话听起来都没有什么问题，鼓励人奋进并没有任何问题，但是以前的奋斗，伴随着可能的巨大的回报，而我当时的付出与回报，显然已经是大打折扣了。

那时还没有 pua 的说法，但是确实有一些话让我觉得不舒服，比如目标要跳起来才是 3.5，蹦起来才是 3.75，以及业务好和你一点关系都没有，你把业务做好了，也只能给你 3.25。必须得出一些技术项目，才能拿到好绩效。

而那种没有人会点明但是大家都在执行的道理：和我 kpi 有关的就是天，无关的就是已读不回，而已读不回，就是拒绝。更是让当时还非常稚嫩的我想要逃之夭夭。

这些也不能说错，但是这确实和我在 5信用卡当时围着业务转的风格大相径庭。

说回技术，阿里整个集团的基建可以说非常好，反而我所在的这个小前端团队的基建，赶不上 51前端团队的基建。

不论是脚手架，发布系统(比较让我震惊的是我当时团队的发布是自己丢文件到服务器上，测试正式环境的区分还是靠手动维护的一份文件)，开发流程，完全赶不上 51当时的丝滑程度。

可以说是对压力的逃避，也可以说是对这种环境的不适应，也可以说是对涨幅的不满，我很快就开启了下一段旅程。

现在回过头来看，当时离职，还是冲动占了大部分。一方面，随着后来业务接触的多了，能够理解当时那个小团队的基建差的原因：主要是业务形态，当时的小团队是 toB 的，要维护的仅仅是一个项目，自然在发布流程上的投入不会太多，而且收益也是远远不及 51 这种移动端几十上百个工程的发布工作来的实在。

而另一方面，所谓的深夜开会，不明说但是心里都清楚的加班氛围，以及唯 kpi 导向的风气，其实也不过是一种生存规则而已。强行说服自己接受也很容易。毕竟人生如戏，适应规则，利用规则，掌握规则，但凡能够想通这一点，当时坚持下来也非常容易。

长达三年的网易之旅

当处于阿里的水深火热之中时，一个在周末就完成了全部流程的网易团队，向我抛出了橄榄枝。

经过短暂的调整，我也就入职了这个团队，不曾想一待就是三年。此时的薪资来到了 30k 左右，但是由于当时这个团队独特的奖金制，月收入会比 base 高出不少。

团队的业务主要是直播，所以 toB 和 toC 的业务都有。基建上也比较完善，发布系统，组件库，脚手架，微前端，等等，相对更为繁荣。

这个团队并没有明确的技术项目的考核，还是以业务为主，大多数人，完成业务开发目标，就能够顺利拿到 3.5 的绩效，同时由于当时直播行业的繁荣，基本都会有一笔不菲的奖金。而技术项目属于锦上添花，确确实实能在最终的绩效上有所体现但是并不多。

但是恰恰是在这样的环境下，组内的同学在相对宽松的氛围下，更热衷于鼓捣技术项目，反而平时对技术的研究及讨论会更多一些。

这三年，也算是见证了业务的兴衰，从开始的营收暴涨开始出海，到最终营收暴跌收缩，到裁员。也不过短短三年。

现在回头来看，在这三年里，对于业务的了解更多的还是停留在表层，虽然当时觉得自己理解业务方的需求了，但是其实内部的很多玩法还是远非仅仅理解需求就能接触到的，什么大 R 运营，"军火商" 等等秀场直播的黑话，我是没有学到一点。

由于组内业务还算比较综合，c端页面的开发，b端后台都有所接触。同时业务之余还会有很多时间去做一些技术项目，比如我负责的 CloudIDE, WebIDE, 可视化埋点项目, 基于 zustand 的状态管理库, 均是这一时期的产物。

整体来讲，这三年不论是工作节奏，还是技术产出，都还算可以。

但是如今回过头来看，似乎这三年，对外界的关注，基本上有了一定的钝感，不像之前，对互联网的各个信息都会去了解看一下。反而这几年，说内敛沉稳也好，说闭门造车也好，说停留在自己的舒适圈内也好，除了技术层面的精进，对于整个行业的发展，都太过闭塞，仿佛只是重复一种舒适的生活过了三年：每天和老婆一起轮流开车上下班，顺便再健个身，住着自己的房子，还着公积金就能覆盖还有结余的带款。

如今回想起来，也正是这三年的经历，让我在技术上有所精进，但是对互联网行业的关注，反而有所下降。同时由于同事间的关系比较简单，也让我在人际交往上变得更加朴素真诚。

半年的小公司之旅

怎么说呢，好像人总是在不稳定的时候追求稳定，在稳定的时候追求不稳定。

所以在结束了网易的三年相对稳定的工作之后，我内心反而变得很躁动，想要去小公司，谋一番事业。

出来看机会之后，才发现外界的环境其实并没有平时了解的那么糟糕，确实不像之前机会那么多，但是确实也还有一些岗位。

在这之中，我选择了在发展业务第二曲线同时又有第一业务支持的说稳定又不稳定的公司 ---- 爱普拉维。

这家公司业务主要集中在海外，所以整体业务情况也还是非常客观。给出的薪资也比较客观，我的薪资也在这一时期，达到了 50k 左右。

不过入职之初，就经历了一些人事变动，如今想来，可以说是警醒，但是我应该是选择性的进行了忽视。心思沉浸在技术和一点点的管理上。

这个团队前端同学并不多，但是业务上除了常规的 h5 和少量的后台项目之外，还会存在一些 chrome 扩展逆向，爬虫项目的存在，而我被招进来的主要任务，也就是 chrome 扩展的逆向和爬虫项目。

在这一期间，我一度沉浸在了技术上的钻研中，从 webpack 的解码逆向，到 puppeteer 爬虫的实现，从 项目秒开的优化，到 svelte 的重构，都是对我之前技术经验的一个补充。也顺利在技术角度上在公司站稳了脚跟。度过了这个公司网上传言的不好过的试用期。

不过终归还是在人际交往上有所欠缺，叠加上公司的业务方向调整，导致了最终今年 1月份的离职。而这，也为我的职场画下了短暂的暂停键。

离职快小半年了

不知不觉离离职已经快小半年了，也顺利领到了失业金，也就是题目中提到的 2k。

这段时间从刚开始的玩乐，到中途的读书写文章，再到一些副业(对于无业人员来讲应该是主业)的探索。焦虑在所难免，未来也还比较迷茫，而其他主业的探索，说实话也没探索出来什么结果。

反倒是这段读书的时间给了我一些收获，一方面是 《穷爸爸富爸爸》中对于资产负债表的解释，我自己也做了一份，还参加了财富流沙盘游戏，对自己的财务状况有了更好的认知。另一方面便是 《认知觉醒》中关于焦虑的说法，一定程度上命中了当下的自己很多。

最后，就用《认知觉醒》中关于焦虑的根源来结束这篇文章吧：想同时做很多事，又想立即看到效果。自己的欲望大于能力，又极度缺乏耐心。人的天性就是避难驱易和急于求成。

ps: 避难驱易，这几个字实在太戳我了，也正是因为避难驱易，所以其实很多之前就想写的文章都拖拖拖，直到认识到是内心的避难驱易之后才开始控制自己开始输出，而也正是输出才让我注意到了自己之前没有注意到的点，才有了这篇文章以及 那些年，我在职场中做过的蠢事。

最后的最后，愿我们都有美好的未来！

一. 引言

为规范开发者的用户个人信息处理行为，保障用户的合法权益，自2023年9月15日起，对于涉及处理用户个人信息的小程序开发者，微信要求，仅当开发者主动向平台同步用户已阅读并同意了小程序的隐私保护指引等信息处理规则后，方可调用微信提供的隐私接口。

公告地址：关于小程序隐私保护指引设置的公告
developers.weixin.qq.com/miniprogram…

接下来我们将打造一个保姆级的隐私协议弹窗组件

二. 开发调试基础

划重点，看文档，别说为什么没有效果，没有弹窗

1. 更新用户隐私保护指引

小程序管理员或开发者可以根据具体小程序涉及到的隐私相关接口来更新微信小程序后台的用户隐私保护指引，更新并审核通过后就可以进行相关的开发调试工作。仅有在指引中声明所处理的用户信息，才可以调用平台提供的对应接口或组件。若未声明，对应接口或组件将直接禁用。

• ���知道怎么填写隐私协议，看看文档：用户隐私保护指引设置developers.weixin.qq.com/miniprogram…


• 哪些api需要用户点击同意隐私协议才可以使用的看这里：小程序用户隐私保护指引内容介绍developers.weixin.qq.com/miniprogram…

审核时间有人说十几分钟，我自己的给大家参考一下。

审核通过!审核通过!审核通过后才可以开发调试。

2.配置调试字段 "__usePrivacyCheck__": true

• 在 2023 年 9 月 15 号之前，在 app.json 中配置 "__usePrivacyCheck__": true 后，会启用隐私相关功能，如果不配置或者配置为 false 则不会启用。


• 在 2023 年 9 月 15 号之后，不论 app.json 中是否有配置 usePrivacyCheck，隐私相关功能都会启用。


• 所以在基于uni-app开发时，我们在 2023 年 9 月 15 号之前进行相关开发调试则需要在manifest.json文件mp-weixin中添加"__usePrivacyCheck__": true


• manifest.json文件源码视图

 "mp-weixin" : {

          "__usePrivacyCheck__": true

    },

3. 配置微信开发工具基础库

将调试基础库改为3.0.0以上。具体路径为:
微信开发者工具->详情->本地设置->调试基础库

以上配置完成后，即可看看效果，我在小程序后台设置了剪切板的隐私接口，果然，已经提示没有隐私授权不能使用了。

三. zero-privacy组件介绍

组件下载地址:ext.dcloud.net.cn/plugin?name…

组件的功能和特点

• 支持 居中弹出,底部弹出


• 不依赖第三方弹窗组件,内置轻量动画效果


• 支持自定义触发条件


• 支持自定义主题色


• 组件中最重要的4个api（只需用到前3个）：


• wx.getPrivacySetting 查询隐私授权情况 官方链接


• wx.onNeedPrivacyAuthorization 监听隐私接口需要用户授权事件。 官方链接


• wx.openPrivacyContract 跳转至隐私协议页面 官方链接


• wx.requirePrivacyAuthorize 模拟隐私接口调用，并触发隐私弹窗逻辑 官方链接

四. zero-privacy组件使用方法

在uniapp插件市场直接下载导入 uni_modules 后使用即可

• 最直接看到弹窗效果的测试方法

<template>

	<view class="container">

		<zero-privacy :onNeed='false'></zero-privacy>

	</view>

</template>

注意以上是测试方案，不建议实际开发中按上面的方法使用，推荐以下两种方法

• 在小程序首页等tabbar页面直接处理隐私弹窗逻辑

<template>

	<view class="container">

		<zero-privacy :onNeed='false' :hideTabBar='true'></zero-privacy>

	</view>

</template>

• 在页面点击某些需要用到隐私协议后处理隐私弹窗逻辑

<template>

	<view class="container">

		<view class="btn" @click="handleCopy">

			复制

		</view>

		<zero-privacy></zero-privacy>

	</view>

</template>

• 自定义内容使用

<template>

	<view class="container">

		<zero-privacy title="测试自定义标题" predesc="协议前内容" privacy-contract-name-custom="<自定义名称及括号>" subdesc="协议后内容协议后内容协议后内容.&#10;主动换行"></zero-privacy>

	</view>

</template>

五. zero-privacy组件参数说明

predesc 和 subdesc 的自定义内容,需要主动换行时在内容中添加实体字符 
 即可

六. zero-privacy组件运行效果

爬虫学得好，牢饭吃得饱！！！切记！！！

相信大家多少都会接触过爬虫相关的需求吧，爬虫在绝大多数场景下，能够帮助客户自动的完成部分工作，极大的减少人工操作。目前更多的实现方案可能都是以python为实现基础，但是作为java程序员，咱们需要知道的是，以java 的方式，仍然可以很方便、快捷的实现爬虫。下面将会给大家介绍两种以java为基础的爬虫方案，同时提供案例供大家参考。

一、两种方案

传统的java实现爬虫方案，都是通过jsoup的方式，本文将采用一款封装好的框架【webmagic】进行实现。同时针对一些特殊的爬虫需求，将会采用【selenium-java】的进行实现，下面针对两种实现方案进行简单介绍和演示配置方式。

1.1 webmagic

官方文档：webmagic.io/

1.1.1 简介

使用webmagic开发爬虫，能够非常快速的实现简单且逻辑清晰的爬虫程序。

四大组件

• Downloader：下载页面


• PageProcessor：解析页面


• Scheduler：负责管理待抓取的URL，以及一些去重的工作。通常不需要自己定制。


• Pipeline：获取页面解析结果，数持久化。

Spider

• 启动爬虫，整合四大组件

1.1.2 整合springboot

webmagic分为核心包和扩展包两个部分，所以我们需要引入如下两个依赖：

<properties>

    <webmagic.version>0.7.5</webmagic.version>

</properties>



<!--WebMagic-->

<dependency>

    <groupId>us.codecraft</groupId>

    <artifactId>webmagic-core</artifactId>

    <version>${webmagic.version}</version>

</dependency>

<dependency>

    <groupId>us.codecraft</groupId>

    <artifactId>webmagic-extension</artifactId>

    <version>${webmagic.version}</version>

</dependency>

到此为止，我们就成功的将webmagic引入进来了，具体使用，将在后面的案例中详细介绍。

1.2 selenium-java

官网地址：http://www.selenium.dev/

1.2.1 简介

selenium是一款浏览器自动化工具，它能够模拟用户操作浏览器的交互。但前提是，我们需要在使用他的机器（windows/linux等）安装上它需要的配置。相比于webmigc的安装，它要繁琐的多了，但使用它的原因，就是为了解决一些webmagic做不到的事情。

支持多种语言：java、python、ruby、javascript等。其使用代码非常简单，以java为例如下：

package dev.selenium.hello;



import org.openqa.selenium.WebDriver;

import org.openqa.selenium.chrome.ChromeDriver;



public class HelloSelenium {

    public static void main(String[] args) {

        WebDriver driver = new ChromeDriver();



        driver.get("https://selenium.dev");



        driver.quit();

    }

}

1.2.2 安装

无论是在windows还是linux上使用selenium，都需要两个必要的组件：

• 浏览器（chrome）


• 浏览器驱动 （chromeDriver）

需要注意的是，要确保上述两者的版本保持一致。

下载地址

chromeDriver：chromedriver.storage.googleapis.com/index.html

windows

windows的安装相对简单一些，将chromeDriver.exe下载至电脑，chrome浏览器直接官网下载相应安装包即可。严格保证两者版本一致，否则会报错。

在后面的演示程序当中，只需要通过代码指定chromeDriver的路径即可。

linux

linux安装才是我们真正的使用场景，java程序通常是要部署在linux环境的。所以我们需要linux的环境下安装chrome和chromeDriver才能实现想要的功能。

首先要做的是判断我们的linux环境属于哪种系统，是ubuntu、centos还是其他的种类，相应的shell脚本都是不同的。

我们采用云原生的环境，所有的服务均以容器的方式部署，所以要在每一个服务端容器内部安装chrome和chromeDiver。我们使用的是Alpine Linux，一个轻量级linux发行版，非常适合用来做Docker镜像。

我们可以通过apk --help去查看相应的命令，我直接给出安装命令：

# Install Chrome for Selenium

RUN apk add gconf

RUN apk add chromium

RUN apk add chromium-chromedriver

上面的内容，可以放在DockerFile文件中，在部署的时候，会直接将相应组件安装在容器当中。

需要注意的是，在Alpine Linux中自带的浏览器是chromium和chromium-chromedriver，且版本相应较低，但是足够我们的需求所使用了。

/ # apk search chromium

chromium-68.0.3440.75-r0

chromium-chromedriver-68.0.3440.75-r0

1.2.3 整合springboot

我们只需要在爬虫模块引入依赖就好了：

<dependency>

    <groupId>org.seleniumhq.selenium</groupId>

    <artifactId>selenium-java</artifactId>

</dependency>

二、三个案例

下面通过三个简单的案例，给大家实际展示使用效果。

2.1 爬取省份街道

使用webmagic进行省份到街道的数据爬取。注意，本文只提供思路，不提供具体爬取网站信息，请同学们自己根据使用选择。

接下来搭建webmagic的架子，其中有几个关键点：

• 创建页面解析类，实现PageProcessor。

import us.codecraft.webmagic.Page;

import us.codecraft.webmagic.Site;

import us.codecraft.webmagic.processor.PageProcessor;



/**

 * 页面解析

 *

 * @author wjbgn

 * @date 2023/8/15 17:25

 **/

public class TestPageProcessor implements PageProcessor {

    @Override

    public void process(Page page) {



    }



    @Override

    public Site getSite() {

        return site;

    }

    

    /**

     * 初始化Site配置

     */

    private Site site = Site.me()

            // 重试次数

            .setRetryTimes(3)

            //编码

            .setCharset(StandardCharsets.UTF_8.name())

            // 超时时间

            .setTimeOut(10000)

            // 休眠时间

            .setSleepTime(1000);

    }

• 实现PageProcessor后，要重写其方法process(Page page)，此方法是我们实现爬取的核心（页面解析）。通常省市区代码分为6级，所以常见的网站均是按照层级区分，我们是从省份开始爬取，即从第三层开始爬取。
  
  
  
  
  • 初始化变量
  
  
  
  

  @Override
  
  public void process(Page page) {
  
      // 市级别
  
      Integer type = 3;
  
      // 初始化结果明细
  
      RegionCodeDTO regionCodeDTO = new RegionCodeDTO();
  
      // 带有父子关系的结果集合
  
      List<Map<String, Object>> list = new ArrayList();
  
      // 页面所有元素集合
  
      List<String> all = new ArrayList<>();
  
      // 页面中子页面的链接地址
  
      List<String> urlList = new ArrayList<>();
  
  }
  
  

  
  
  
  
  • 根据不同级别，获取相应页面不同的元素
  
  
  
  

  if (CollectionUtil.isEmpty(all)) {
  
      // 爬取所有的市,编号，名称
  
      all = page.getHtml().css("table.citytable").css("tr").css("a", "text").all();
  
      // 爬取所有的城市下级地址
  
      urlList = page.getHtml().css("table.citytable").css("tr").css("a", "href").all()
  
              .stream().distinct().collect(Collectors.toList());
  
      if (CollectionUtil.isEmpty(all)) {
  
          // 区县级别
  
          type = 4;
  
          all = page.getHtml().css("table.countytable").css("tr.countytr").css("td", "text").all();
  
          // 获取区
  
          all.addAll(page.getHtml().css("table.countytable").css("tr.countytr").css("a", "text").all());
  
  
  
          urlList = page.getHtml().css("table.countytable").css("tr").css("a", "href").all()
  
                  .stream().distinct().collect(Collectors.toList());
  
          if (CollectionUtil.isEmpty(all)) {
  
              // 街道级别
  
              type = 5;
  
              all = page.getHtml().css("table.towntable").css("tr").css("a", "text").all();
  
              urlList = page.getHtml().css("table.towntable").css("tr").css("a", "href").all()
  
                      .stream().distinct().collect(Collectors.toList());
  
              if (CollectionUtil.isEmpty(all)) {
  
                  // 村，委员会
  
                  type = 6;
  
                  List<String> village = new ArrayList<>();
  
                  all = page.getHtml().css("table").css("tr.villagetr").css("td", "text").all();
  
                  for (int i = 0; i < all.size(); i++) {
  
                      if (i % 3 != 1) {
  
                          village.add(all.get(i));
  
                      }
  
                  }
  
                  all = village;
  
              }
  
          }
  
      }
  
  }
  
  

  
  
  
  
  • 定义一个实体类RegionCodeDTO，用来存放临时获取的code，url以及父子关系等内容：
  
  
  
  

  public class RegionCodeDTO {
  
  
  
      private String code;
  
  
  
      private String parentCode;
  
  
  
      private String name;
  
  
  
      private Integer type;
  
  
  
      private String url;
  
  
  
      private List<RegionCodeDTO> regionCodeDTOS;
  
  }
  
  

  
  
  
  
  • 接下来对页面获取的内容（code、name、type）进行组装和临时存储，添加到children中：
  
  
  
  

  // 初始化子集
  
  List<RegionCodeDTO> children = new ArrayList<>();
  
  // 初始化临时节点数据
  
  RegionCodeDTO region = new RegionCodeDTO();
  
  // 解析页面结果集all当中的数据，组装到region 和 children当中
  
  for (int i = 0; i < all.size(); i++) {
  
      if (i % 2 == 0) {
  
          region.setCode(all.get(i));
  
      } else {
  
          region.setName(all.get(i));
  
      }
  
      if (StringUtils.isNotEmpty(region.getCode()) && StringUtils.isNotEmpty(region.getName())) {
  
          region.setType(type);
  
          // 添加子集到集合当中
  
          children.add(region);
  
          // 重新初始化
  
          region = new RegionCodeDTO();
  
      }
  
  }
  
  

  
  
  
  
  • 组装页面链接，并将页面链接组装到children当中。
  
  
  
  

  // 循环遍历页面元素获取的子页面链接
  
  for (int i = 0; i < urlList.size(); i++) {
  
      String url = null;
  
      if (StringUtils.isEmpty(urlList.get(0))) {
  
          continue;
  
      }
  
      // 拼接链接，页面的子链接是相对路径，需要手动拼接
  
      if (urlList.get(i).contains(provinceEnum.getCode() + "/")) {
  
          url = provinceEnum.getUrlPrefixNoCode();
  
      } else {
  
          url = provinceEnum.getUrlPrefix();
  
      }
  
      // 将链接放到临时数据子集对象中
  
      if (urlList.get(i).substring(urlList.get(i).lastIndexOf("/") + 1, urlList.get(i).indexOf(".html")).length() == 9) {
  
          children.get(i).setUrl(url + page.getUrl().toString().substring(page.getUrl().toString().indexOf(provinceEnum.getCode() + "/") + 3
  
                  , page.getUrl().toString().lastIndexOf("/")) + "/" + urlList.get(i));
  
      } else {
  
          children.get(i).setUrl(url + urlList.get(i));
  
      }
  
  }
  
  

  
  
  
  
  • 将children添加到结果对象当中
  
  
  
  

  // 将子集放到集合当中
  
  regionCodeDTO.setRegionCodeDTOS(children);
  
  

  
  
  
  
  • 在下面的代码当中将进行两件事儿：
    
    
    
    
    • 处理下一页，通过page的addTargetRequests方法，可以进行下一页的跳转，此方法参数可以是listString和String，即支持多个页面跳转和单个页面的跳转。
    
    
    • 将数据传递到Pipeline，用于数据的存储，Pipeline的实现将在后面具体说明。
    
    
    
    
  
  
  
  

  // 定义下一页集合
  
  List<String> nextPage = new ArrayList<>();
  
  // 遍历上面的结果子集内容
  
  regionCodeDTO.getRegionCodeDTOS().forEach(regionCodeDTO1 -> {
  
      // 组装下一页集合
  
      nextPage.add(regionCodeDTO1.getUrl());
  
      // 定义并组装结果数据
  
      Map<String, Object> map = new HashMap<>();
  
      map.put("regionCode", regionCodeDTO1.getCode());
  
      map.put("regionName", regionCodeDTO1.getName());
  
      map.put("regionType", regionCodeDTO1.getType());
  
      map.put("regionFullName", regionCodeDTO1.getName());
  
      map.put("regionLevel", regionCodeDTO1.getType());
  
      list.add(map);
  
      // 推送数据到pipeline
  
      page.putField("list", list);
  
  });
  
  // 添加下一页集合到page
  
  page.addTargetRequests(nextPage);
  
  

  
  


• 当本次process方法执行完后，将会根据传递过来的链接地址，再次执行process方法，根据前面定义的读取页面元素流程的代码，将不符合type=3的内容，所以将会进入到下一级4的爬取过程，5、6级别原理相同。
  
  

  



• 创建Pipeline，用于编写数据持久化过程。经过上面的逻辑，已经将所需内容全部获取到，接下来将通过pipline进行数据存储。首先定义pipeline，并实现其process方法，获取结果内容，具体存储数据的代码就不展示了，需要注意的是，此处pipeline没有通过spring容器托管，需要调用业务service需要使用SpringUtils进行获取：
  
  

  public class RegionDataPipeline implements Pipeline{
  
  
  
  
  
  @Override
  
  public void process(ResultItems resultItems, Task task) {
  
  // 获取service
  
  IXXXXXXXXXService service = SpringUtils.getBean(IXXXXXXXXXService.class);
  
  // 获取内容
  
  List<Map<String, String>> list = (List<Map<String, String>>) resultItems.getAll().get("list");
  
  // 解析数据，转换为对应实体类
  
  // service.saveBatch
  
  }
  
  

  
  


• 启动爬虫
  
  

  //启动爬虫
  
  Spider.create(new RegionCodePageProcessor(provinceEnum))
  
          .addUrl(provinceEnum.getUrl())
  
          .addPipeline(new RegionDataPipeline())
  
          //此处不能小于2
  
          .thread(2).start()
  
  

  
  

2.2 爬取网站静态图片

爬取图片是最常见的需求，我们通常爬取的网站都是静态的网站，即爬取的内容都在网页上面渲染完成的，我们可以直接通过获取页面元素进行抓取。

可以参考下面的文章，直接拉取网站上的图片：juejin.cn/post/705138…

针对获取到的图片网络地址，直接使用如下方式进行下载即可：

url = new URL(imageUrl);

//打开连接

HttpURLConnection conn = (HttpURLConnection) url.openConnection();

//设置请求方式为"GET"

conn.setRequestMethod("GET");

//超时响应时间为10秒

conn.setConnectTimeout(10 * 1000);

//通过输入流获取图片数据

InputStream is = conn.getInputStream();

2.3 爬取网站动态图片

在2.2中我们可以很快地爬取到对应的图片，但是在另外两种场景下，我们获取图片将会不适用上面的方式：

• 需要拼图，且多层的gis相关图片，此种图片将会在后期进行复杂的图片处理（按位置拼接瓦片，多层png图层叠加），才能获取到我们想要的效果。


• 动态js加载的图片，直接无法通过css、xpath获取。

所以在这种情况下我们可以使用开篇介绍的selenium-java来解决，本文使用的仅仅是截图的功能，来达到我们需要的效果。具体街区全屏代码如下所示：

public File getItems() {

    // 获取当前操作系统

    String os = System.getProperty("os.name");

    String path;

    if (os.toLowerCase().startsWith("win")) {

        //windows系统

        path = "driver/chromedriver.exe";

    } else {

        //linux系统

        path = "/usr/bin/chromedriver";

    }

    WebDriver driver = null;

    // 通过判断 title 内容等待搜索页面加载完毕，间隔秒

    try {

        System.setProperty("webdriver.chrome.driver", path);

        ChromeOptions chromeOptions = new ChromeOptions();

        chromeOptions.addArguments("--headless");

        chromeOptions.addArguments("--no-sandbox");

        chromeOptions.addArguments("--disable-gpu");

        chromeOptions.addArguments("--window-size=940,820");

        driver = new ChromeDriver(chromeOptions);

        // 截图网站地址

        driver.get(UsaRiverConstant.OBSERVATION_POINT_URL);

        // 休眠用于网站加载

        Thread.sleep(15000);

        // 截取全屏

        File screenshotAs = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE);

        return screenshotAs;

    } catch (Exception e) {

        throw new RuntimeException(e);

    } finally {

        driver.quit();

    }

}

如上所示，我们获取的是整个页面的图片，还需要对截取的图片进行相应的剪裁，保留我们需要的区域，如下所示：

public static void cutImg(InputStream inputStream, int x, int y, int width, int height, OutputStream outputStream) {//图片路径，截取位置坐标,输出新突破路径

    InputStream fis = inputStream;

    try {

        BufferedImage image = ImageIO.read(fis);

        //切割图片

        BufferedImage subImage = image.getSubimage(x, y, width, height);

        Graphics2D graphics2D = subImage.createGraphics();

        graphics2D.drawImage(subImage, 0, 0, null);

        graphics2D.dispose();

        //输出图片

        ImageIO.write(subImage, "png", outputStream);

    } catch (IOException e) {

        e.printStackTrace();

    } finally {

        try {

            fis.close();

        } catch (IOException e) {

            throw new RuntimeException(e);

        }

    }

}

三、小结

通过如上两个组件的简单介绍，足够应付在java领域的大多数爬取场景。从页面数据、到静态网站图片，在到动态网站的图片截取。本文以提供思路为主，原理请参考相应的官方文档。

爬虫学得好，牢饭吃得饱！！！切记！！！

接上文：屠龙少年终成恶龙，前端转产品的我给前端挖了个坑

前情提要

大约一个月前，公司的医疗管理系统终于完工上线。后面一个周一，领导叫大家开会，说后面没有项目进来了，用不了这么多开发人员，原地宣布裁员。再后一周后，花 2000 招了个实习生，工作内容为系统维护。

工作内容

领导：由于我们工作内容很简单，事情轻松，基本就在页面上加加按钮就行，所以工资相对较少一些，是否接受？

实习生小李：能开实习证明吗？

领导：能的。

实习生小李：好的，谢谢老板。

领导：什么时候能入职？

实习生小李：现在。

工作来源

医疗系统是一个比较数据敏感的系统，现在医院那边需要添加一个十分钟时间没有在系统进行操作，则锁定电脑的功能，使用者再次使用时，必须输入密码。客户那边在系统对接群里发出需求时，并没有人回复（PS：人都裁完了），然后老板回复到：好的。

工作安排

领导：小李，我们有个医疗系统，需要添加锁屏功能，你处理一下，两天时间应该没问题吧？

实习生小李：（思索片刻）好的，有代码吗

（4小时之后）

领导：有的，我找下

（第二天10点）

实习生小李：王总，代码找到了没有

（第二天12点）

领导：没代码改不了吗？

实习生小李：（瑟瑟发抖）我试试

（第二天14点）

实习生小李：王总，是那种长时间不操作就锁定系统的功能吗

领导：是的

实习生小李：多久不操作才锁

领导：十分钟，锁了需要输入密码才能使用

实习生小李：但是我们医疗系统没有密码功能

领导：客户电脑有密码啊

实习生小李：是锁电脑系统吗

领导：对

实习生小李：（若有所思）我试试

实现过程

实习生小李：魔镜魔镜，我们有个医疗系统，需要做一个十分钟不操作电脑，就锁定用户电脑系统的功能，在没有源代码的情况下如何实现？

魔镜：好的，在没有源代码的情况下为医疗系统添加十分钟不操作电脑就锁定用户电脑系统的功能，可以使用 sys-shim 实现。

第一步，创建一个目录例如 medical-system ，目录里有以下两个文件：

• package.json 文件用来配置 sys-shim


• preload.js 用来向医疗系统添加功能

第二步

在 package.json 中编写内容如下

{

  "browserArguments": "--disable-web-security --allow-running-insecure-content ",

  "form": {

    "right": "1300",

    "bottom": "800"

  },

  "page": "https://www.baidu.com/"

}

• browserArguments 用来指定浏览器参数，这里配置为允许跨域以方便注入代码


• form 用来控制窗口如何显示，这里表示窗口大小


• page 表示医疗系统的页面

在 preload.js 中编写内容如下

new Promise(async function () {

  window.main = await new window.Sys({ log: true })

  // 设置倒计时时间，为了测试方便，这里改为 30 秒

  const TIMEOUT = 0.5 * 60 * 1000;

  

  // 声明一个变量来存储 setTimeout 的引用

  let timeoutId = null;

  

  // 定义一个函数来重置倒计时并在2分钟后打印日志

  function startInactivityCheck() {

    // 清除之前的倒计时（如果有的话）

    if (timeoutId !== null) {

      clearTimeout(timeoutId);

    }

  

    // 设置一个新的倒计时

    timeoutId = setTimeout(function() {

      // 锁定系统

      window.main.native.sys.lock()

    }, TIMEOUT);

  }

  

  // 为 body 元素添加点击事件监听器

  document.body.addEventListener('click', function() {

    console.log("检测到点击事件，重新开始计时。");

    // 重置倒计时

    startInactivityCheck();

  });

  

  // 初始化倒计时

  startInactivityCheck();

})

• sys.lock() 方法用于锁定操作系统。

第三步，生成应用程序

npx sys-shim pack --input medical-system

运行该命令后，会在当前目录生成一个名为 medical-system.exe 的可执行文件。它封装了医疗系统这个 web 程序，并在里面添加了锁屏功能。

• pack 指定表示打包应用


• --input 参数表示要打包的目录

--input 参数也可以是线上的网页，比如：

npx sys-shim pack --input https://www.baidu.com/

即可获取一个可以调用操作系统 api 的 web 应用。

交付反馈

用户：以前我们还需要进入浏览器输入网址才能进入系统，现在直接在桌面上就能进入，并且还有安全锁屏功能，非常好！

领导：小李干得不错，但没有在规定的时间内完成，但由于客户反馈不错，就不扣你的考核分了。

实习生小李：（不得其解）谢谢老板。

后记

不知不觉，又到了周五，这是公司技术分享会的时候。当前公司技术人员只有实习生小李，由小李负责技术分享。

宽旷的会议室里，秘书、领导、小李三人面面相觑，小李强忍住尴尬，开始了自己的第一次技术分享：

实习生小李：感谢领导给我的工作机会，在这份工作里，我发现了 sys-shim 这个工具，它可以方便的在已有的 web 页面中添加系统 api，获取调用操作系统层面功能的能力，比如关机、锁屏。

领导：（好奇）那他可以读取电脑上的文件吗？

实习生小李：可以的，它可以直接读取电脑上的文件，例如电脑里面的文档、照片、视频等。

突然领导脸色一黑，看了一眼秘书，并关闭了正在访问的医疗系统，然后在技术分享考核表上写下潦潦草草的几个字：考核分-5。

续集：托领导大福！前端实习生用 vue 随手写了个系统修复工具，日赚 300

提示

大家可以直接运行这个命令生成 app 体验：

npx sys-shim pack --input https://www.baidu.com/

生成后的 app 可以右键解压，看到内部结构。如果遇到问题，可以在这里提交，方便追溯，我会及时解答的。

参考

• sys-shim 文档


• sys-shim 源码仓库


• 实现细节请参考 electron 和 tauri 都不想用，那就自己写个想用的吧

一、业务需求

• 给定一个图片作为参考


• 可配置画笔颜色、粗细


• 可通过手势生成实际轨迹


• 可通过手势来圈选轨迹


• 可撤销、删除轨迹


• 可操作轨迹


• 可缩放、拖动


• 背景网格，且背景网格可缩放和拖动


• 参考图片可缩放、偏移


• 手势处理系统，单指绘制、双指缩放、三指拖动


• 需要一个禁止绘制区域，方便用户在平板上有手掌的支撑区域

二、技术选型

因为涉及到轨迹、操作轨迹两点，
svg无法满足大量且复杂的轨迹，canvas没法操作轨迹，所以从 fabricjs/konva 中选型，
因 fabricjs 使用人数更多，所以采取了其作为技术选型。

三、fabric 原理

• 通过其内置的几何对象来创建图形


• 维护一个对象树


• 将对象树通过 canvas-api 绘制在实际的 canvas 上

因此，fabric 能做非常多的优化手段

• 已渲染的节点可通过子canvas做缓存


• 对比新旧对象树能做差值更新


• 虚拟画布，类似于虚拟滚动，只渲染可视化的区域

四、模块拆分

• header：与业务相关


• toolBar：工具栏


• sidebar：与业务相关


• canvas：绘制画板

五、架构设计

六、问题收集

6.1 性能问题

• 圈选是实时的，即判断一个多边形是否相交于或包含于一条复杂轨迹，因为使用了射线法，当遇到大量轨迹的时候，可能会卡顿。目前做了多重优化手段，比如函数节流、先稀疏复杂轨迹的点、然后判断图形的占位区域是否相交、然后判断图形的线段之间是否相交、然后判断是否包含关系。


• 轨迹的实时生成，在一长串touchmove事件中，使用一个初始化的polyline，后续更改其点集，这样只需要实例化一个对象，性能高。


• touchmove回调里执行复杂的逻辑，这会阻塞touchmove的触发频率，我们将touchmove里的回调通过settimeout放到异步队列中，这样就剥离了touchmove事件层 和 回调函数处理层，这样touchmove的触发频率就不会被影响

6.2 禁止绘制区域

该需求无法实现，因为当我们手掌放在平板上时，会触发系统级别的误触识别算法，阻止所有的触摸事件，所以我们没办法在页面上实现该功能。

touch事件

一个屏幕上可以有多个touch触摸点，这些触摸点绑定的target是可以多个的
touchEvent对象有如下重要属性

特别注意点：

平板调试手段-chrome浏览器

前言

瀑布流布局，不管是在pc端还是手机端都很常见，但是我们通常都是列固定。今天来实现一下小红书的响应式瀑布流。后面有仓库地址。

正文

还是先来看看效果

原理：

对每一个item都使用绝对定位，left和top都是0，最后根据容器大小、item的height通过计算来确定item的transform值

接下来从易到难来解析一下实现

初始化数据

列表怎么可以没有数据，先来初始化一下数据

确定列数及列大小

由于是响应式，我们要去监听列表容器的大小变化并记录容器宽度，这样才能做出相应的处理

根据监听得到的容器大小信息，我们可以确定每行个数和每一个item的宽度

确定列表中item位置

确定item的位置，那么我们只需要确定transform值就可以了，这也是整个实现的核心。我们还需要解决几个问题

item放置的原理图，放置在当前最低高度的下面

更新item高度

当我们第一次运行的时候，每一个item的高度一定都是随机生成的，现在我们要确定item的实际高度。在这里我们还可优化一下，使用懒加载和底部加载，提升性能。这两个在这里就不讲了，不懂的可以去搜一下。

下面代码一共两个作用

根据滚动值判断是否加载图片，加载图片后触发父亲更新高度函数

父亲接受到新的高度并更新高度，然后去重新计算transform值和item高度

完整代码

仓库地址

结语

感兴趣的可以去试试

数字化时代，显示器是我们日常生活和工作中不可或缺的一部分。
无论是在电脑、手机、平板还是电视上，我们都依赖显示器来呈现图像和文字。然而，对于许多人来说，显示器分辨率这一概念可能并不十分清晰。

分辨率是影响显示器性能和视觉效果的关键因素之一。它决定了图像的清晰度、细节和整体观感。
因此，了解显示器分辨率的知识对于我们选择和使用显示设备至关重要。

本文将向大家介绍关于显示器分辨率的一些小知识，希望能够帮助大家更好地选择合适的显示器，并提升在使用显示设备时的体验。

1. 常用的分辨率

2. 一些术语

关于显示器，最常见的三个术语就是：

2.1. 刷新率

刷新率（Refresh rate）是指屏幕硬件每秒刷新以显示图像的速率，通常以赫兹（Hz）为单位。
刷新率是指显示器的能力，简单理解就是每秒屏幕能切换多少个图像。

刷新率越高的显示器，显示的视频越流畅。
不过，由于人眼有视觉暂留的能力，一般60Hz左右的液晶屏已经很流畅了。

2.2. 帧速率

帧速率（Frame rate）是指视频或游戏每秒传输的图像帧数，通常以FPS（每秒帧数）为单位。
帧速率一般取决于视频或者游戏本身，与显示器关系不大。

帧速率越高，视频和游戏的清晰度和流畅度越高，当然，占用的硬盘空间也越大，对显卡要求也越高。

在实际使用中，如果帧速率高于刷新率，可能会出现屏幕撕裂等现象，因为显示器无法完全跟上图像的更新速度。
而如果刷新率高于帧速率的话，对显示影响不大，但是对显示器来说，有点大材小用。
因此，刷新率和帧速率的匹配和协调对于获得最佳的视觉体验，以及购买显示器时考虑性价比至关重要。

2.3. 纵横比

纵横比（Aspect ratio）概念比较简单，是指水平像素数与垂直像素数的比率。
对于视频和游戏，一般可以调节输出的纵横比；对于显示器，也可以通过调节像素来显示不同的纵横比。

视频或游戏与显示器的纵横比匹配的时候，显示效果最佳，图像不会变形。
这也是为什么很多视频在手机上竖屏看的时候，只会集中在中间显示，上下很多部分都是黑屏，
就是因为视频的纵横比在竖屏上的纵横比不匹配，只能缩小在中间那部分显示。

换成横屏观看，视频才能完全展开。

3. 容易混淆的概念

关于纵横比和刷新，有2个概念可能我们平时容易混淆。

3.1. 4:3 和 16:9

这两种纵横比常常被误会成差不多，甚至是一样的，但是细算起来，它们的差距还挺大。

对于4：3 的纵横比意味着图像中每 4 个宽度单位就有 3 个高度单位，
最终显示出来，屏幕宽度比长度增加了 33%。

而16：9 的纵横比意味着图像中每 16 个宽度单位就有 9 个高度单位，
最终显示出来，屏幕宽度比长度增加了 78%。

3.2. 1080i 和 1080p

i 代表隔行扫描，通过照亮屏幕上的奇数像素和偶数像素，然后将它们的结果拼接在一起以获得最终图像，容易闪烁。
p 代表逐行扫描，对图像以逐行平滑的方式拼接，有效防止屏幕闪烁。

1080p比1080i的显示效果更加的清晰和细腻，因为1080p是后来改进的技术，现在的显示器用 i 的方式已经不多了。

前言

Hi 你好，我是东东拿铁，一个正在探索个人IP&副业的后端程序员。

今天我想和大家聊一段我自己毕业初期的一段经历，当领导给你安排了无从下手的任务，难以解决的技术问题时，该怎么办？

本文会从我的一段经历出发，分析在初入职场、刚刚成为一个程序的时候，遇到自己无解决的问题，和自己的一些解决问题的思考。

如果你工作不满三年，一定要往下看，相信一定会对你有帮助。但如果你已经工作3年以上，那么你应该不会遇到下面的问题啦，但也欢迎你往下看，也许会有不同的收获。

先讲故事

每个人都有自己的职场新人期，这个阶段你会敏感、迷茫。

记得在毕业的2个月后，我的组长给我布置了一个任务，实现服务的热部署。

热部署是什么？

热部署是一种技术，它允许在应用程序运行时不中断地更新或替换软件组件，如代码或配置。这种技术主要应用于Web应用程序和分布式系统中，旨在减少停机时间，提高开发效率，并增强应用程序的可用性。

那时候我们的服务器是单实例，每次升级，一定要先停掉服务，替换war包，然后重启tomcat。想升级，必须要在半夜客户下班的时候升级。

作为一个职场小白，技术小白，第一次接到这种任务的时候，我整个人是一脸懵逼的。

那时候报错的堆栈信息我都看不懂，还得请教组里的同事，CRUD还没整明白呢。就要去解决这个架构问题，可想而知我那时候有多崩溃。

其实选择让我一个毕业2个月的应届生来做，能发现两个基本的背景

• 公司没有标准化的解决方案，没有人知道你的解决方案是否对错。


• 包括我的组长、组内老同事在内，也没有人了解如何在生产环境实现热部署，没人可以提供帮助。

因此在这件事的起步阶段，非常的困难。最重要的是，我还不会调研行业的标准方案是什么，刚毕业的我只能埋头苦干，不断试错。

持续的没有进展，也让我内心非常焦虑。多次周会上被问及这件事情，也完全不知道如何汇报进展，因为我自己也不知道，到底什么时候能解决。

记得那时候上厕所、接水的时候，我都是低头不语，装作看不见，生怕他问我一句：“那件事情的进度怎么样了？”

现在想起自己那时候的无助和不安，我都会微微一笑。

很庆幸是在计算机行业，即使是用百度，也能够搜到大把的信息，那段时间也了解到了像Nginx、Redis这样的中间件，最终也是用Nginx，实现了最基本的目标，可以在保证客户使用的情况下，正常的升级我们的系统了。

是的，毕业后的第一家公司的负载均衡和不停机服务发布，是由一个小小毕业生来做的，前期内心有多煎熬，上线的那一刻就有多自豪。

故事讲完了，我相信很多职场人，都会面临这样的场景吧，或许是一个功能不知道怎么去实现，又或者一个方案不知道如何去设计，不敢面对，不敢说出来。

为什么会这样

在职场中，我们大概可以用四个阶段概括

上面我自己的一小段经历，遇到了新人期中最容易面临的问题，技能上的迷茫，和职场上的迷茫。

技能上的迷茫

我们可能发现自己有好多东西不会，什么都要学，却不知道自己该如何入手。

在大厂里，周围人看起来都是大牛，可以看着他们侃侃而谈，虽然自己只能茫然四顾，但起码有着标杆和榜样。

而在普通传统行业，身边连个会的人都没有，自己的摸索更像是盲人摸象。

职场上的迷茫

不知道事情该办成什么样，领导会不会不满意，对我的考核会不会有影响。

又或者主动说了有困难，领导会不会觉得我能力不足？

面对多重困难，我该如何汇报自己的进度？没有进度怎么办。

思考、建立正确的认知

界定问题，比问题本身要重要

技术日新月异，新技术是学不完的，解决问题的方式更是多种多样的。所有成熟的方案，都不是一蹴而就的，而是通过发现问题、解决问题一步步优化完善来的。

所以我们有一个清晰的认知，我们很难得到最优的解决方案，而是把注意力放在问题本身，看看我们到底要解决什么问题。

例如我一开始不知道热部署的含义，但我知道的是，公司想解决服务的不停机升级问题。那么我最终引入了Nginx，通过反向代理，部署多个服务就好了。提供的解决方案，完成了预期，我认为对于一个新人来讲就是合格的。

PS：事实上我在使用了Nginx完成了负载均衡后，我的组长曾和我说，你这个方案感觉不太行，不是领导想要的效果。但点到为止了，也没有什么指导，或者改进措施，最终也用这个方案在生产去部署。

注重当下

职场规则是明确的，可以在员工手册、职级要求中看到。但职场中的潜规则是不明确的，你无法摸清领导最真实的想法。

为什么这么说呢？

• 领导可能就是想历练你，给你有挑战的事情，想看看你做到什么程度，你的能力边界在哪里


• 领导对你的预期就是能够解决，也不需要他的指导

不同的想法，对你的要求截然不同。

历练你的时候，即使事情没有结果，领导也不会多说什么，或许这就是一个当下受限于公司运维、资源而难以做到的事情。

但领导相信你能够解决问题的时候，你必须要尽量完成，不然确实会影响到对你的一些看法。

对于职场新手期，你短时间内是无法建立一个良好的向上沟通渠道的（如何建立向上沟通渠道，我们后面再说）。所以对你而言，与其揣摩想法， 不如界定好问题，然后注重当下，解决好遇到的每一个困难。

两个方法

目标拆分

有一个关于程序员的经典段子：这个工作已经做完了80%，剩下的**20%**还要用和前面的一样时间。

遇到无从下手，不知如何去解决的问题，是怎么给出一个可执行的分解。

重点来了，拆分的，一定要可执行。每个人对于可执行的区分，是有很大不同的。不同的地方在于可执行的定义，你是否能清楚地知道这个问题该如何解决。

比如文章开头的故事，如果时间回到那一刻，我会这么列出计划

学会借力

手里有把锤子,看见什么都是钉子。

我们更倾向于用我们手里的某种工具，去解决所有问题。

在遇到问题时，我们的大脑会根据以往经验做出预判，从而形成思维定势，使得我们倾向于使用熟悉的工具或方法来解决问题。然而，并不是所有问题都是钉子，一旦碰到超出我们经验边界的事情，我们可能会束手无策。

还是分享一段经历：

在字节的时候，我遇到过一个问题场景，就是如何保证集群服务器的本地缓存，保持一致。

直白来讲，我要开一个500人的会议，我准备了500份资料，那么在资料可能会修改的情况下，如何保证大家手里资料，都是最新的？

加载、更新，我能想到的就是用消息队列广播，系统收到消息的时候，每一台服务器都走一遍加载逻辑。

但有一个问题我解决不了，几百台服务器同时请求，如何解决突发的压力问题呢？如果500个人同时去找会议组织人打印，排队不说了，打印机得忙冒烟。

我给身边的一个技术大拿说了我的问题，他说，你可以用公司的一个中间件啊，数据只需要一次加载，然后服务器去下载就好了。是哈，用一个超级打印机打印出500份，分发下去就好了，不用每个人亲自来取呀。

就是几句点拨，同步给我了这一个信息，我了解了一下这个中间件，完美解决了我的问题。

因此，学会借力。找到公司大佬，找到网上的大佬，买杯咖啡、发个红包，直接了当的说出你的问题，咨询解决方案，从更高层次，降维打击你的问题。

当然，一定要在自己思考完、没有结果的情况下，再去请教，能够自己研究明白的，比如使用相关的，不要去麻烦别人。

说在最后

文章到这里就要结束啦，很感谢你能看到最后。

职场初期遇到无从下手的任务时，我们应该建立正确的认知，界定问题，并注重当下。

也分享给你了两个行之有效的方法，目标拆分和学会借力，当然，这一切都离不开你的行动和坚持，这不是方法，而是一个技术人最基本的素质，所以就不多说啦。

不知道你在职场中初期遇到无从下手的问题时，你是怎么处理的呢，欢迎你在评论区和我分享，也希望你点赞、评论、收藏，让我知道对你有所收获，这对我来说很重要。也欢迎你加我的wx：Ldhrlhy10，让我做你的垫脚石，帮你解决你遇到的问题呀，欢迎一起交流～

开篇

这不是一篇技术的文章。

第一阶段 裸辞后的两个半月

介绍下自己的情况，坐标上海，双非院校前端打工人，目前是有三年的工作经验，在23年的年底裸辞了，有一个女朋友，本来异地，她在22年10月来到了上海，选择相信我。
在刚刚裸辞的时候，我信心满满的在各个平台投递着简历，给自己做了一个规划：“先投外包的，投小公司来练手，最后一鸣惊人进入大厂，走向人生巅峰！”当时已经可以在各大论坛上看到，前端已死啊之类的标题，但从实际感受来说，好像并没有那么夸张，程序员还是比较高薪的职业。已读不回是挺常见的，但实际面试还是比较多的，并不像大家在网上说的感觉前端开发都要找不到工作了。在这三个月里，我BOSS上沟通了400个人左右，面试的有11家，其中有5个外包。这样的情况在现在的我看来真有点属于暴殄天物了，只沟通了400多个公司就约了11家面试，后来的我才知道这就是我找工作最顺利的阶段，也是我最浪费机会的阶段。由于没有一个正确的认知，以及一个具体的规划和行动，我面试没有尽力去准备，再加上父亲住院，经常往医院跑，一来一回基本一天就没了，11家面试只有一家进入了二轮复面，甚至没有一家进入到谈薪阶段。可当时的我始终是抱着一个比较乐观的态度，还会天天和我的女朋友吐槽一些公司，从来没有认真的找过自己的问题，天真的认为只要我好好准备一下，就一定可以拿下offer，还和她保证我过年前一定能找到工作！她也十分信任我，可后续的发展就愈发的不可控了。

第二阶段 字节面试一轮结束 失业的第四个月

因为之前的面试都没有一个很好的反馈，渐渐的我有点开始着急，也已经渐渐处于摆烂的状态投递简历，就是海投，不看公司介绍，只要是个公司我就打个招呼，有回复我就发个简历，以至于在投递简历的过程中，都不知道何时自己投了字节的一个岗位，然后还约到了面试，我一时间来了信心，约了两周后的字节一轮面试。这两周我没有打开招聘软件，处于一个孤注一掷的状态，实际上就是抱着侥幸心理想碰碰运气，这期间我看了一周的技术课程，浅浅的背了一些八股文，但并没有对之前所有面试的经历进行一个总结，找找自己的问题。之后时间很快就到了面试的当天，这天我突然感觉自己差的东西有很多，但还是硬着头皮去面了，结果可想而知，一轮没有通过。我当时非常沮丧，给女朋友打了一个电话说自己没有通过，她还是非常鼓励我，不给我压力。她工作也很忙，基本就是早上8点到晚上11点的上班强度，但还是一直很有耐心的和我说没事，没有工作也没事，等你想找工作的时候再找也来得及。实际这个时候我就应该醒悟了，自己并不是什么技术大牛，只是一个顶着一个前端工程师光环的cv工程师，一个凭借一些错误的自我认知，就觉得自己未来一定会更好的愚蠢、不可理喻的愚蠢的人，况且我已经不算年轻，是一个快要奔三的大龄青年了，还抱着这种天真，不成熟的想法，但这也是后话了，当时的我还是挫败了几天后继续着躺平的生活，还大言不惭的和我的女朋友说着我三四月份一定可以找到一份合适的工作，做出承诺，但却没有匹配承诺的态度和行为，这时候的女朋友已经对我有了一些意见，但她没有明确的和我说，怕给我压力，只是感觉她的工作状态逐渐不对了，疲惫和内耗占据了她大部分空闲时间，她第一次跟我说了，要不试试别的岗位吧，前端的工作这么不好找，不如换个方向，但这句话我没有放在心上。因为报了健身班，我的健身教练已经开始为我着急了，他说要不来干健身教练吧，我带你入门，我也只当是玩笑话了。

第三阶段 裸辞后的六月半

不出意外的，在金三银四过去之后，我仍然没有找到工作，面试机会也几乎没有了，一个月可能有一两个外包的面试，但自己因为不想考虑外包，在某一家外包面完挫败感的驱使下，屏蔽了BOSS上大多数的外包公司，自此我的BOSS上再也没有一点水花。后来在我认为是缘分的加持下，我的父母和她的父母在上海碰到了，然后顺利的吃了饭，见了面，我爸妈给了我的女朋友见面礼一万零一的红包，寓意万里挑一。我的父母是很普通的农民，一辈子都跟种地打交道，不善言辞，一整个饭局，基本就是我的哥哥和她的爸妈和她在聊天，我在饭桌上也一言不发，可能是怕她的父母问及我工作的问题，也可能是因为哥哥是个很优秀的人，他对于我的期望很高，每次他在场的时候我都会避免开口，以免被抓到会被教育的点。总之饭局也很快就结束了，她的父母对我也没有什么过分的要求，也没有着急让我找工作，说着安慰我的话，现在市场环境不好，找不到工作很正常，利用这段时间学习，以后还有很多机会，你还年轻呢，不要害怕。现在的我几乎是流着眼泪打出当时阿姨跟我说的话，她们一家都是很讲道理，也会为别人考虑的人，但我还是辜负了他们的信任，让他们失望了。这期间面试机会少之又少，我这时候已经渐渐由摆烂，变得慌张的不知所措了，现在发生的情况我之前完全没有考虑到，随着存款一点一点的被社保、房租、吃喝消耗，女朋友的状态也愈发变得消极，我内心陷入了很痛苦的境地。但这并没有让我去总结面试的问题，只是一味的投着简历，看着八股文，等待面试。在六月初，女朋友第二次和我商量，如果前端的工作不好找就换个别的干干吧，这时我已经有点想逃避社会了，想要避免外出，除了每天去健身房，剩下时间几乎都呆在小小的出租屋房间。但我还是答应了她，在6月15号之后我就找其他岗位的工作。接下来几天，有了两个面试，还有原来公司的人找我想让我帮忙做个项目，因为甲方报价还没有，所以这个事情就相当于没有后续，但实际我还是心存幻想，想走更平坦的路。接着时间很快就到了6月13号，她问我计划还实行吗，我说当然实行啊，不过想等一下这个项目的事情，她第一次发泄了自己的情绪，说自己要等到什么时候啊！6月14号，她说她好累，不想等了，想分手。晚上沟通中我没有任何的话可以讲出口，一直沉默，气氛一直很凝重，6月15日，我整理了一些我的问题，想和她聊聊，她上班回来之后很平静的和我说了分手，说了本身对我的期望也没有那么高，说只需要有一个工作，或者我努力的心就可以。我说了我的很多问题，保证我自己会改，但为时已晚，因为她已经给我了足够的时间，但我没有珍惜。她把礼金退给了我，我搬了出去，故事在这就画了句号。

现在

痛苦总是后知后觉，并且悄悄击碎你的防线。父亲身体愈发不好，在知道我分手之后，去医院检查身体的时候晕倒了，进入急诊的那一刻，看着急诊中的病人，看着意识模糊的父亲，我的世界一下就崩塌了。好在父亲没有大碍，但精神状态不是很好。我没有一个最坏的预期，并且时刻都在回避问题，不敢直面自己，承认自己的弱小以及愚蠢，还渐渐看不到身边人做出的牺牲和努力。我浑浑噩噩的过着这几天，这几天是我第一次正面的和哥哥进行了我认为的平等的沟通，我第一次很认真的听他讲话，不再排斥，也第一次觉得他说的其实都对，他的话第一次在我眼里不是说教，而是关心和爱护。我发现了自己的很多问题，他还教会了我一个人生态度：凡事抱最大的希望，尽最大的努力，做最坏的打算。我的世界开始慢慢重建起来，我发现了自己之前的工作内容很简单，基于vue2、antdv、Echarts的后台管理系统，图表，小程序。我发现我没有规划，总是走一步看一步，并且还带着莫名的自信。我发现我辜负了很多人的期待，让自己也很失望。我发现了很多很多，我不知道这次裸辞还会持续的给我带来什么影响，但生活总是要继续，一手好牌最终打的稀烂，但已经没有时间让我继续消沉下去，2024年有可能是我这一生都不会忘记的。

结语

这七个月，让我失去了很多很多，失去了工作，失去了信任，失去了挚爱，失去了···这篇文章主要目的不是为了卖惨，或者贩卖焦虑，只是一个普通的不能再普通的人的一段时间的总结，是对可能已经逝去爱情的怀念。未来还会有很多很多意外的事情发生，我需要做的是积极的去面对，能做的是适应环境，找自己的不足，及时补救，不要一切都来不及的时候才后悔，才反思。我想要和林克一样，忍受孤独，努力变强，去找到她。

前言

一些持续关注过我的朋友大部分都来源于我的一些资源分享和一篇万字泣血斩副业的劝诫文，但今年年后开始我有将近4个月没有再更新过。

有加过我好友的朋友私聊我问过，有些回复了有些没回复。

想通过这篇文章顺便说明一下个人的情况，主要是给大家的一些中肯的建议。

我的身体

今年年前公司福利发放的每人一次免费体检，我查出了高密度脂蛋白偏低，因为其他项大体正常，当时也没有太在意。

但过完年后的第一个月，我有一次下午上班忽然眩晕，然后犯恶心，浑身发软冒冷汗，持续了好一阵才消停。

当时我第一感觉就是颈椎出问题了？毕竟这是程序员常见的职业病。

然后在妻子陪伴下去医院的神经内科检查了，结果一切正常。

然后又去拍了片子看颈椎什么问题，显示第三节和第四节有轻微的增生，医生说其实没什么，不少从事电脑工作的人都有，不算是颈椎有大问题。

我人傻了，那我这症状是什么意思。

医生又建议我去查下血，查完后诊断出是血脂偏高，医生说要赶紧开始调理身体了，否则会引发更多如冠心病、动脉粥样硬化、心脑血管疾病等等。

我听的心惊胆战，没想到我才34岁就会得上老年病。

接下来我开始调理自己的作息和生活，放弃一些不该强求的，也包括工作之余更新博客，分享代码样例等等。

4个月的时间，我在没有刻意减肥的情况下体重从原先152减到了140，整个人也清爽了许多，精力恢复了不少。

所以最近又开始主动更新了，本来是总结了程序员的10个工作中的不良习惯。

但想到自己的情况，决定缩减成5个，另外5个改为程序员生活中的不良习惯，希望能对大家有警示的作用。

不良习惯

1、工作

1）、拖延症

不到最后一天交差，我没有压力，绝不提前完成任务，从上学时完成作业就是这样，现在上班了，还是这样，我就是我，改不了了。

2）、忽视代码可读性

别跟我谈代码注释，多写一个字我认你做die，别跟我谈命名规范，就用汉语拼音，怎样？其他人读不懂，关我什么事？

3）、忽视测试

我写一个单元测试就给我以后涨100退休金，那我就写，否则免谈。接口有问题你前端跟我说就行了发什么脾气，前后端联调不就这样吗？！

4）、孤立自己

团队合作不存在的，我就是不合群的那个，那年我双手插兜，全公司没有一个对手。

5）、盲目追求技术新潮

晚上下班了，吃完饭打开了某某网，看着课程列表中十几个没学完的课程陷入了沉默，但是首页又出现了一门新课，看起来好流行好厉害耶，嗯，先买下来，徐徐图之。

2、生活

1）、缺乏锻炼和运动

工作了一天，还加班，好累，但还是得锻炼，先吃完饭吧，嗯，看看综艺节目吧，嗯，再看看动漫吧，嗯，还得学习一下新技术吧，嗯，是手是得洗澡了，嗯，还要洗衣服，咦，好像忘记了什么重要的事情？算了，躺床上看看《我家娘子不对劲》慢慢入睡。

2）、加班依赖症

看看头条，翻翻掘金，瞅瞅星球，点点订阅号，好了，开始工作吧，好累，喝口水，上个厕所，去外面走走，回来了继续，好像十一点半了，快中午了，待会儿吃什么呢？

午睡醒了，继续干吧，看看头条，翻翻掘金，瞅瞅星球，点点订阅号，好了，开始工作吧，好累，喝口水，上个厕所，去外面走走，回来了继续，好像5点半了，快下班了，任务没完成。

算了，加加班，争取8点之前搞定。

呼~搞定了，走人，咦，10点了。

3）、忽视饮食健康

早上外卖，中午外卖，晚上外卖，哇好丰富耶，美团在手，简直就是舌尖上的中国，晚上再来个韩式炸鸡？嗯，来个韩式甜辣酱+奶香芝士酱，今晚战个痛快！

4）、缺乏社交活动

好烦啊，又要参加公司聚会，聚什么餐，还不是高级外卖，说不定帮厨今天被大厨叼了心情不好吐了不少唾沫在里面，还用上完厕所摸了那里没洗的手索性搅了一遍，最后在角落里默默看着你们吃。

吃完饭还要去KTV？继续喝，喝不死你们，另外你们唱得很好听吗？还不是看谁嗷的厉害！

谁都别跟我说话，尤其是领导，离我越远越好，唉，好想回去，这个点B站该更新了吧，真想早点看up主们嘲讽EDG。

5）、没有女朋友

张三：我不是不想谈恋爱，是没人看得上我啊，我也不好意思硬追，我也要点脸啊，现在的女孩都肿么了？一点暗示都不给了？成天猜猜猜，我猜你MLGB的。

李四：家里又打电话了，问在外面有女朋友了没，我好烦啊，我怎么有啊，我SpringCloudAlibaba都没学会，我怎么有？现在刚毕业的都会k8s了，我不学习了？不学习怎么跳槽，不跳槽工资怎么翻倍，不翻倍怎么买房，不买房怎么找媳妇？

王五：亲朋好友介绍好多个了，都能凑两桌麻将了，我还是没谈好，眼看着要30了，我能咋整啊，我瞅她啊。破罐破摔吧，大不了一个人过呗，多攒点钱以后养老，年轻玩个痛快，老了早点死也不亏，又不用买房买车结婚受气还得养娃，多好啊，以后两脚一蹬我还管谁是谁？

总结

5个工作坏习惯，5个生活坏习惯，送给我亲爱的程序员们，如果你占了一半，真得注意点了，别给自己找借口，你不会对不起别人，只是对不起自己。

喜欢的小伙伴们，麻烦点个赞，点个关注，也可以收藏下，以后没事儿翻出来看看哈。

以前在团队里 Review 过无数代码，也算是阅码无数的人了，解决过的线上异常也数不胜数，故对如何写出健状性的代码有一些微小的见解。刚好最近闲来得空（其实是拖延症晚期）把之前躺在备忘录里的一些小记整理了一下，希望能对你有一些启发。

Uri 对象的使用

在 Dart 语言中 Uri 类用于表示 URIs（网络地址、文件地址或者路由），它内部能自动处理地址的模式与的百分号编解码。在实际开发过程我们经常直接使用字符串进行拼接 URIs，然而这种方式会给地址的高级处理带来不便甚至隐式异常。

/// 假设当前代码为一个内部系统，[outsideInput] 变量是外部系统传入内部的字符串变量

/// 你无法限定 [outsideInput] 的内容，如果变量包含非法字符(如中文)，整个地址非法

final someAddress = 'https://www.special.com/?a=${outsideInput}';

/// 为了保持 URI 的完整性你可能会这样做

final someAddress = 'https://www.special.com/?a=${Uri.decodeFull(outsideInput)}';

/// 如有多个外部输入变量你又需要这样做

final someAddress = 'https://www.special.com/?a=${Uri.encodeFull(outsideInput)}&b=${Uri.encodeFull(outsideInput1)}&c=${Uri.encodeFull(outsideInput2)}';

直接使用字符串来拼接 URI 地址会带来非常多的限制，你需要关注地址中拼接的每个部分的合法性，并且在处理复杂逻辑时需要更冗长为的处理。

/// 如果我们需要在另一个系统中对 [someAddress] 地址的参数按条件进行添加

if (conditionA) {

  someAddress = 'https://www.special.com/?a=${Uri.encodeFull(outsideInput)}';

} else if (conditionB) {

  someAddress = 'https://www.special.com/?a=${Uri.encodeFull(outsideInput)}&b=${otherVariable}';

} else {

	someAddress = 'https://www.special.com';

}

如果使用 Uri 可以简化绝大多数对 URIs 的处理，同时限定类型对外部有更明确的确定性，因此针对 URIs 需要做如下约定：

在任何系统中都不应直接拼接 URIs 字符串，应当构造 URI 对象作为参数或返回值。

/// 生成 Uri 对象

final someAddress = Uri(path: 'some/sys/path/loc', queryParameters: {

  'a': '${outsideInput}', // 非法参数将自动百分号编码

  'b': '${outsideInput1}', // 不用对每个参数单独进行编码

  if (conditionA) 'c': '${outsideInput2}', // 条件参数更为简洁

});

类型转换

Dart 中可以使用 is 进行类型判断，as 进行类型转换。 同时，使用 is 进行类型判断成功后会进行隐性的类型转换。示例如下：

class Animal {

  void eat(String food) {

    print('eat $food');

  }

}



class Bird extends Animal {

  void fly() {

    print('flying');

  }

}



void main() {

  Object animal = Bird();



  if (animal is Bird) {

    animal.fly(); // 隐式类型转换

  }



  (animal as Animal).eat('meat'); // 强制类型转换一旦失败就会抛异常

}

由于隐式的类型转换存在，is 可以充当 as 的功能，同时 as 进行类型失败会抛出异常。

所以日常开发中建议使用 is 而不是 as 来进行类型转换。 is 运算符允许更安全地进行类型检查，如果转换失败，也不会抛出异常。

void main() {

  dynamic animal = Bird();



  if (animal is Bird) {

    animal.fly();

  } else {

    print('转换失败');

  }

}

List 使用

collection package 的使用

List 作为 Dart 中的基础对象使用广范，由于其本身的特殊性，如使用不当极易导致异常，从而影响业务逻辑。典型示例如下：

 List<int> list = [];

// 当 List 为空时访问其 first 会抛异常

list.first

// 同理访问 last 也会抛异常

list.last

// 查找对象时没有提供 orElse 也会抛异常

list.firstWhere((t) => t > 0);



// List 对象其它会抛异常的访问还有

list.single

list.lastWhere((t) => t > 0)

list.singleWhere((t) => t > 0)

所以如果没有前置判断条件，所有对 List 的访问均需替换为 collection 里对应的方法。

import 'package:collection/collection.dart';



List<int> list = [];

list.firstOrNull;

list.lastOrNull;

list.firstWhereOrNull((t) => t > 0);

list.singleOrNull;

list.lastWhereOrNull((t) => t > 0);

list.singleWhereOrNull((t) => t > 0);

取元素越界

在 Dart 开发时，碰到数组越界或者访问数组中不存在的元素情况时，会导致运行时错误，如:

List<int> numbers = [0, 1, 2];

print(numbers[3]); // RangeError (index): Index out of range: index should be less than 3: 3

你可以使用使用 try-catch 来捕获异常，但由于数组取值这样的基础操作往往遍布在项目的各个角落，try-catch在这样的情况下使用起来会比较繁琐，而且并不是所有的取值都会导致异常，所以往往越界的问题只有真正出现了才发现。

好在，我们可以封装一个 extension 来简化数组越界的问题：

extension SafeGetList<T> on List<T> {

  T? tryGet(int index) =>

    index < 0 || index >= this.length ? null : this[index];

}

使用时:

final list = <int>[];



final single = list.tryGet(0) ?? 0; 

由于 tryGet 返回值类型为可空(T?) ，外部接收时需要进行空判断或者赋默认值，这相当于强迫开发者去思考值不存在的情况，如此减少了异常发生的可能，同时在业务上也更加严谨。

当然还有另一种方案，可以继承一个 ListMixin 的自定义类：SafeList，其代码如下：

class SafeList<T> extends ListMixin<T> {



  final List<T?> _rawList;



  final T defaultValue;



  final T absentValue;



  SafeList({

    required this.defaultValue,

    required this.absentValue,

    List<T>? initList,

  }) : _rawList = List.from(initList ?? []);



  @override

  T operator [](int index) => index < _rawList.length ? _rawList[index] ?? defaultValue : absentValue;



  @override

  void operator []=(int index, T value) {

    if (_rawList.length == index) {

      _rawList.add(value);

    } else {

      _rawList[index] = value;

    }

  }



  @override

  int get length => _rawList.length;



  @override

  T get first => _rawList.isNotEmpty ? _rawList.first ?? defaultValue : absentValue;



  @override

  T get last => _rawList.isNotEmpty ? _rawList.last ?? defaultValue : absentValue;



  @override

  set length(int newValue) {

    _rawList.length = newValue;

  }

}

使用：

final list = SafeList(defaultValue: 0, absentValue: 100, initList: [1,2,3]);



print(list[0]); // 正常输出: 1

print(list[3]); // 越界，输出缺省值: 100

list.length = 101;

print(list[100]); // 改变数组长度了，输出默认值: 0

以上两种方案均可以解决越界的问题，第一个方案更简洁，第二个方案略复杂且侵略性也更强但好处是可以统一默认值、缺省值，具体使用哪种取决于你的场景。

ChangeNotifier 使用

ChangeNotifier 的属性访问或方法调用

ChangeNotifier 及其子类在 dispose 之后将不可使用，dispose 后访问其属性（hasListener）或方法（notifyListeners）时均不合法，在 Debug 模式下会触发断言异常；

// ChangeNotifier 源码

bool get hasListeners {

  // 访问属性时会进行断言检查

  assert(ChangeNotifier.debugAssertNotDisposed(this));

  return _count > 0;

}



void dispose() {

  assert(ChangeNotifier.debugAssertNotDisposed(this));

  assert(() {

    // dispose 后会设置此标志位

    _debugDisposed = true;

    return true;

  }());

  _listeners = _emptyListeners;

  _count = 0;

}



static bool debugAssertNotDisposed(ChangeNotifier notifier) {

  assert(() {

    if (notifier._debugDisposed) { // 断言检查是否 dispose

      throw FlutterError(

        'A ${notifier.runtimeType} was used after being disposed.\n'

        'Once you have called dispose() on a ${notifier.runtimeType}, it '

        'can no longer be used.',

      );

    }

    return true;

  }());

  return true;

}

在 dispose 后访问属性或调用方法通常出现在异步调用的场景下，由其是在网络请求之后刷新界面。典型场景如下：

class PageNotifier extends ChangeNotifier { 

  dynamic pageData;

  

	Future<voud> beginRefresh() async {

    final response = await API.getPageContent();

    if (!response.success) return;

    pageData = response.data;

    // 接口返回之后此实例可能被 dispose，从而导致异常

    notifyListeners();

  }

}

为使代码逻辑更加严谨，增强整个代码的健状性：

ChangeNotifier 在有异步的场景情况下，所有对 ChangeNotifier 属性及方法的访问都需要进行是否 dispose 的判断。

你可能会想到加一个 hasListeners 判断:

class PageNotifier extends ChangeNotifier { 

  dynamic pageData;

  

	Future<voud> beginRefresh() async {

    final response = await API.getPageContent();

    if (!response.success) return;

    pageData = response.data;

    // Debug 模式下 hasListeners 依然可能会抛异常

    if (hasListeners) notifyListeners(); 

  }

}

如上所述 hasListeners 内部仍然会进行是否 dispose 的断言判断，所以 hasListeners 仍然不安全。

因此正确的做法是：

// 统一定义如下 mixin

mixin Disposed on ChangeNotifier {

  bool _disposed = false;

  

  bool get hasListeners {

    if (_disposed) return false;

    return super.hasListeners;

  }



  @override

  void notifyListeners() {

    if (_disposed) return;

    super.notifyListeners();

  }



  @override

  void dispose() {

    _disposed = true;

    super.dispose();

  }

}



// 在必要的 ChangeNotifier 子类混入 Disposed

class PageNotifier extends ChangeNotifier with Disposed { 



	Future<voud> beginRefresh() async {

    final response = await API.getPageContent();

    if (!response.success) return;

    pageData = response.data;

    // 异步调用不会异常

    notifyListeners(); 

  }



}

ChangeNotifier 禁止实例复用

ChangeNotifier 在各种状态管理模式中一般都用于承载业务逻辑，初入 Flutter 的开发者会受原生开发的思维模式影响可能会将 ChangeNotifier 实例进行跨组件复用。典型的使用场景是购物车，购物车有加/减商品、数量管理、折扣管理、优惠计算等复杂逻辑，将 ChangeNotifier 单个实例复用甚至单例化能提高编码效率。

但单个 ChangeNotifier 实例在多个独立的组件或页面中使用会造成潜在的问题：复用的实例一旦在某个组件中被意外 dispose 之后就无法使用，从而影响其它组件展示逻辑并且这种影响是全局的。

@override

void initState() {

  super.initState();

  // 添加监听

  ShoppingCart.instance.addListener(_update);

}



@override

void dispose() {

  // 正确移除监听

  ShoppingCart.instance.removeListener(_update);

  // 如果哪个实习生不小心在组件中这样移除监听，将产生致命影响

  // ShoppingCart.instance.dispose();

  super.dispose();

}

因此在 Flutter 开发中应禁止 ChangeNotifier 实例对外跨组件直接复用，如需跨组件复用应借助provider、get_it 等框架将 ChangeNotifer 子类实例对象置于顶层;

void main() {

  runApp(

    MultiProvider(

      providers: [

        Provider<Something>.value(ShoppingCart.instance),

      ],

      child: const MyApp(),

    )

  );

}

如果你非得要 「单例化」 自定义 ChangeNotifier 子类实例，记得一定要重新 dispose 函数。

Controller 使用

在 Flutter 中大多数 Controller 都直接或间接继承自 ChangeNotifier。为使代码逻辑更加严谨，增强整个代码的健状性，建议：

所有 Controller 需要显式调用 dispose 方法，所有自定义 Controller 需要重写或者添加 dispose 方法。

// ScrollController 源码

class ScrollController extends ChangeNotifier {

//...

}



// 自定义 Controller 需要添加 dispose 方法

class MyScrollController {

	ScrollController scroll = ScrollController();



	// 添加 dispose 方法

  void dispose() {

    scroll.dispose();

  }

}

ChangeNotifierProvider 使用

ChangeNotifierProvider 有两个构造方法:

• ChangeNotifierProvider.value({value:})


• ChangeNotifierProvider({builder:})

使用 value 构造方法时需要注意：value 传入的是一个已构造好的 ChangeNotifier 子类实例，此实例不由 Provider 内构建，Provider 不负责此实例的 dispose 。

虽然这个差异在 Provider 文档中有重点说明，但仍然有不少开发人员在写代码的过程中混用，故在此再次强调

因此开发人员在使用 ChangeNotifierProvider.value 时为使代码逻辑更加严谨，增强整个代码的健状性，培养良好的开发习惯开发人员需践行以下规范：

使用 ChangeNotifierProvider.value 构造方法时传入的实例一定是一个已构建好的实例，你有义务自行处理此实例的 dispose。使用 ChangeNotifierProvider(builder:) 构造方法时你不应该传入一个已构建好的实例，这会导致生命周期混乱，从而导致异常。

你需要这样做

MyChangeNotifier variable;



void initState() {

	super.initState();

	variable = MyChangeNotifier(); // 提前构建实例

}



void build(BuildContext context) {

	return ChangeNotifierProvider.value(

		value: variable, // 已构建好的实例

		child: ...

  );

}



void dispose() {

  super.dispose();

  variable.dispose(); // 主动 dispose

}

你不能这样做

MyChangeNotifier variable;



void initState() {

	super.initState();

	variable = MyChangeNotifier(); 

}



void build(BuildContext context) {

  // create 对象的生命周期只存在于 Provider 树下，此处应不直接使用此实例

	return ChangeNotifierProvider(

		create: (_) => variable, 

		child: ...

  );

}

避免资源释放遗忘

在 Flutter 中有很多需要主动进行资源释放的类型，包含但不限于：Timer、StreamSubscription、ScrollController、TextEditingController等，另外很多第三方库存在需要进行资源释放的类型。

如此多的资源释放类型管理起来是非常麻烦的，一旦忘记某个类型的释放很会造成整个页面的内存泄漏。而资源的创建一般都位于 initState 内，资源释放都位于 dispose 内。

为了减小忘记资源释放的可能性，dispose 应为 State 内的第一个函数并尽可能的将 initsate 紧跟在 dispose 后

这样在代码 Review 时可以从视觉上一眼看出来资源释放是否被遗忘。

Bad

final _controller = TextEditingController();

late Timer _timer;



void initState() {

  super.initState();

  _timer = Timer(...);

}



Widget build(BuildContext context) {

  return SizedBox(

    child: // 假设此处为简单的登录界面，也将是一串很长的构建代码

  );

}



void didChangeDependencies() {

  super.didChangeDependencies();

  // 又是若干行

}



// dispose 函数在 State 末尾，与 initState 大概率会超过一屏的距离

// 致使 dispose 需要释放的资源与创建的资源脱节

// 无法直观看出是否漏写释放函数

void dispose() {

  _timer.cancell();

  super.dispose();

}

Good

final _controller = TextEditingController();

late Timer _timer;



// 属性后第一个函数应为 dispose

void dispose() {

  _controller.dispose();

  _timer.cancell();

  super.dispose();

}

// 中间不要插入其它函数，紧跟着写 initState

void initState() {

  super.initState();

  _timer = Timer(...);

}

上面推荐的写法也可以用在自定义的 ChangeNotifer 子类中，将 dispose 函数紧在构造函数后，有利于释放遗漏检查。

由于创建资源与释放资源在不同的函数内，因此存在一种情况：为了释放资源不得不在 State 内加一个变量以便于在 dipose 函数中引用并释放，即便此资源仅在局部使用。

典型场景如下：

late CancelToken _token;



Future<void> _refreshPage() async {

  // _token 只在页面刷新的函数中使用，却不得不加一个变量来引用它

  _token = CancelToken();



  Dio dio = Dio();

  Response response = await dio.get(url, cancelToken: _token);

  int code = response.statusCode;

  // ...

}



void dispose() {

  super.dispose();

  _token.cancel();

}

这样的场景在一个页面内可能有多处，相同的处理方式使用起来就略显麻烦了，也容易导致遗忘。因此推荐如下写法：

// 创建下面的 Mixin

mixin AutomaticDisposeMixin<T extends StatefulWidget> on State<T> {

  Set<VoidCallback> _disposeSet = Set<VoidCallback>();



  void autoDispose(VoidCallback callabck) {

    _disposeSet.add(callabck);

  }



  void dispose() {

    _disposeSet.forEach((f) => f());

    _disposeSet.removeAll();

    super.dispose();

  }

}



class _PageState extends State<Page> with AutomaticDisposeMixin {

  Future<void> _refreshPage() async {

    final token = CancelToken();

    // 添加到自动释放队列

    autoDispose(() => token.cancel());

    Dio dio = Dio();

    Response response = await dio.get(url, cancelToken: token);

    int code = response.statusCode;

    // ...

  }

}

当然也这种用法不限于局部变量，同样也可以在 initState 内进行资源声明的同时进行资源释放，这种写法相对来讲更加直观，更不易遗漏资源释放。

final _controller = TextEditingController();



void initState() {

  super.initState();

  _timer = Timer(...);

  autoDispose(() => _timer.cancel());

  autoDispose(() => _controller.dispose());

}

StatefulWidget 使用

State 中存在异步刷新

在开发过程中简单的页面或组件通常直接使用 StatefulWidget 进行构建，并在 State 中实现状态逻辑。因此 State 不可避免可能会存在异步刷新的场景。但异步结束时当前 Widget 可能已经从当前渲染树移除，直接刷新当前 Widget 可能导致异常。典型示例如下：

class SomPageState extends State<SomePageWidget> {

 

  PageData _data;

  

  Future<void> _refreshPage() async {

    // 异步可能是延时、接口、文件读取、平台状态获取等

    final response = await API.getPageDetaile();

    if (!response.success) return;

    // 直接界面刷新页面可能会导致异常，当前 Widget 可能已从渲染树移除

    setState((){

      _data = response.data;

    });

  }

}

为使代码逻辑更加严谨，增强整个代码的健壮性，培养良好的开发习惯，建议：

在 State 里异步刷新 UI 时需要进行 mounted 判断，确认当前 Widget 在渲染树中时才需要进行界面刷新否则应忽略。

Future<void> _refreshPage() async {

  // 异步可能是接口、文件读取、状态获取等

  final response = await API.getPageDetaile();

  if (!response.success) return;

  // 当前 Widget 存在于渲染树中才刷新

  if (!mounted) return; 

  setState((){

    _data = response.data;

  });

}

上面的 mounted 判断可能会存在于所有 State 中又或者一个 State 里有多个异步 setState 调用，每个调用都去判断过于繁锁，因此更推荐如下写法：

// 统一定义如下 mixin

mixin Stateable<T extends StatefulWidget> on State<T> {

  @override

  void setState(VoidCallback fn) {

    if (!mounted) return;

    super.setState(fn);

  }

}



// 在存在异步刷新的 State 中 with 如上 mixin

class SomPageState extends State<SomePageWidget> with Stateable { 

  //...

}

本文介绍了美团到家/站外投放团队在多场景建模技术方向上的探索与实践。基于外部投放的业务背景，本文提出了一种自适应的场景知识迁移和场景聚合技术，解决了在投放中面临外部海量流量带来的场景数量丰富、场景间差异大的问题，取得了明显的效果提升。希望能给大家带来一些启发或帮助。

1 引言

美团到家Demand-Side Platform（下文简称DSP）平台，主要负责在美团外部媒体上进行商品或者物料的推荐和投放，并不断优化转化效果。随着业务的不断发展与扩大，DSP对接的外部渠道越来越丰富、展示形式越来越多样，物料展示场景的差异性愈发明显（如开屏、插屏、信息流、弹窗等）。

例如，用户在午餐时间更容易点击【某推荐渠道下】【某App】【开屏展示位】的快餐类商家的物料而不是【信息流展示位】的啤酒烧烤类商家物料。场景间差异的背后本质上是用户意图和需求的差异，因此模型需要对越来越多的场景进行定制化建设，以适配不同场景下用户的个性化需求。

业界经典的Mixture-of-Experts架构（MoE，如MMoE、PLE、STAR^[1]等）能一定程度上适配不同场景下用户的个性化需求。这种架构将多个Experts的输出结果通过一个门控网络进行权重分配和组合，以得到最终的预测结果。早期，我们基于MoE架构提出了使用物料推荐渠道进行场景划分的多场景建模方案。然而，随着业务的不断壮大，场景间的差异越来越大、场景数量也越来越丰富，这版模型难以适应业务发展，不能很好地解决DSP背景下存在的以下两个问题：

在面对此类建模任务时，业界现有的方法是在不同场景间进行知识迁移。例如，SAML^[2]模型采用辅助网络来学习场景的共享知识并迁移至各场景的独有网络；ADIN^[3]和SASS^[4]模型使用门控单元以一种细粒度的方式来选择和融合全局信息到单场景信息中。然而，在DSP背景中复杂多变的流量背景下，场景差异性导致了场景数量的急剧增长，现有方法无法在巨量稀疏场景下有效。

因此，在本文中我们提出了DSP背景下的自适应场景建模方案（AdaScene, Adaptive Scenario Model），同时从知识迁移和场景聚合两个角度进行建模。AdaScene通过控制知识迁移的程度来最大化不同场景共性信息的利用，并使用稀疏专家聚合的方式利用门控网络自动选择专家组成场景表征，缓解了负迁移现象；同时，我们利用损失函数梯度指导场景聚合，将巨大的推荐场景空间约束到有限范围内，缓解了数据稀疏问题，并实现了自适应场景建模方案。

2 自适应场景建模

在本节开始前，我们先介绍多场景模型的建模方式。多场景模型采用输入层 Embedding + 混合专家（Mixture-of-Experts, MoE）的建模范式，其中输入信息包括了用户侧、商家侧以及场景上下文特征。多场景模型的损失由各场景的损失聚合而成，其损失函数形式如下：

其中，$K$为场景数量，$α_i$为各场景的损失权重值。

我们提出的AdaScene自适应场景模型主要包含以下2个部分：场景知识迁移（Knowledge Transfer）模块以及场景聚合（Scene Aggregation）模块，其模型结构如下图2所示。场景知识迁移模块自适应地控制不同场景间的知识共享程度，并通过稀疏专家网络自动选择 K 个专家构成自适应场景表征。场景聚合模块通过离线预先自动化衡量所有场景间损失函数梯度的相似度，继而通过最大化场景相似度来指导场景的聚合。

该模型结构的整体损失函数如以下公式所示：

其中，$\alpha_{k}$为每个场景组的损失函数所对应的系数，$G_k$为第$k$个场景组下的的场景数量，$G$为某种场景组的划分方式。

下面，我们分别介绍自适应场景知识迁移和场景聚合的建模方案。

2.1 自适应场景知识迁移

在多场景建模中，场景定义方式决定了场景专家的学习样本，很大程度上影响着模型对场景的拟合能力，但无论采用哪种场景定义方式，不同场景间用户分布都存在重叠，用户行为模式也会有相似性。

为提升不同场景间共性的捕捉能力，我们从场景特征和场景专家两个维度探索场景知识迁移的方法，在以物料推荐渠道×App×展示形态作为多场景建模Base模型的基础上，构建了如下图3所示的自适应场景知识迁移模型（Adaptive Knowledge Transfer Network, AKTN）。该模型建立了场景共享参数与私有参数的知识迁移桥梁，能够自适应地控制知识迁移的程度、缓解负迁移现象。

• 场景特征适配：通过Squeeze-and-Excitation Network^[5]构建场景适应层（Scene Adaption Layer），其结构可表示为$F_{SE}= FC( ReLU( FC(x)))$，其中$FC$表示全连接层，$ReLU$为激活函数。由于不同场景对原始特征的关注程度存在较大差异，该层能够根据不同场景的信息生成原始特征的权重，并利用这些权重对输入特征进行相应的变换，实现场景特定的个性化输入表征，提高模型的场景信息捕捉能力。


• 场景知识迁移：使用GRU门控单元构建场景知识迁移层（Scene Transfer Layer）。GRU门控单元通过场景上下文信息对来自全局场景专家和当前场景专家的信息流动进行控制，筛选出符合当前场景的有用信息；并且，该结构能以层级方式进行堆叠，不断对场景输出进行修正。

场景特征适配在输入层根据场景信息对不同特征进行权重适配，筛选出当前场景下模型最关注的特征；场景知识迁移在隐层专家网络中进行知识迁移，控制共享专家中共性信息向场景独有信息的流动，使得场景共性信息得以传递。

这两种知识迁移方式互为补充、相辅相成，共同提升多场景模型的预估能力。我们对比了不同模块的实验效果，具体结果如下表1所示。可以看出，引入场景知识迁移和特征权重优化在头部、尾部渠道都能带来一定提升，其中尾部小流量场景上（见下表1子场景2、3）有更为明显的提升，可见场景知识迁移缓解了场景之间的负迁移现象。

相关研究和实践表明^[6][7][8]，稀疏专家网络对于提高计算效率和增强模型效果非常有用。因此，我们在AKTN模型的基础上，在专家层进一步优化多场景模型。具体的，我们将场景知识迁移层替换为自动化稀疏专家选择方法，通过门控网络从大规模专家中选取与当前场景最相关的$K$个构成自适应场景表征，其选择过程如下图4所示：

在实践中，我们通过使用可微门控网络对专家进行有效组合，以避免不相关任务之间的负迁移现象。同时大规模专家网络的引入扩大了多场景模型的选择空间，更好地支持了门控网络的选择。考虑到多场景下的海量流量和复杂场景特征，在业界调研的基础上对稀疏专家门控网络进行了探索。

具体而言，我们对以下稀疏门控方法进行了实践：

• 方法一：通过$KL$散度衡量子场景与各专家之间的相似度，以此选择与当前场景最匹配的$k$个专家。在实现方式上，使用场景*专家的二维矩阵计算相似性，并通过$KL$散度选择出最适合的$k$个专家。


• 方法二：每个子场景配备一个专家选择门控网络，$m$个场景则有$m$个门控网络。对于每个场景的门控网络，配备$k$个单专家选择器^[9]，每个单专家选择器负责从$n$个专家中选择一个作为当前场景的专家（$n$为Experts个数）。在实践中，为提高训练效率，我们对单专家选择器中权重较小的值进行截断，保证每个单专家选择器仅选择一个专家。

在离线实验中，我们以物料推荐渠道 * 展示形态作为场景定义，对上述稀疏门控方法进行了尝试，离线效果如下表2所示：

可以看出，基于软共享机制的专家聚合方法能够更好地通过所激活的相同专家网络对各场景之间的知识进行共享。相较于常见的以截断方式为主的门控网络，使用二进制编码的方式使得其在不损失其他专家网络信息的同时，能够更好地收敛到目标专家数量，同时其可微性使得其在以梯度为基础的优化算法中训练更加稳定。

同时，为了验证稀疏门控网络能否有效区分不同场景并捕捉到场景间差异性，我们使用$n$=16个专家中选择$K$=7个的例子，对验证集中不同场景下各专家的利用率、选择专家的平均权重进行了可视化分析（如图5-图7所示），实验结果表明该方法能够有效地选择出不同的专家对场景进行表达。

例如，图6中KP_1更多地选择第5个专家，而KP_2更倾向于选择第15个专家。并且，不同场景对各专家的使用率以及选择专家的平均权重也有着明显的差异性，表明该方法能够捕捉到细分场景下流量的差异性并进行差异化的表达。

实验证明，在通过大规模专家网络对每个场景进行建模的同时，基于软共享机制的专家聚合方法能够更好地通过所激活的相同专家网络对各场景之间的知识进行共享。 同时，为了进一步探索Experts个数对模型性能的影响，我们在方法二的基础上通过调整专家个数和topK比例设计了多组对比实验，实验结果如下表3所示：

从实验数据可以看出，大规模的Experts结构会带来正向的离线收益；并且随着选取专家个数比例的增加（表3横轴），模型整体的表现效果也有上升的趋势。

2.2 自适应场景聚合

理想情况下，一条请求（流量）可以看作一个独立的场景。但如引言所述，随着DSP业务持续发展，不同的物料展示渠道、形式、位置等持续增加，每个场景的数据十分稀疏，我们无法对每个细分场景进行有效训练。因此，我们需要对各个推荐场景进行聚类、合并。我们使用场景聚合的方法对此问题进行求解，通过衡量所有场景间的相似度，并最大化该相似度来指导场景的聚合，解决了数据稀疏导致难以收敛的问题。具体的，我们将该问题表示为：

其中$G$表示某种分组方式，$f_{s_i}$为场景$s_i$在分组$G_k$内与其他场景的总体相似度。在将$N$个场景聚合成$K$个场景组的过程中，我们需要找到使得场景间整体相似度最大的分组方式$G^{\ast}$。

因此，我们在2.1节场景知识迁移模型的基础上，增加了场景聚合部分，提出了基于Two-Stage策略进行训练的场景聚合模型：

• Stage 1：基于相似度衡量方法对各场景的相似度进行归纳，并以最大化分组场景的相似度为目标找到各场景的最优聚合方式（如Scene1与Scene 4可聚合为场景组合Scene Gr0up SGA）；


• Stage 2：基于Stage 1得到的场景聚合方式，以交叉熵损失为目标函数最小化各场景下的交叉熵损失。

其中，Stage 2与2.1节中所述一致，本节主要针对Stage 1进行阐述。我们认为，一个有效的场景聚合方法应该能自适应地应对流量变化的趋势，能够发现场景之间的内在联系并依据当前流量特点自动适配聚合方法。我们首先想到的是从规则出发，将人工先验知识作为场景聚合的依据，按照推荐渠道、展示形式以及两者叉乘的方式进行了相应迭代。然而这类场景聚合方式需要可靠的人工经验来支撑，且在应对海量流量时不能迅速捕捉到其中的变化。

因此，我们对场景之间关系的建模方法进行了相关的探索。首先，我们通过离线训练时场景之间的表征迁移和组合训练来评估场景之间的影响，但这种方式存在组合空间巨大、训练耗时较长的问题，效率较低。

在多任务的相关研究中^{[10][11][12][13]}，使用梯度信息对任务之间的关系进行建模是一种有效的方法。类似的在多场景模型中，能够根据各场景损失函数的梯度信息对场景间的相似度进行建模，因此我们采用多专家网络并基于梯度信息自动化地对场景之间的相似度进行求解，模型示意如下图8所示：

基于上述思路，我们对场景之间的关系建模方法进行了以下尝试：

1. Gradient Regulation