阅读时长约9.6分钟；共计2411个字

作为这个系列的正篇开端，我们聊一个很应景的话题——要不要做程序员。

说到这个话题，就要把时间往前推到高考后填报志愿的时刻，那个时刻可以说是大部分人首次面对职业规划问题。

在很久之前，我写过一篇关于填报志愿的文章，不妨先来回顾一下。

在那篇文章中，我指出填报志愿的优先原则是城市首选，院校次之，专业末位。

如此选择是有理由的，城市意味着圈子，意味着机会，意味着眼界。院校意味着平均水准，意味着知名度，意味着基本盘。专业意味着兴趣，意味着专长，意味着就业。

虽然我把专业放在末尾，但这并不意味着个人的兴趣不重要。而是当我们有了圈子，有了机会，有了平均水准之后，可以通过辅修或者转专业来进修自己喜欢的知识。

举个例子，比如一个人的高考成绩可以选择一所211或985院校，但专业只能服从调剂。也可以选一所普通院校，专业随便选。这二者之间，其实我更推荐前者。通过转专业或者辅修，最终可以收获知名院校的自己喜欢的专业的毕-业-证书。而后者最终只能收获普通院校的，自己喜欢的专业的毕-业-证书。如果有这样两份不同的学历放在HR面前，如果你是HR，你也会更倾向于选择前者吧？

这就是为啥选专业要放在选学校后面的原因。

再说城市与学校，这个就很好理解了。毕业后，大部分人都会选择参加工作。如果去的城市就业环境不好，机会少，行业内的大佬也不在此地聚集。就算个人再努力，和那些经常和行业大牛接触的人相比，日子久了，差距就会逐渐拉大。这是眼界、格局的差异，不是单纯的能力就可以弥补的。

简短地回顾完旧文章，我们把话题拉回来。就是要不要走软件开发这条路呢？

诚然，在这个问题上，我曾经没有丝毫犹豫，因为我根本就没想过甚至还有点抵触走这条路。

我最初的想法其实是做设计，图形图像方面，或是做视频剪辑。后来又想着做网络工程师，自学了一段时间的思科认证。直到后来快毕业的时候，有培训机构的讲师来做宣讲会，我稀里糊涂地就上了Android App开发这条船。也许是运气爆棚，我还真的挺适合走这条路。

但话说回来，为什么我会在大学期间对自己的未来有那么多的不确定呢？为什么不能坚定地走一条路呢？因为这个专业就不适合我，从一开始报得就有问题。

我填报志愿的时候是师范大学的信息工程，我依稀记得自己就是冲着这个名字选的，没怎么看都有哪些学科。根本就没料到会学什么单片机、电路原理、汇编语言之类的。这些我完全不感兴趣，学习成绩自然也很一般。虽然狗屎运一般地还拿了一次奖学金，但要说心里话，那就是：“这TM学的都是什么玩意”。我这个专业就一个班，而且是全学校唯一一个工科。我有时候就在想，我为啥报了这个专业，以至于荒废了四年大部分的时间。

而且我总共没怎么挂科，然而C语言挂了。所以当时的我怎么也想不到自己会做软件开发，其实这也注定了我也许做不到金字塔顶的那一小撮人。

所以，我特别希望今年的考生，特别是看到我这篇文章的考生，报志愿的时候一定要清醒一些，别像我似的。没有目标感的日子，真的不好过。

另一方面，也是我想表达的重点，就是如果我喜欢做的事情，不挣钱，或是就业前景非常不好，怎么办？

诚然，我当时报这个专业，或多或少是因为这个世界未来的时代将会是信息时代，这一点是毋庸置疑的。没错，选学校、选专业时，考虑的一个因素就是就业。但我认为，就业确实该考虑，但完全不用以它为导向。更多的，还是看个人的擅长领域，只要不是特别离谱就行。

举个例子，小X不喜欢编程，但迫于就业，想多挣些钱，走了编程这条路。刚开始的时候还不错，薪水在同学圈里不算低，自己也因为实现了多挣些钱的目的而开心。但随着时间的推移，他发现薪水的涨幅变慢了。更要命的是，由于自己根本就不喜欢编程，甚至会抵触工作。总是想：“要不是为了钱，老子早就辞职了”。终于有一天，遇到裁员潮。等到他在出去求职的时候，发现同龄人比自己强好多，自己在职场上几乎没什么竞争力。再加上年龄增大，薪酬高的能力够不上，薪酬低的不想去。陷入非常尴尬的境地。

另一个人，小Y，特别喜欢编程。第一份工作的工资或许没有小X高，但他干得很开心，因为他喜欢他的工作内容。而人一旦从事自己真心喜欢的事，就会变得非常积极主动。所以薪资很快就涨到了和小X差不多的水平，但他依然还是很积极地工作。随着他的薪水不断增多，生活水平慢慢地越来越好，他能在更舒适的环境中工作和学习。后来他发现，金钱对他来说不是第一要务，实现人生理想才是。于是他更加积极，甚至把自己所学分享给他人，决定做个对社会有贡献的人。

你看，这就是喜欢和不喜欢的区别，这里面的小Y其实就是我。

发自内心的喜欢，是工作积极主动的重要条件之一。对于真正喜欢的事业，做起来是会非常开心，非常投入，甚至还不觉得累，甚至还是不计回报的。在这种情形下，没有理由做不好。既然能做好，必然就会受到公司的青睐，不用为找不到工作发愁，从而让赚钱成为顺便的事儿。

所以，我的观点，在决定要不要走软件开发者这条路之前，不妨问问自己的内心：我真的喜欢这个行业吗？我真的具备这个行业从业者应有的素养：强大的自学能力、工作中的自律、缜密的逻辑等等吗？我愿意为了可能的加班，牺牲休闲时光吗？我愿意熬夜发版，牺牲睡眠吗？我愿意承担有可能秃如其来的迷人发型吗？……

但是，如果你和这个行业优秀的前辈们那样，希望用键盘，生产那些改善人们生活乃至改变世界的产品；是终身学习者，对新技术、新领域保持好奇；务实，不相信道听途说，善于用实践来检验真理；能和难题死磕到底……那么，非常欢迎你，成为我们的同行。

当然，一旦做了选择，那就没什么可说的。不再犹豫，风雨兼程。十余年的工作经验教会我一个朴实、简单却有奇效的道理——坚持。在坚持面前，一切困难都将不再可怕。而能坚持的人，便是手持利刃的勇士，必能披荆斩棘。

好了，说到这，就有点鸡汤的意味了，我就不给大家打鸡血了。

重复一下重点：走，抑或是不走软件开发这条路。要充分考虑自己的兴趣、擅长以及个性，切勿只考虑就业。况且，四年后的事，谁都说不准。

昨天，昨天和滨江的一个朋友聊了聊，他是那边的一个公司产品负责人，也算是核心合伙人的角色之一，他们的公司是做直播业务的，大概有七八十人的团队，开发人员大概是30人左右，占比35%左右，其中里面还有一个CTO角色，或者说技术总监的角色，其他的全部都是干活的小兵和小组长之类的。

我们主要聊到了两个不同规模的公司的工作模式的问题，因为我所在的是阿里巴巴应该是非常典型的超大型互联网公司，而他们公司这个人数刚好是属于小型的互联网公司。

他的公司主要是做直播业务的，大家都很熟悉诸如抖音快手这样的直播平台，这么小的公司怎么能做好一个直播平台呢？那他们的业务模式也非常的经典，那就是做一些非常小众的网红和用户产品。

一、直播市场的长尾用户

他描述了一下他自己的一些对于直播和用户的一些观点和理解，比如说现在众所周知的类似于抖音这样极大的平台，有超级大的网红IP，也有无数的粉丝。但是国内互联网用户基数非常之大，存在非常多的长尾用户，比如一些粉丝想在平台上获得一些娱乐感和交互感，这个是抖音这种大平台所满足不了的。另外一方面有大量的尾部网红在抖音这种大平台上面往往也拿不到任何的流量，所以他们也需要一种更小的平台，有充足的流量扶持。

在这个背景下就有了针对这些长尾用户的一些小的直播平台，那在小的直播平台上，哪怕你再小的网红，你都会有一些流量上面的倾斜，对于用户来说，在抖音上给大V打赏几万可能主播都不会理你，但是你在小平台上直接给主播进行打赏交互，就会变得更加的简单和高效。毕竟我们可以想象一下，很多花不起大价钱的“屌丝”用户，可能在这种小平台上面砸个几百几千，可能就能够约网红出来吃个饭，聊个天什么的。一些尾部网红也是一样，长期在抖音中大平台上面基本上没有流量，也没人关注和在意，但是到小平台上面可能就有比较多的几十个，甚至几百个粉丝过来和你交互和聊天打赏，很容易形成一个正反馈。

所以对于刚刚起步的网红来说，在这种小平台上面去发展，获得自己的正反馈和积累初步的影响力是非常的必要的。那对于一些没有太多钱、时间又空闲的粉丝们来说，对于小平台上面也能够有一个快速的通道去接触到这些主播或者兴趣相同的朋友。

于此同时，各行各业，蚊子肉都是大平台吃不到也不想吃的，这类长尾用户是大的平台是往往无法覆盖的，也是看不上的，所以给了这些小型的平台很多的发展空间，这个就是非常典型的一种长尾生态形式。也非常符合之前我所推荐的那本书叫做《长尾理论》，这种小平台因为它的边际成本是非常的低的，所以它可以在各个地方花钱去投放广告，吸引长尾客流，主打各种形式的娱乐化的直播并从中抽佣。

我们也可以看到这种平台本身也不大可能做的非常大，一方面它可能在形式和内容上面都可能走一些擦边或者灰色的方式，另外一方面对他们自己来说，他们也不想做的做大，做大以后以后就会面临着更加复杂的问题，比如监管问题。所以很多这种小型的平台活的非常的滋润，从来没想着做大做强，而是在自己的一亩三分细分领域里深耕，现金流反而还比大平台的还更加的充足。

他们公司在前两年就寻求上市，因为经济的原因中止，但这也就说明他这种模式实际上非常赚钱，现金流是非常的稳定的。

二、快进快出的用人理念

除了这种非常好的商业模式之外，另外一个讨论点就是我们工作模式上面的最大的区别。他提到了他们公司的员工的离职率是非常高的，基本上几个月、半年可能就大量的技术人员离职汰换。这个也很简单，她说对于新招聘的员工来说，如果半个月上不了手的情况下的话，就会在试用期里面就会解聘掉，主打就是追求实用主义，员工拿来即用没有培养一说。对于一个小的技术公司来说，它的成本控制的非常的严格，如果员工短时间内不能上手的情况下的话，对他们来说是没有任何价值的，所以对于员工都采用快进快出这样的方式，完全不像我们大平台大企业，可能给到一个员工的成长时间，短则三个月，大长则半年，一年。而小公司完全吃不消这种巨大的人力培养成本。

另外就是对于他们一些比较资深的工程师来说，工龄时间也不会太长，因为他们给不了员工的一个向上的晋升通道。当个员工工作了两年到三年，技术能力各方面能力都提高了，以后也没办法往上升或者持续加薪，因为毕竟上面只有一个技术合伙人，总不能把这个技术合伙人给顶下去吧，所以他们大部分的员工工作了两年到三年之后，技术能力上面都有非常大的成长之后，往往就会跳出这个小厂去寻求其他的大厂机会。

然后他们公司本身对于技术的追求也不深，大部分完全采用的是“拿来即用”的原则，他说在早期的时候做平台还会去找一些开源源码自己来部署，到了现在大部分能力都有非常成熟的第三方厂家来支持，他们公司技术人员只要做集成和包装就可以了。现在据我所知，类似于阿里云这样的云平台，已经把整个云计算API、网络直播的API，甚至很多底层技术全部做的非常好，都打包成SDK或者封装成API，所以上层业务方只要购买服务后把API包装一下，封装就可以直接使用了，五分钟生成一个直播平台APP已经没有任何问题了。

以我的理解，一个正常的工作了半年到一年的同学，我觉得在这种SDK或者API的加成下，就应该在一个星期内能创建出来一个直播平台APP了。所以很明显在这种基础能力非常强大的情况下，他们公司就会可以把成本压的更小，他们可以随时的去调整自己的业务方向和迭代，基本上几周就会有一个小版本迭代或者出全新的APP。

我问了一下，他们有没有一个知名的应用市场APP，给我的答案是他们开发成了很多非常小的一些APP，然后在应用市场上面去打广告引流，用户量和粉丝量都不算大，明显就能看到这种模式主打一个灵活、主打分布式。

三、反脆弱的商业形式

所以相对于小厂和中厂来说，不管从业务模式上还是从技术架构上，还是从经营理念上完全不可同日而语。但不得不说，我觉得正如我们的自然界生态系统一样，有些时候很微小的生物往往能够在漫长的生态环境中存活下来，比如蟑螂老鼠，而有一些庞然大物，诸如恐龙猛犸象这样的大体积的生物，反而还容忍不了生态气候的变化而灭绝。

而对于他这样小的一些经济体，几十个人，有自己的一些核心的产品模式，并且能够快速的迭代，对成本控制严格，对经济变化敏感，反而还能够存活到各个不同的周期里面，所以这我觉得也是一种值得我们羡慕的地方。这也是知名作家塔勒布在他的《反脆弱》一书里提到的一种形式，这种公司反而具备更强的反脆弱性，当经济越差，他们不仅不受影响，反而反弹变得更强壮、盈利性更强。

最后一步来说，对于程序员来说，根据自己的兴趣、爱好、能力水平，在当前的经济周期找到一个比较合适自己的平台，能够锻炼到自己的能力，不管是从技术还是从业务经营，产品各个方面都有所成长，那对自己来说就是好事。对于创业者来说也未必要盯着非常大的市场，动不动就来个规模效应，有时候去做这种非常小微公司和长尾市场，往往活得会更加的滋润和惬意。

前言

很多网站会在一些按钮上面加上不同的动画效果，这些动感的效果能够更加容易的创建具有视觉吸引力的用户界面。

本文将介绍一个小巧的 JavaScript 库，它能够用非常短的时间以及简短的代码量创建我们想要的五彩纸屑效果

简单使用

我们可以通过 npm 安装或从 cdn 导入两种方式来使用这个库。

这里我采用的是导入的方式。

在你导入完成这个库之后，我们需要一个按钮

<button onclick="myClick()">button</button>

最简单的特效只需要在点击函数当中调用 confetti 函数即可

function myClick () {

	confetti()

}

细节配置参数

通过传入 options 属性，我们可以在特效上自定义很多我们需要的部分，下面是部分配置属性的作用，后面我们会挑出部分属性来展示一下效果：

根据上面的参数，你可以很容易的定义自己想要的效果，下面我们随意定义部分例子：

<body>

  <button onclick="myClick1()">左倾斜</button>

  <button onclick="myClick2()">全是黑色</button>

  <button onclick="myClick3()">数量很多多多</button>

 <script src="https://cdn.jsdelivr.net/npm/canvas-confetti@1.9.0/dist/confetti.browser.min.js"></script>

  <script>

    function myClick1 () {

      confetti({

        angle: 135,

      });

    }

    function myClick2 () {

      confetti({

        colors: ['#000000']

      });

    }

    function myClick3 () {

      confetti({

        particleCount: 500,

      });

    }

  </script>



</body>

详细定义纸屑形状

在上面的配置当中我们已经可以定义纸屑的大部分配置，其中 shapes 可以用于定义纸屑的形状，官方为我们预留了三个形状 'square', 'circle', 'star' 分别对应 方形，圆形，星星，这个字段传入的是一个数组，这个数组中元素的数量，决定了这个形状在所有纸屑中的比例，比如说你要是传入了 ['square', 'circle', 'star'] 那么三种形状就都是占比三分之一。

除了通过官方预留的形状，我们还可以通过两个函数来进行形状自定义，分别是 confetti.shapeFromPath 和 confetti.shapeFromText

confetti.shapeFromPath

这个函数可以传入一个对象，对象中存在一个 path 的 key，这个就决定了创建出来的形状长什么样子

下面的代码可以创建一个三角形的纸屑

var triangle = confetti.shapeFromPath({ path: 'M0 10 L5 0 L10 10z' });



confetti({

	shapes: [triangle],

});

confetti.shapeFromText

这个函数同样传入一个对象，对象存在 text 和 scalar ， text 可以传入任何文字，甚至是一些文字表情也可以使用， scalar 配合 options 的 scalar 使用，两个相差过大会导致字体变得很模糊。

下面的代码你就可以创建一个字符串纸屑

var scalar = 2;

var pineapple = confetti.shapeFromText({ text: '🍍🍍🍍', scalar });

confetti({

	shapes : [pineapple],

	scalar,

});

逻辑事件

纸屑在生成的时候，我们可以会需要一些事件，比如说在我们想要的时候清除掉屏幕上还未消失的纸屑，又或者在一次纸屑彻底消失的时候执行某些逻辑。

消除纸屑

我们可以通过调用 confetti.reset(); 来消除屏幕上的纸屑

监听纸屑消失事件

在我们调用 confetti() 的时候会返回一个 promise 对象，这个对象将会在纸屑完全消失的时候回调。

自定义纸屑产生的位置

在上面的例子当中，我们可能会发现，纸屑都只能在屏幕的正中心产生，这是因为 options 里的 origin 属性的默认值，我们可以通过一些方式来自定义这个产生的位置

动态设置 origin

我们可以通过动态的来设置这个值来做到自定义产生的位置。

在点击事件当中，我们能够拿到当前的点击对象，通过这个 event 对象以及 window 上获取到可视区域的宽高，我们不难算出当前按钮相对于左右的位置。

const windowHeight =

  window.innerHeight ||

  document.documentElement.clientHeight ||

  document.body.clientHeight;

// 获取浏览器高度

const windowWidth =

  window.innerWidth ||

  document.documentElement.clientWidth ||

  document.body.clientWidth;

// 获取浏览器宽度

const origin = {

	x: event.pageX/windowWidth,

	y: event.pageY/windowHeight,

}

// 获取比例

自定义 canvas

官方支持我们创建自定义画布的  confetti 实例，这样创建的  confetti 不会超出定义的这个画布的范围，这在某些时候可能会起到很重要的作用。

并且官方强调了，一个画布最好只和一个  confetti 实例做关联，所以说当我们创建多个  confetti 实例的时候，就也需要创建多个画布。

因为是自定义添加的画布，所以我们需要在不需要的时候手动去删除这个画布，避免产生多余的元素。

var myCanvas = document.createElement('canvas');

var container = document.querySelector('.container')

container.appendChild(myCanvas)

var myConfetti = confetti.create(myCanvas).then(()=>{

	container.removeChild(myCanvas)

});

然后设定位置的操作我这里就不多做了，只需要定义这个 canvas 的生成位置就好了。

示例代码

如题，一些牢骚。希望对年轻的你有点帮助。

# 勇敢点

提前规划，在大学的时候，你就应该开始“面向大厂”规划自己的职业路线，争取校招进入大厂实习。

不要整天宅在图书馆，看什么 Linux 内核、Unix 编程艺术、Unix 网络编程、计算机的构造与解释、不要学那么多编程语言，Python、Java、Perl、Ruby、JavaScript、PHP、Go、C++…

多刷题，一定要争取去大厂，你一定可以，只要你勇敢点。

在现实生活中，人们往往依靠勇气而不是智慧去取得领先的地位。

# 不要呆在非一线城市

这里机会非常少，不是你不行，不要自卑，不要内耗，这不是你的问题，你应该去能够发挥你价值的地方。

虽然那里生活和工作节奏快。但是现在国内互联网企业都一个德性，都在模仿“狼性”文化，说着一样的互联网黑话，一样是内卷，去一线城市、一线大厂赚更多钱不好吗？

为了钱，不寒碜。

# 不要只关注技术，花点时间了解世界

不要只关注技术！别老是看那些技术类的书，你压根记不住，也很少有实践的机会。

多看点别的书，多了解自己、了解人类、了解世界、了解政治、了解经济/商业的运作原理和底层逻辑。提前布局、提前投资

世事洞明皆学问，不要穷极一生都是为了钱而工作，成为钱的奴隶，一直被恐惧和欲望支配。

推荐图书：人类简史、纳瓦尔宝典、富爸爸穷爸爸、黑客与画家

# 接受不完美的自己和代码

不要追求完美，你很普通，接受自己的平庸吧。

你不可能什么都精通，把精力花在自己核心竞争力上。

就像系统总有改不完的 bug，接受不完美的自己，学会放弃。

不要单打独斗、 尽量和更聪明的人共事。在矮子里面当将军，不如在巨人里面做士兵。

# 了解你的公司

不要只关注你眼前的这颗螺丝钉。

• 你的公司是做什么的？核心竞争力是什么？


• 公司的管理模式是什么？为什么要这样管理？规范的目的又是什么？


• 公司的商业模式是什么？靠什么赚钱？怎么卖出去？


• 公司的用户是谁？给用户创造了什么价值？


• 公司的技术架构是怎样？


• 公司的组织架构为什么设计？团队之间又是怎么协作的


• 我努力加班赚的钱，最后进谁兜里？凭什么是他？


• …

难道你不好奇？不八卦吗？

# 多积攒人脉

某些关键时刻，他们能捞你一把。同时你也要努力成为别人的有价值的人脉。

这其实并不需要你付出真感情，而应该把它当作资产。

# 可以认清现实，但是要保持批判精神

宏观的大环境个人是无法干预的，我们只能去适应。当然适应并不意味着委屈求全，每个人有选择的权利，当你无法接受公司的工作环境，不能接受公司的价值观，我们是可以选择跳出来的，而且越早越好。

我们的适应能力很强，同样能够适应糟糕的问题，然后置之不理。就比如人类的嗅觉，古人云”入芝兰之室，久而不觉其香；入鲍鱼之肆，久而不觉其臭”。

就比如笔者所在公司最近开始抓考勤打卡了，一开始内心十分抵触，现在也慢慢‘适应’了，也没有之前的抱怨，但我知道这对我来说并不是一件好事。

既要认清现实，保持批判精神，否则将一成不变。

# 关注战略设计

大部分程序员都是实现者，即战术实现者。很多时候，我们都不知道我们的工作的价值是什么。

因此我们也要关注战略设计，保持对一切事情的好奇心，尝试突破自己的职能边界，没人会阻止你，也很少人会给你机会。

# 效率从来不是一个人的事情，伟大的项目也是如此

不要相信小说、传记里面的孤胆英雄。

前几年关于 10 倍程序员也很多讨论，比如极客时间 10X 程序员工作法, 这些教程总结了很多务实的提效方法论。

总的来说，提高效率从来不是一个人的事情，另外程序员的主要工作‘编码’ 也仅仅只占整个研发流程的 20% ~ 30%。

# 不要什么都亲力亲为，学会外包

让你的能力和知识可以复制和传递，比如 CodeReview，技术写作，写好文档。

培养得力的助手，或者更好的方式是招揽比你更聪明的人。

# 不要轻信什么最佳实践

没有绝对正确的东西，没有放之四海皆准的东西。

学习它们，然后忘掉

# 问题的维度

不要只关注吃掉眼前的棋子，从更高的维度去解决问题。

举个例子

• 问题域。有些问题不一定就要在技术层面解决，可能在产品层面、战略层面就能规避掉。


• 解决域。另外，提升抽象的高度，在解决问题时能否举一反三？覆盖更多场景？

# 不要被奴役

• 鼓励抱怨，但也要解决问题。


• 不要为了钱而工作，让钱为你工作。


• 工作不是为了写代码，让代码为你工作。


• 把自己当成一家公司去经营


• 不要被雇主奴役，你和他们是雇佣合作关系，不是奴隶关系，不要被 PUA


• 不要被机器奴役。人类创造编程语言是为了服务人类，而不是服务机器。不要追求那些反人类的奇技淫巧，也不要自以为掌握了一门底层、学习曲线陡峭的编程语言而沾沾自喜，不符合人类心智的技术迟早被淘汰。

# 不管你喜不喜欢，在中国你还是得要学会“管理”

在国内 IT 打工人的体系更像是军队管理，俗话说就是吃年轻饭的。

尽管未来的趋势是分工的精细化，管理者也是占少数。为什么我就不能当个平庸的程序员呢？

• 我们所处的社会主导集体主义，自然也会滋生对权力的崇拜，很多人对这个金字塔尖趋之若鹜。权利也意味着‘成功’


• 平庸很容易被取代。而熟练工并没有壁垒，你能干别人也能干。商业是逐利，在高度内卷的市场下，为什么就不能选择跟便宜、精力更旺盛的年轻人呢？

你面前可能有几条路，创业、技术专家、管理，不管是哪条路都是很艰难，管理在很多人看来是顺理成章。

或者，现在就想想，你不搞 IT 还能干什么？提前做好投资

# 精心炮制的故事

这个世界的秩序是由精心炮制的故事组成，而且大部分人都相信它。

保持怀疑的姿势，可以让你跳出游戏

# 直面你的恐惧

为什么你会社恐？

为什么几天后的一个会议会让你忐忑不安？

为什么你那么在乎别人的看法？

为什么你总是感觉到焦虑？

为什么你不敢说出你的真实想法？

为什么你会情不自禁地与别人做比较，然后妄自菲薄？

为什么你会恐惧？如果人生是一场游戏呢？

# 编程的本质是抽象

编程是一门抽象艺术。

把现实世界的业务抽象成二维表，数据结构，对象关系、业务流程。

前端页面抽象成组件，低代码，DSL，本质上都是抽象的艺术。

抽象需要发挥人的主观能动性，人与人的差距就体现在这里。而工具通过学习一般都能掌握，很难建立壁垒

# 不要自我感动

• 只有功劳，没有苦劳。


• 选择比努力更重要。


• 大部分企业并不在乎你代码写得多多漂亮，而在于你能不能真正创造价值。

# 继续保持专注

远离那些垃圾。

# 总会有差评

不管是多好的产品都会有差评。

# 不要随波逐流

我发现，程序员群体大部分是比较‘安分守己’的，身边很多典型的例子，早早地结婚，早早地生子，996 的工作，电子产品自由，开着特斯拉，在老家可能还有套套牢的房。

人生的轨迹和父辈其实不会有太大的区别。

这真是你想要的人生吗？

# 降低欲望，你会更快乐

所有的痛苦都来源于欲望，远离一切成功学，回头是岸

前两天和实习那会的同事一起吃饭，聊到了他们那会刚毕业两三年的工作收入，问完我之后说，“你刚毕业一年的起点太高了，税后五位数，而且还是大专学历，这在外面根本找不到薪资那么多的工作”，“这一切还是得感谢你们几个人，如果不是前年你们收留了我，估计我都不干这行跑去流水线拧螺丝了”，我点头说道。

21年六月在学校投了上百份简历，面试收到了几个offer，但是实习工资给的太少，不是2.5k或者3k，这对于那时年少轻狂的我怎么可能接受呢，果断拒绝，快月底临近毕业找不到工作的我越来越慌了，后来约了一家线上面试并且通过了，实习工资150一天，正常每个月能拿3.3k，有节假日的情况下只能拿到不到2.8k的可怜工资。但命运真的很神奇，因为这家实习公司，结识了能够在职场上帮助到我的良师益友。

21年十月认识了一位朋友介绍的女生，可能是好久没和女生接触过，我变得不怎么会和女生聊天了，只记得我和她打了两个月的王者，基本上天天玩，还都是玩的人机，后来不知道啥原因就凉凉了，当然两个月也没见过面。当然因为这个事搞的我心烦意乱，工作没法工作，21年底，22年初，也就是元旦期间，我向公司提出离职，电话裸辞，直接就不去公司了，给老板整的一脸懵逼。22年一月中旬，公司聚餐邀请了已经离职的我，晚上酒喝起兴的我，在同事的劝说下，我向老板表明了我想回到公司的意向，后来如愿以偿的回到了公司，此时，我的工资不是150一天了，而且达到了惊人的4.5k每月。

22年六月临近毕业，在实习公司沉淀了一年，我觉得时机已经成熟是时候走了，鼓起勇气和老板说了离职，老板同意了。这个时候我还不知道未来的一年，我还会和他们经常聚餐，一起聊行业、工作、生活。甚至今天的这份工作也得益于他们。

离职后，准备去南京发展，当时在常州的同学那暂住了几天，闲的没事干就投了几份简历玩玩，面试了两家都收到了offer，一家给政府做erp系统的公司给了7.5k，另一家是上市公司的外包给了8k，随后我就不想去南京了，选择了那家外包公司，在那前几个月基本上天天没事，过的相当的安逸，每天晚上下班后，5:30准备到球场，后来我换了个组长，我开始做MES系统了，第一个系统我身份是打杂的，给另一个同事当助手，后来做的系统，我开始当主力开发。22年底，工作干的十分不顺心，萌生了离职的想法，向外包公司的部门经理提了涨薪，他只给涨500块钱，我觉得也没必要留下了，所性直接离职，此时我还没有转正，所以我直接在一周到走人。

再次离职后，我选择回到老家休息一段时间，思考一下第二年该去往何处。在家乡待了近四十天，基本上没有碰过电脑，我到处的玩，打球，打游戏，泡澡，感觉已经废了。

过年前几天，我开始慌了，于是我重新打开我的小米笔记本，打开了熟悉又陌生的IDEA，学习了几个开源框架，背了一些面试题，准备年后去外地找工作。

大年初三，我早早的买好火车票去往常州，准备在常州找一份工作，可惜我找了近一周，一份工作也没有找到，于是我将目光看向南京和老东家所在的苏州。我联系了实习公司一个同事现在所在的公司，于是他将我内推到了现在的这个公司，他向上面的人担保我肯定没有问题，所以我直接跳过了面试，也就是在这个公司，因为我代码写的好，所以我两次加薪达到了税后五位数。

23年五月二十号，公司安排我去西安出差两周，这是我人生第一次出差，见到了网络上所谓的甲方，值得我纪念一下。

如今，那位内推我的同事，也就是我第一份实习公司的同事，他要走了，去了一家做大数据的公司，领导让我开始学习做管理，以后带新人做项目，我只能说尽力而为。

对于像我这样学历不高的人而言，个人觉得代码不是技术架构，而是人情世故，人脉是人生宝贵的一笔财富。

上班摸鱼写于2023年7月12日11点。

效果图如下

上图的组成可以分为两部分，一个为底图六边形的形成，一个为内容六边形的形成。

要生成对应的六边形，首先要获得需要绘制的六边形的中心坐标。

观察不难得出结论，以中心的六边形为基点，第二圈很明显能排6个，第三圈能排12个，以此进行类推。

这里可以以中心点为坐标原点[0,0],以[1,0], [1,1],[-1,1],[-1,0],[-1,-1],[1,-1]这种形式来表示第二圈在轴线上的六个六边形的中心点关系（这是一种形式，并非真实的坐标系坐标）。

// 第二圈时的对应圆上的坐标值

const pixiArr = [

  [1, 0],

  [1, 1],

  [-1, 1],

  [-1, 0],

  [-1, -1],

  [1, -1]

]



// 根据圈数生成对应轴线上的坐标

function generatePixiArrByWeight(weight) {

  if (weight === 2) {

    return pixiArr

  }

  const multiple = weight - 1

  const tempPixiArr = pixiArr.map((x) => {

    return [x[0] * multiple, x[1] * multiple]

  })

  return tempPixiArr

}

进一步观察，可知，第三圈时两条发散的轴中间夹了一个六边形，第四圈时两条发散的轴中间夹了两个六边形，依次类推。

六条发散轴上的六边形中心点坐标是最容易计算的，不过要计算三圈及其开外的，就得有那么一点点的数学基础，知道sin60度cos60度的意思。

const sin60 = Math.sin(Math.PI / 3)

const cos60 = Math.cos(Math.PI / 3)

有了上面的铺垫后就可以开始了，定义一个函数，传入的参数为六边形总个数和六边形的边长

// 生成六边形中心坐标

function getHexagonCoordinateArrayByTotal(total = 0, radius = 0){

    // 1、获取圈数weight

    if (total === 0) return []

  let tierList = [] // 用于存放每圈的个数

  let tierIndex = 0

  while (total > 0) {

    if (tierIndex === 0) {

      tierList.push(1)

      total = total - 1

    } else {

      let n = 6 * tierIndex

      total = total - n

      if (total < 0) {

        tierList.push(total + n)

      } else {

        tierList.push(n)

      }

    }

    tierIndex++

  }

  const weight = tierList.length

    // 2、根据圈数去获取coordinateArray坐标列表

    // getHexagonCoordinateArrayByWeight：根据圈数和边长返回对应的坐标点

    const weight = tierList.length

  let coordinateArray = []

  for (let i = 0; i < weight; i++) {

    if (i + 1 === weight) {

      coordinateArray = [

        ...coordinateArray,

        ...getHexagonCoordinateArrayByWeight(i + 1, radius).slice(

          0,

          tierList[weight - 1]

        )

      ]

    } else {

      coordinateArray = [

        ...coordinateArray,

        ...getHexagonCoordinateArrayByWeight(i + 1, radius)

      ]

    }

  }



  return coordinateArray

}

有个getHexagonCoordinateArrayByWeight需要实现其，方式为

function _abs(val = 0) {

  return Math.abs(val)

}



function getHexagonCoordinateArrayByWeight(weight = 1, radius = 0) {

  if (weight === 0) return []

  if (weight === 1) return [[0, 0]]

  const addNum = weight - 2

  const addArr = generatePixiArrByWeight(weight)

  const hypotenuse = radius * sin60 * 2 // 两倍的边心距长度

  let offsetArr = []

  let offsetX

  let offsetY

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

    const t = addArr[i]

    if (t[1] !== 0) {

      offsetX = t[0] * hypotenuse * cos60

      offsetY = t[1] * hypotenuse * sin60

    } else {

      offsetX = t[0] * hypotenuse

      offsetY = 0

    }

    offsetArr.push([offsetX, offsetY])

  }

  const tempOffsetArr = JSON.parse(JSON.stringify(offsetArr))

  let resArr = new Array(6 * (weight - 1))

  let lineArr = []

  for (let i = 0; i < 6; i++) {

    let lindex = i * (weight - 1)

    resArr[lindex] = tempOffsetArr[i]

    lineArr.push(lindex)

  }

  // 利用已知的六个发散轴上的中心坐标点推出剩余的中心坐标点

  if (addNum > 0) {

    for (let i = 0; i < 6; i++) {

      let s = tempOffsetArr[i]

      let e = i + 1 === 6 ? tempOffsetArr[0] : tempOffsetArr[i + 1]

      let si = lineArr[i]

      let sp = addNum + 1

      let fx

      let fy

      if (i === 0) {

        fx = (s[0] - e[0]) / sp

        fy = (e[1] - s[1]) / sp

      }

      if (i === 1) {

        fx = (_abs(s[0]) + _abs(e[0])) / sp

        fy = 0



      }

      if (i === 2) {

        fx = (_abs(e[0]) - _abs(s[0])) / sp

        fy = (_abs(s[1]) - _abs(e[1])) / sp

      }

      if (i === 3) {

        fx = (_abs(s[0]) - _abs(e[0])) / sp

        fy = (_abs(e[1]) - _abs(s[1])) / sp

      }

      if (i === 4) {

        fx = (_abs(s[0]) + _abs(e[0])) / sp

        fy = 0

      }

      if (i === 5) {

        fx = _abs(s[0]) / sp

        fy = (_abs(e[1]) - _abs(s[1])) / sp

      }

      let mr = []

      for (let j = 0; j < addNum; j++) {

        if (i === 0 || i === 1) {

          mr.push([s[0] - fx * (j + 1), s[1] + fy * (j + 1)])

        }

        if (i === 2) {

          mr.push([s[0] - fx * (j + 1), s[1] - fy * (j + 1)])

        }

        if (i === 3) {

          mr.push([s[0] + fx * (j + 1), s[1] - fy * (j + 1)])

        }

        if (i === 4) {

          mr.push([s[0] + fx * (j + 1), s[1] - fy * (j + 1)])

        }

        if (i === 5) {

          mr.push([s[0] + fx * (j + 1), s[1] - fy * (j + 1)])

        }

      }

      mr.forEach((x, index) => {

        resArr[si + index + 1] = x

      })

    }

  }

  return resArr

}

至此，生成六边形中心坐标点的方法完成。
有了中心坐标生成方式之后，就可以使用Konva这种辅助绘图的库来进行效果绘制了。

我发现一个非常有趣的现象。

十多年前，那时“美女”这个称谓还是非常稀缺值钱的，被这么称呼的女性同胞占比，也就是不到10%的样子。

后来就愈发不可收拾了，只要是个女的活的，下至5岁上至50岁的，99%都被人称呼过“美女”。

当然，现在互联网行业的架构师，也越来越“美女化”了，基本上有个两三年工作经验的，带两三个应届生负责过一两个QPS不过十，用户量不过千的小系统的，把项目用SSM框架给搭建起来的，也都成架构师了。

而这些所谓的“架构师”们，如果仅仅是title上的改动，平时工作中该撸代码就撸代码，该摸鱼看网页就看网页，其实也真的没什么。

最最最最怕的就是，他们觉得自己的身份已经变了，是时候该体现出自己作为系统架构师价值的时候了，那一切就会变得不可收拾了。

这些架构师们体现价值的方式当然是做架构设计。按照他们的话说，系统架构要具备前瞻性、灵活性、复用性、伸缩性、可维护性、可扩展性、低耦合性、高内聚性、可移植性。当然，基本上90%都是过度设计。

下面让我们来细数一下，那些年，我所经历过的过度设计。

名副其实的微服务

不久前我面试过一个中小厂架构师，看他的简历上赫然写着，“主导XX系统从单体服务往微服务架构演进工作”。

然后我问他的问题是：“详细说下微服务拆分这件事情，包括：微服务拆分的原因、时机和拆分后的粒度。”

这个架构师说的第一句话就把我雷到了：“微服务拆分的粒度，我认为越细越好，不然为什么叫微服务呢？而且，现在的一个很小的微服务，随着业务的持续迭代演进，未来都有可能变得非常庞大，我们做架构设计的，必须要具备前瞻性。”

他接着说：“我们的微服务不但按照业务模型进行的拆分，而且我还按照controller层、service层和dao层也做了拆分，这样可以提升代码复用性，你想用我哪层的代码，就可以调用我哪层的API。”

最终，一个单体服务就被他拆分成了这样。

我问他：“微服务的‘三个火枪手原则’了解吗？”

他摇了摇头，说不清楚。

我心里感慨到，今年阿里云和腾讯云业绩能不能达标，全看这类架构师的了，他们是真费机器啊。

3个库和300张表

去年，跟一个三方公司临时组建了一个项目组，共同开发孵化A项目。

项目联调期间，我跟三方公司的小A说：“我刚调用了你们项目的XX接口，新增了20条交易数据，你看看你们接口的业务处理正常吗？数据库里面有这20条数据吗？”

小A说：“好的，稍等，我看看。”

20分钟过去了，我问小A看得怎么样了。

小A说：“业务处理是正常的，数据我正在一条条找，20条已经找到17条了，我在找剩下的3条。”

我听得有些懵逼，问小A：”你直接从你们订单表里，不能一下子看到20分钟前写入的20条数据吗？为什么还需要一条条找啊？“

小A说：”我们的架构师老张，按照每天三百万订单的数据增量，做了一个五年架构规划，已经分好了3个库和300张表。我现在正在根据他的路由规则，一条条地找这些数据。“

满城尽是大中台

呵呵，忽如一夜春风来，满城尽是大中台。

2015年福厂正式提出了“大中台、小前台”的中台战略，通过将原本分散到各个业务的支持部门，比如技术部门、数据部门集中到一起，进行快速的服务迭代，以期更高效地支撑前线，大幅降低支持部门的重复投资建设。

三年后，各个大小互联网公司纷纷跟进，争相建设自己家的中台，也就在这时，某独角兽公司的架构师老范过来找我取经。

我跟老范说：“你们的两个主业务是机票和酒店，业务差别太大了，且创新孵化业务并不多，并不适合中台策略。”

老范说：“不，中台这个我们一定要搞，因为既是研发团队的政治任务，也是我个人的技术追求。”

半年后，我问老范搞得怎么样了，老范说：“唉，讨论了半年哪些职责属于大中台，哪些职责属于小前端，现在还没讨论明白呢。”

无处不在的消息队列

福厂收购了某公司，在收购后的一次技术交流中，我听到对方公司的首席架构师说：“MQ是个好东西，能异步处理，能消峰，能解耦，还是应该在项目中多用用的。”

后来发现，大首席架构师的下级执行力真强，MQ真的在他们的项目中无处不在：

• 发短信验证码的场景用MQ，且其生产者和消费者是同一个服务，就为了用MQ异步调用短信服务的SDK；


• 打业务日志的场景用MQ，且其生产者和消费者是同一个服务，就是为了用MQ异步打一行日志；


• TPS个位数的约课场景用MQ，且其生产者和消费者是同一个服务，其美名曰进行消峰；


• 各服务间的通信基本上80%都用了MQ，而不是RPC，其美名曰系统解耦；

牛逼Class！

遍地开花的多级缓存

对，对，还是上次的那个首席架构师，他除了爱用消息队列外，还特别喜欢用缓存，而且是Guava Cache + Redis的多级缓存。

据同事说，这种多级缓存策略在这位首席架构师的熏陶下，已经遍布了OA系统、公司官网、消息中心、结算系统、供应链系统、CRM系统。

首席架构师说：“缓存不仅能提升性能，还能帮助数据库抗压，提升系统可用性，绝对是个好东西，应该多用一用。”

然后，公司的系统就经常发生多种缓存的数据与数据库的数据一致性问题。

首席架构师又说：“任何架构都是有利有弊的，但只要利大于弊就好，不要太在意。”

设计模式的流毒

记得我刚上班不久，组内有一个架构师同事，写的代码巨复杂，各种技巧、设计模式、高级语法满天飞，还沾沾自喜的给我们炫耀。

一次Code Review的时候，我嘴欠问他这里咋这么设计，他就鄙视的说：“你连这个都不知道，这是设计模式中的建造者模式啊。”

当时觉得他好牛逼，而我好low。

以后，每次进行Code Review，只要看到其他同事代码里有几个if else，架构师同事就质问道：“为什么不用策略模式优化if else？”

当然，还有其他的质问，类似于：这块为什么不用抽象工厂模式？这块为什么不用代理模式？这块为什么不用观察者模式？

后来我们就给他起了个外号，叫“设模”（se mo）。

多多益善的复杂关系

前面说的那些架构师们，他们过度设计所带来的后果是浪费服务器和研发资源，但架构师老邓不一样，他的过度设计是浪费表。

之前见过某在线教育公司设计的表结构，基本上所有表之间的外键关系都是按照多对多方式设计的，也就是加一个中间的关系映射表。

有的我是可以理解的，比如：

• 一个学生会出现在多个不同的班级里，而一个班级里也会有不同的学生；


• 一个学生可以学习多门课程，而每门课程又会对多个学生进行学习；


• 一个学生可以上多个老师的课，而一个老师又可以教多个学生；

但是，但是。

• 一个学生可以有多个考试成绩，难道一个考试成绩还能属于多个学生吗？


• 一个学生有多个课程的课时余额，难道一个课时余额还能属于多个学生吗？

老邓说：“万一以后业务变化了呢？一切皆有可能啊。”

数据库的可移植性

还在上大学的时候，在CSDN上看某著名架构师在极力强调数据库的可移植性。

我记得当时的原话大概是：

• Hibernate的HQL可以帮我们保证不同数据库之间的移植性，比如：MySQL中的limit和Oracle中的rownum。


• 为什么不能写存储过程？一个重要的原因就是业务逻辑放到数据库里会导致数据库移植成本变大。


• 程序内尽量采用标准SQL语法，因为我们要考虑将来的移植风险。

当时听了，觉得这个大架构师简直就是YYDS。然后我工作了这么多年，也没遇到过一次数据库移植。

无间道版的数据校验

我厂某团队的架构师老李素以严谨著称，其经常放在嘴边的一句话就是：“工程师不仅仅是一项有创造性的职业，也是一门严谨审慎的职业。”

这话说的确实没毛病，我也看过他们团队的工程代码，程序的边界处理、异常处理和容错处理做得都特别好，入参校验也是特别细致入微。

就像老李所说的那样：“All input is evil。”

不，等等，入参校验没问题，但怎么从数据库里读出来的数据，为什么还要再校验一遍？难道不是在写入的时候校验吗？

老李面无表情地说：“如果数据库中的数据，并没有经过应用程序处理，而是不知道被谁直接改库了呢？”

卧槽，这是泥马数据校验无间道版吗？

疯魔成活的配置化

还是上面的那个架构师老李，他要求团队代码中带数字的地方，全部走配置中心，这样可以不发布代码就直接进行修改。

然后，我就看到了这样的现象：

• 如果某个HashMap的size大于0，则进行xxxx，这个0写到了配置中心里。


• 如果用户性别等于1（男性），则进行男装推荐，这个1写到了配置中心里。


• 如果商品状态等于2（已下线），则进行xxxx，这个2写到了配置中心里。

配置中心啊，你的责任真的好重大。

总结

遇到这种类型的架构师，真的特别想把他们祭天了，因为我是Kiss原则的忠实拥趸。

Keep it simple，stupid，即：保持简单、愚蠢。

保持简单就能让系统运行更好，更容易维护扩展，越是资深的人，越明白这个道理。

曾经有一段职场生涯，坐了很长时间的冷板凳，也正是那段经历，彻底改变了整个职场生涯。今天这篇文章聊聊自己曾经的经历，也聊聊如果在职场中被坐了冷板凳该咋办。

关于冷板凳

有人的地方就有江湖。而这个江湖中是否性情相同，是否因某些事（或利益）产生矛盾，都可能造成职场坐冷板凳的情况。

冷板凳常见于上级对下级的打压。一般手段就是让你无所事事或安排一些边缘性的事务，不怎么搭理你，从团队层面排挤你，甚至否定你或PUA你，别人也不敢跟你沟通，以至于让你在团队中形成孤立的的状态。

根据矛盾或冲突的不同，冷板凳的程度也不同。常见的有：浅层次的冲突，可进行修复；不可调和，无法修复；中间的灰度状态。

通常根据具体情况，判断程度，有没有可能或必要修复，再决定下一步的行动。

第一，可修复的冷板凳

有很多同学，特别是技术人，在职场上有时候特别的“刚”，为了某个技术点跟领导争的面红耳赤的，导致被坐冷板凳。

比如有同学曾有这样的经历：领导已经拍板的决定，他很刚的去跟领导据理力争，导致起了冲突，大吵一架，领导也下不来台。随后领导好几天没搭理他。

针对这种情况，一般也就是一顿火锅的事，找领导主动沟通，重拾信任。甚至可能会出现不打不相识的情况。当然，一顿火锅不够还可以两顿。

第二，清场性质的冷板凳

这种情况常见于业绩或能力不达标，已经是深层次的矛盾，一般会空降过来一个领导，故意将其边缘化。属于清场接替工作性质的，基本上无法修复。

针对这种情况，看清局势，准备好找下家就是了。如果做得好，准备好交接工作，给彼此一个体面。毕竟，很多事情我们是无法改变的。

第三，灰度状态的冷板凳

以上两个常见都比较极端，而大多数情况下都是灰度状态的，大的可能性就是一直僵持着。这时作为下属的人，一般建议主动去沟通、修复。

如果阅历比较浅，看不出中间的微妙关系以及深层次的冲突点，就请人帮你看看，听听别人的建议和决策。再决定值不值得修复，要不要修复。

我的冷板凳

曾经我在一家公司坐的冷板凳属于第三种，但却把这个冷板凳坐到了极致。下面就讲讲我曾经的故事。

跟着一个领导到一家新公司，本来领导带领技术部门的，但由于内部斗争的失利，去带产品团队了，而我也归属到他对手的手下了。这种情况下，冷板凳是坐定了，但也不至于走人。

被新领导安排了一个很边缘的业务：对接和维护一套三方的系统。基本上处于不管不问，开会不带，接触不到核心，也与其他人无交流的状态。起初这种状态非常难受，人毕竟是社群动物，需要一个归属感和存在感的。

但慢慢的，自己找到了一些属于自己的乐趣。

首先，没人管没人问，那就可以自己掌控节奏和状态了。看他们天天加班到凌晨一两点，而自己没人管，六七点就下班了。最起码在那段持续疯狂加班的岁月里，自己保住了头发。那位大领导后来加班太多，得了重病，最终位置也没保住。

其次，有了大把的时间。上班几乎没人安排工作，于是上班的时间完全自己安排。三方服务商安排了对接人，好歹自己作为甲方，于是天天就跟服务商的技术沟通，询问他们系统的设计实现，技术栈什么的。

在那段岁月里，完成了几个改变后续职场生涯的事项。

事项一：那时Spring Boot 1.5刚刚发布，公司的技术栈还没用上，但服务商的这套系统已经用上了。感觉这玩意太好用了，于是疯狂的学学习。因为当初的学习，后来出版了书籍《Spring Boot技术内幕》那本书。

事项二：写技术博客，翻译技术文档，录技术视频。服务商的系统中还用到了规则引擎，当时市面上没有相关的中文资料。于是边跟对方技术沟通，边翻译英文文档，写博客。后来，还把整理的文档录制成视频，视频收入有几万块吧。

这算是自己第一次尝试翻译文档、录制教学视频，而且这个领域网络上后续的很多技术文章都是基于我当初写文章衍生出来的。最近，写的第二本书便是关于规则引擎的，坐等出版了。

事项三：学习新技术，博客输出。当时区块链正火爆时。由于有大量的时间，于是就研究起来了，边研究边写技术博客。也是在这个阶段，养成了写技术博客的习惯。

因为区块链的博客，也找到了下家工作。同时写了CSDN当时类似极客时间的“Chat”专栏，而且是首批作者。也尝试搞了区块链的知识星球。后来，因为区块链的工作，做了第一次公开课的分享。还是因为区块链相关，与别人合著了一本书，解释了出版社的老师，这也是走上出书之路的开始。

因为这次冷板凳，让职场生涯变得极其丰富，也扭转了大的方向，发展了副业，接触了不同行业领域的人。

最后的小结

在职场混，遇到坐冷板凳的情况不可避免，但如何化解，如何抉择却是一个大学问。尽量主动沟通，毕竟找工作并不容易，也不能保证下家会更好。同时，解决问题，也是人生成长的一部分，所以，尽量尝试化解。

但如果矛盾真的不可调和或持续僵持，那么就更好做好决策，选择对自己最有利的一面。

曾在朋友圈发过这样一段话，拿来与大家分享：

“始终难守樊登讲过的一句话：人生成长最有效的方法，就是无论命运把你抛在任何一个点上，你就地展开做力所能及的事情。

如果还要加上一句，那就是：还要占领制高点。与君共勉～”

防不胜防，10分钟就被AI骗走430万！

这是这两天震惊全网的真实诈骗案件。

据包头警方发布，一公司老板接到朋友的微信视频电话，由于长相和声音确认都是“本人”，他丝毫没有怀疑就把钱打了过去。

结果一问朋友，对方根本不知道此事。这人才知道，原来诈骗者DeepFake了他朋友的面部和声音。

消息一出，直接冲上热搜第一。网友们纷纷表示：离大谱啊！不敢接电话了。

也有人提出质疑：AI这么好训练？这需要掌握个人的大量信息吧。

不过，虽说是看上去离谱的小概率事件，但据相关统计，AI技术新骗局来袭后，诈骗成功率竟接近100% 。

毕竟连那些直播卖货“杨幂”“迪丽热巴”、B站歌手“孙燕姿”“林俊杰”都不是真的。

△图源抖音@娱乐日爆社，疑似直播间用杨幂的AI换脸带货

10分钟被AI骗走430万

据微信号平安包头介绍，一个月前，福州市一科技公司法人代表郭某，突然接到好友的微信视频。

聊天过程中，这个“好友”透露，自己朋友在外地投标，需要430万保证金，且公对公账户过账，所以想用郭某公司的账户走一下账。

背景介绍之后，“好友”就找郭某要了银行卡号，而后甩出一张银行转账底单的截图告诉郭某，已经把钱打到了郭某的账户上。

结果因为已经视频聊天以及各种“物证”，郭某并没有过多怀疑，甚至也没去核实钱款是否到账。

几分钟之后郭某就分两笔将钱打了个过去，本想去跟好友报备一下：“事情已经办妥”。

然而，好友缓缓打出来一个问号。

好在郭某反应比较快，第一时间报警。于是在警方和银行联动下，仅用时10分钟就成功拦截了330多万元被骗资金。

有网友表示，AI正成为骗子高手新一代工具。

还有网友调侃道，我没钱，哪个都骗不了我。（等等，好友有钱也不行doge）

而在这起案件背后，核心涉及了AI换脸以及语音合成这两个技术。

大众所熟知的AI换脸方面，现在即便一张2D照片，就能让口型动起来。据此前新华每日电讯消息，合成一个动态视频，成本也仅在2元至10元。

当时涉案嫌疑人表示：“客户”往往是成百上千购买，牟利空间巨大。

至于面向更精准、更实时的大型直播平台，视频实时换脸的全套模型购买价格在3.5万元，而且不存在延迟、也不会有bug。

至于像语音合成方面，技术效果也是越来越逼真，新模型和开源项目涌现。

前段时间，微软新模型VALL·E炸场学术圈：只需3秒，就可以复制任何人的声音，甚至连环境背景音都能模仿。

而具备语音合成功能的工具Bark，更是曾登顶GitHub榜首，除了声色接近真人，还能加入背景噪音和高度拟真的笑声、叹息和哭泣声等。

在各类社交网络上，各种小白教程也层出不穷。

要是结合虚拟摄像头，可能就更加防不胜防。

只需一个软件应用程序，就可以在视频通话中使用任意视频资源。

△图源微博@哑巴

点击接通后，对方完全不会看到播放、暂停视频等具体操作，只会看到视频播放的效果，“接通后看到的就是美女了”：

△图源微博@哑巴

这样一来，不仅视频可以通过虚拟摄像头，随意拍摄甚至更换，甚至连说话方式都可以真人定制：

△图源微博@哑巴

核心技术门槛的降低，也就给了犯罪分子可乘之机。

AI新骗局成功率接近100%

事实上，AI加持下的新型网络诈骗，并不止这一种操作。

无论是国内还是国外，都有不少用AI换脸的诈骗案例，小到在网络购物、兼职刷单等方面骗点小钱，大到冒充客服、投资理财人员等身份，获取银行卡账号密码直接转一大笔账，都有出现。

在国内，据南京警方消息，此前就出现过一起被QQ视频AI诈骗3000元的案例。

当事人小李表示，自己的大学同学小王通过QQ跟自己借3800元，称自己很着急，因为表姐住院了。

小李怀疑了小王的身份，而小王很快给她传来了一个4~5秒左右的动态QQ视频，不仅背景在医院，而且还打了声招呼。

这让小李打消了疑虑并转了3000元，然而随后发现对方已经将她删除拉黑，发现视频原来是AI伪造的。

目前包括北京反诈、武汉市反电信网络诈骗中心等官方公众号平台，都警告了AI技术新骗局的严重性，甚至表示“诈骗成功率接近100%”。

可别以为这些诈骗现象只在国内出现，国外的语音诈骗同样花样百出。

一种方式是用AI合成语音骗取电话转账。

据Gizmodo介绍，英国最近就同样发生了一起涉及金额高达22万英镑（折合人民币约192.4万元）的诈骗案件。

一位当地能源公司的CEO，在不知情的情况下被骗子“DeepFake”了自己的声音。随后，骗子用他这段声音，电话转账了22万英镑到自己的匈牙利账户。

据CEO表示，他后来自己听到这段AI合成语音时都惊讶了，因为这段语音不仅模仿出了他平时说话的语调，甚至还带有一点他的口癖，有点像是某种“微妙的德国口音”。

另一种则是用合成语音冒充亲友身份。

据nbc15报道，美国一位名叫Jennifer DeStefano的母亲，最近接到了一个自称是“绑匪”的诈骗电话，对方称劫持了她15岁的女儿，要求这位母亲交出100万美元的赎金。

电话那头传来了女儿的“呼救声”，不仅声音、就连哭声都非常相似。幸运的是她的丈夫及时证明了女儿是安全的，这次诈骗才没能成功。

现在，不仅是诈骗，在AI技术加持下，就连杨幂、迪丽热巴们都在今天引发了热议。

原来，这是商家们想出的新“搞钱之道”，那就是在直播的时候，用AI换脸等技术“Deepfake”一下杨幂、迪丽热巴、Angelababy等明星的脸，这样大家就会误以为是明星本人在带货，从而拉升直播流量。

然而，这类行为目前还不能被直接判定为侵权。据21世纪经济报道，北京云嘉律师事务所律师赵占领表示：

平台对于平台内商家的侵权行为不承担直接侵权的责任，而是否构成帮助侵权，主要是看平台对于商家的侵权行为是否属于明知或应知。

但对于如何判定平台对用户、权利人的投诉是否明知或应知，在一般情况下很难认定。

显然，在AI技术越来越火热的当下，相关法律也还需要进一步完善。

One More Thing

就在昨天夜里，最近火爆全网的“AI孙燕姿”本人，也就是歌手孙燕姿，出来回应了。

她发布了一篇名为《我的AI》的英文版文章，这是她团队的中文翻译全文：

然后，网友们看到后的评论是酱婶的：

△图源微信@南方都市报

参考链接：

[1]mp.weixin.qq.com/s/Ije3MyQxN…

[2]mp.weixin.qq.com/s/kcbNlaFe_…

[3]gizmodo.com/deepfake-ai…

[4]http://www.nbc15.com/2023/04/10/…

[5]weibo.com/1796087453/…

[6]weibo.com/1420862042/…

— 完 —

前言： 最近接到的一个需求十分有意思，设计整体实现了前端仿微信扫一扫的功能。整理了一下思路，做一个分享。

tips: 如果想要实现完整扫一扫的功能，你需要掌握一些前置知识，这次我们先讲如何实现拍照并且保存的功能。

一. window.navigator

1. 
   

   你想调取手机的摄像头，首先你得先检验当前设备是否有摄像设备，window 身上自带了一个 navigator 属性，这个对象有一个叫做 mediaDevices 的属性是我们即将用到的。

   
   


2. 
   

   于是我们就可以先设计一个叫做 checkCamera 的函数，用来在页面刚开始加载的时候执行。。
   
   
   

   
   


3. 
   

   我们先看一下这个对象有哪些方法，你也许会看到下面的场景，会发现这个属性身上只有一个值为 null 的 ondevicechange 属性，不要怕，真正要用的方法其实在它的原型身上。
   

   
   


4. 
   

   让我们点开它的原型属性，注意下面这两个方法，这是我们本章节的主角。
   
   

   
   


5. 
   

   我们到这一步只是需要判断当前设备是否有摄像头，我们先调取 enumerateDevices 函数来查看当前媒体设备是否存在。它的返回值是一个 promise 类型，我们直接用 async 和 await 来简化一下代码。
   
   
   从上图可以看出，我的电脑有两个音频设备和一个视频设备，那么我们就可以放下进行下一步了。

   
   

二. 获取摄像头

1. 
   

   接下来就需要用到上面提到的第二个函数，navigator.getUserMedia。这个函数接收一个对象作为参数，这个对象可以预设一些值，来作为我们请求摄像头的一些参数。

   
   


2. 
   

   这里我们的重点是 facingMode 这个属性，因为我们扫一扫一般都是后置摄像头
   
   当你执行了这个函数以后，你会看到浏览器有如下提示：
   
   
   

   
   


3. 
   

   于是你高兴的点击了允许，却发现页面没有任何变化。
   
   
   

   
   


4. 
   

   这里你需要知道，这个函数只是返回了一个媒体流信息给你，你可以这样简单理解刚刚我们干了什么，首先浏览器向手机申请我想用一下摄像头可以吗？在得到了你本人的确认以后，手机将摄像头的数据线递给了浏览器，：“诺，给你。”

   
   


5. 
   

   但浏览器现在仅仅拿到了一根数据线，然而浏览器不知道需要将这个摄像头渲染到哪里，它不可能自动帮你接上这根线，你需要自己找地方接上这根数据线。

   
   


6. 
   

   这里不卖关子，我们需要请到我们的 Video 标签。我没听错吧？那个播放视频的 video 标签？没错，就是原生的 video 标签。

   
   


7. 
   

   这里创建一个 video 标签，然后打上 ref 来获取这个元素。
   
   

   
   


8. 
   

   这里的关键点在于将流数据赋值给 video 标签的 srcObject 属性。就好像你拿到了数据线，插到了显示器上。
   
   (tips: 这里需要特别注意，不是 video.src 而是 video.srcObject 请务必注意)
   
   

   
   


9. 
   

   现在你应该会看到摄像头已经在屏幕上展示了，这里是我用电脑前置摄像头录制的一段视频做成了gif。(脉动请给我打钱，哼)
   

   
   

三. 截取当前画面

1. 
   

   这里我随手写了一个按钮当作拍摄键，接下来我们将实现点击这个按钮截取当前画面。
   
   

   
   


2. 
   

   这里你需要知道一个前提，虽然我们现在看到的视频是连贯的，但其实在浏览器渲染的时候，它其实是一帧一帧渲染的。就像宫崎骏有些动漫一样，是一张一张手写画。

   
   


3. 
   

   让我们打开 Performance 标签卡，记录一下打开掘金首页的过程，可以看到浏览器的整个渲染过程其实也是一帧一帧拼接到一起，才完成了整个页面的渲染。
   
   

   
   


4. 
   

   知道了这个前提，那么举一反三，我们就可以明白，虽然我们现在已经打开了摄像头，看到的视频好像是在连贯展示，但其实它也是一帧一帧拼到一起的。那现在我们要做的事情就非常明了，当我按下按钮的时候，想办法将 video 标签当前的画面保存下来。

   
   


5. 
   

   这里不是特别容易想到，我就直接说答案了，在这个场景，我们需要用到 canvas 的一些能力。不要害怕，我目前对 canvas 的使用也不是特别熟练，今天也不会用到特别复杂的功能。

   
   


6. 
   

   首先创建一个空白的 canvas 元素，元素的宽高设置为和 video 标签一致。
   
   

   
   


7. 
   

   接下来是重点： 我们需要用到 canvas 的 getContext 方法，先别着急头晕，这里你只需要知道，它接受一个字符串 "2d" 作为参数就行了，它会把这个画布的上下文返回给你。
   （ tips 如果这里还不清楚上下文的概念，也不用担心，这里你就简单理解为把这个 canvas 这个元素加工了一下，帮你在它身上添加了一些新的方法而已。)
   

   
   


8. 
   

   在这个 ctx 对象身上，我们只需要用到一个 drawImage 方法即可，不需要关心其它属性。
   
   

   
   


9. 
   

   感觉参数有点多？没关系，我们再精简一下，我们只需要考虑第二个用法，也就是5参数的写法。(sx,sy 是做裁切用到的，本文用不到，感兴趣可以自行了解。)
   
   

   
   


10. 
    

    这里先简单解释一下 dx 和 dy 是什么意思。在 canvas 里也存在一个看不见的坐标系，起点也是左上角。设想你想在一个 HTML 的 body 元素里写一个距离左边距离 100px 距离顶部 100px的画面，是不是得写 margin-left:100px margin-top:100px 这样的代码？没错，这里的 dy 和 dx 也是同样的道理。
    
    

    
    


11. 
    

    我们再看 dwidth，和 dheight，从这个名字你就能才出来，肯定和我们将要在画笔里画画的元素的宽度和高度有关，是的，你猜的没错，它就好像你设置一个 div 元素的高度和宽度一样，代表着你将在画布上画的截图的宽高属性。

    
    


12. 
    

    现在只剩下第一个参数还没解释，这里直接说答案，我们可以直接将 video 标签填进去，ctx 会自动将当前 video 标签的这一帧画面填写进去。现在按钮的代码应该是这个样子。

    
    

    function shoot() {
    
      if (!videoEl.value || !wrapper.value) return;
    
      const canvas = document.createElement("canvas");
    
      canvas.width = videoEl.value.videoWidth;
    
      canvas.height = videoEl.value.videoHeight;
    
      //拿到 canvas 上下文对象
    
      const ctx = canvas.getContext("2d");
    
          ctx?.drawImage(videoEl.value, 0, 0, canvas.width, canvas.height);
    
      wrapper.value.appendChild(canvas);//将 canvas 投到页面上
    
    }
    
    

    
    


13. 
    

    测试一下效果。
    
    

    
    

四. 源码

<script lang="ts" setup>

import { ref, onMounted } from "vue";



const wrapper = ref<HTMLDivElement>();

const videoEl = ref<HTMLVideoElement>();



async function checkCamera() {

  const navigator = window.navigator.mediaDevices;

  const devices = await navigator.enumerateDevices();

  if (devices) {

    const stream = await navigator.getUserMedia({

      audio: false,

      video: {

        width: 300,

        height: 300,

        // facingMode: { exact: "environment" }, //强制后置摄像头

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

      },

    });

    if (!videoEl.value) return;



    videoEl.value.srcObject = stream;

    videoEl.value.play();

  }

}



function shoot() {

  if (!videoEl.value || !wrapper.value) return;

  const canvas = document.createElement("canvas");

  canvas.width = videoEl.value.videoWidth;

  canvas.height = videoEl.value.videoHeight;

  //拿到 canvas 上下文对象

  const ctx = canvas.getContext("2d");

  ctx?.drawImage(videoEl.value, 0, 0, canvas.width, canvas.height);

  wrapper.value.appendChild(canvas);

}



onMounted(() => {

  checkCamera();

});

</script>

<template>

  <div ref="wrapper" class="w-full h-full bg-red flex flex-col items-center">

    <video ref="videoEl" />

    <div

      @click="shoot"

      class="w-100px leading-100px text-center bg-black text-30px"

    >

      拍摄

    </div>

  </div>

</template>

五. 总结

实现拍照的整体思路其实很简单，仅仅需要了解到视频其实也是一帧一帧画面构成的，而 canvas 恰好有捕捉当前帧的能力。

预告：在下一篇会讲解如何实现扫一扫的功能，需要用到插件，感兴趣的同学可以先预习一下功课。🎁二维码扫码插件

趁热打铁🧭:前端实现微信扫一扫的思路

前言： 在有了获取手机摄像头权限并且记录当前画面的前置知识以后，我们现在已经可以进行下一步实现一个仿微信扫一扫的功能了。

tips: 如果你是直接看的本文，对如何打开摄像头拍照这个功能还不太熟悉，请移步 🎁前端如何打开摄像头拍照。这是你阅读本篇的必需前置知识。

一. 效果预览

这里先简单放一下整体界面效果，接下来带大家一步一步分析其中的功能如何实现。

本篇将重点讲解多张二维码识别的处理场景。

二. 简单了解二维码

1. 
   

   现在流行使用的二维码是 qrcode，其中 qr 两个字母其实就是 quick response 的缩写，简单来说就是快速响应的意思。三个角用来定位，黑点表示二进制的1，白色点代表0。（这里感兴趣可以自行了解) 它的本质其实就是将一个地址链接利用某种约定好的规则隐藏到一个图片当中，
   
   

   
   


2. 
   

   我们可以利用 chrome 自带的创建当前网站二维码的功能快速体验一下。
   

   
   


3. 
   

   你可以用手机自带的二维码扫码软件扫一下这个二维码，它将会将你引导到我掘金的个人主页。
   
   

   
   


4. 
   

   细心的你可能会发现二维码下面已经给你提示了你准备保存的链接地址，现在你观察一下浏览器地址栏是否正对应下面这个地址呢？
   

   
   

三. 实现扫码本地图片功能

1. 
   

   我们不需要深入了解这个二维码的转换规则，我们可以直接选用现有的插件即可完成识别功能。 这里我们选用 antfu 大佬的轮子。这里我们不过多介绍，你只需要它可以识别出图片中的二维码即可。如果感兴趣，这是具体仓库地址 qr-sanner-wechat。

   
   


2. 
   

   首先安装 npm i qr-scanner-wechat。

   
   


3. 
   

   它的使用方法也十分简单，这个依赖导出了一个方法，我们直接引入这个方法即 import { scan } from 'qr-scanner-wechat。

   
   


4. 
   

   这个函数可以接收一个 image 元素或者 canvas 元素作为参数，并且返回一个 promise 类型的值。

   
   


5. 
   

   我们先来测试最简单的，传入一个 image 元素，利用 input 标签的 type=file 属性，就可以从本地选择图片，比较基础的知识，不过多赘述，代码如下。

   
   

   function getImageFromLocal(e: Event) {
   
     const inputEl = e.target as HTMLInputElement;
   
     if (!inputEl) return;
   
     console.log("inputEl.files", inputEl.files);
   
   }
   
   
   
   
   
   

   
   

   然后我们可以通过 input 元素绑定的 onChange 回调中拿到 input 元素身上的 files 属性，就可以获取到刚刚我们选择的文件信息。
   
   

   
   


6. 
   

   但是目前这个数据对象我们还无法使用，需要借助 URL.createObjectUrl 方法来创建一个普通的 url 地址。
   
   

   
   


7. 
   

   当拿到这个 url 地址以后该如何使用呢？🤔
   

   
   


8. 
   

   一个熟悉的老朋友，有请 img 标签出场，👏，我们只需要将 img 标签的 src 替换成刚刚保存的 url 地址即可。
   
   
   
   现在整体效果应该是这样的：
   
   

   
   


9. 
   

   有了 img 元素，我们直接将这个元素赋值给 qr-scanner-wechat 插件提供的 scan 函数即可。
   
   
   

   
   


10. 
    

    我们来测试一下整体流程。
    
    
    

    
    


11. 
    

    可以看到，scan 函数返回了一个对象，这个对象身上有两个十分重要的属性。一个叫做 rect (rectangle 长方形的单词缩写)，这个属性描述了这个插件在什么位置扫描到了二维码，另外一个属性就是 text，也就是这个图片上隐藏的字符串地址。
    
    

    
    


12. 
    

    这里我们再讲解一下 rect 属性，因为后面的功能需要你对这个属性有比较清晰的理解。我们对比一个现实世界的例子。当你掏出手机扫描二维码的时候，往往并不会正好对准一个二维码的图片，或者会遇到一个图片中存在两个二维码的情况，如下图：
    
    

    
    


13. 
    

    这个 qr-scanner 插件会帮你把二维码所在整张图片的相对位置告诉你，因为这个插件每次调用 scan 函数只会返回一次结果。并不是说图片上有两个二维码，它的识别结果就会有两个，所以说这个 qr-scanner 插件的识别效果也并不是百分之一百准确的。

    
    

四. 理清思路

1. 
   

   说了这么多，那么这个 rect 我们该如何利用起来呢？别着急，我们先理清思路再动手写代码，到了目前这一步会出现两种情况。
   
   

   
   


2. 
   

   第一种是图片压根就没有二维码，这个简单，提示用户重新放置图片即可。

   
   


3. 
   

   关键点就在于第二张情况，当图片上扫码到存在一个二维码后，我们该如何判断是否存在第二个或多个维码呢？
   
   

   
   


4. 
   

   我们看一下微信的实现效果，当只有一张二维码的时候，它会直接跳转，当有多个二维码的时候，它会将整个页面暂停，并且提示用户有两张二维码，请点击选择一个进行跳转。
   
   

   
   


5. 
   

   但是我们上面提到了，scan 函数每次只会扫描一次图片，返回一个识别结果，它并不能准确知道图片上到底有几个二维码。那放到现实生活我们会怎么做呢？
   

   
   


6. 
   

   举个例子，假如我们现在掏出手机扫一扫的功能，现在给你的图片上有两个二维码，但是我明确的知道我就想扫第二个，你会怎么做？
   
   

   
   


7. 
   

   这不是很简单的道理吗？我拿手挡住第一个二维码不就可以了吗？
   
   

   
   


8. 
   

   那么利用同样的思路，我们可以再扫描到一张二维码的时候，想办法把当前识别到的这个二维码位置给遮挡住，然后将被遮挡后的照片传递给 scan 函数再次扫描。

   
   


9. 
   

   那么整个过程就是，我们首先将完整的照片传给 scan，然后 scan 觉得第一张二维码比较帅，就先识别了它。(tips: 这里需要提醒一下，scan 有时候会觉得第二张二维码比较帅，那我就识别第二张二维码，要注意的它的顺序性是随机的)
   
   

   
   


10. 
    

    然后我们想办法盖上遮挡物，然后将这个图片传给 scan，让它再次确认是否有第二个二维码。
    
    

    
    


11. 
    

    在哪覆盖？还记不记 rect 属性保留有这个二维码的位置信息？现在的问题就转变为如何覆盖了？

    
    


12. 
    

    这里需要用到 canvas 元素的一丢丢基础知识，这是 mdn canvas 基础知识的介绍，十分简单的就画出了一个绿色长方体。
    
    
    
    ctx.filleRect可以接收四个参数，分别是相对于画布起始轴的 x 和 y 的距离。
    
    简单来讲就可以理解为每一个 canvas 就相当于一个独立的 HTML 文件，也有自己的独立坐标系系统，x，y 就相当于 margin，至于后面两个参数，其实就代表着你要画的长方形的宽度和高度。
    

    
    

13.那这不巧了吗，scan 的返回值 rect 恰好就有这几个值。

14. 话不多说，马上开始实践。⛽️

五. 处理存在多张二维码的图片

1. 
   

   注意： 以下内容我统一选用从本地照片上传作为演示，从摄像头获取图片是同样的道理，详细介绍请移步 🎁前端如何打开摄像头拍照。在下面的讲解过程，我会默认你已经阅读了前置知识。

   
   


2. 
   

   这里我就继续沿用之前提到的图片，我将他们拼接到了一张图片上。
   
   

   
   


3. 
   

   下面应该是你目前从本地选择二维码图片识别的代码。
   

   
   

   async function getImageFromLocal(e: Event) {
   
     const inputEl = e.target as HTMLInputElement;
   
     if (!inputEl) return;
   
     if (!inputEl.files?.length) return;
   
     const image = inputEl.files[0];
   
     const url = URL.createObjectURL(image);
   
     src.value = url;
   
     const result = await scan(imgEl.value!);
   
     console.log("result", result);
   
   }
   
   

   
   


4. 
   

   接下来我们需要先创建一个 canvas 来将当前的照片拷贝到画布上，然后准备利用得到的 rect 信息在这个 canvas 元素上绘画。
   
   

   
   


5. 
   

   为了方便展示，我调用 appendChildren 方法将这个 canvas 元素打印到了界面上。
   
   

   
   


6. 
   

   然后用 result 中 rect 的坐标和宽度信息，去调用我们提到的 canvas 的 fillStyle fillRect 方法。
   
   
   
   下面是目前实现的效果:
   
   

   
   


7. 
   

   注意：scan 函数不仅仅可以接受 imgElment 作为扫描的参数，它还可以接受 canvas 元素作为扫描的参数。聪明的你看到这里，或许已经猜到我们下一步准备做什么了。

   
   


8. 
   

   那么此时我们就可以将这个已经被黑色涂鸦覆盖过的 canvas 进行二次扫描。(暂时不要考虑代码的优雅性，这里只是更清晰的说明我们在干什么，之后我们会封装几个方法，然后整理一下代码)
   
   
   
   让我们再看一下效果:
   
   

   
   


9. 
   

   通过多次重复上面的操作，就可以将图片上所有的二维码都尽量识别出来。
   
   
   
   现在实现的效果:
   
   
   
   同时图片上相对应的识别内容也全都被正确的被获取到了。
   
   

   
   


10. 
    

    此时我们创建一个 Map 来保存这些数据。Map 的 key 就是 text ，对应的 value 就是 rect 坐标信息。
    
    
    
    

    
    

六. 弹出可以点击的小蓝块

1. 
   

   有了坐标信息和位置信息，并且我们的 canvas 和 img 元素的坐标轴系统是一一对应的，那么我们就可以写一个函数来遍历这个 resultMap，然后根据位置信息在 img 元素所在的 div 上打印出我们想要的样式。

   
   


2. 
   

   首先在 img 元素外面包一层 div，打上 ref 叫做 imgWrapper 。因为之后我们要用它当作小蓝块的定位元素，所以先设置 position:relative。
   
   

   
   


3. 
   

   绘画代码如下，都是基础的方法，不再过多赘述。

   
   

   //多个二维码时添加动态小蓝点
   
   function draw() {
   
     resultMap.forEach((rect, link) => {
   
   if (!imgWrapper.value) return;
   
   const dom = document.createElement("div");
   
   const { x, y, width, height } = rect;
   
   const _x = (x || 0) + width / 2 - 20;
   
   const _y = (y || 0) + height / 2 - 20;
   
   dom.className = "blue-chunk";
   
   dom.style.width = "40px";
   
   dom.style.height = "40px";
   
   dom.style.background = "#2ec1cc";
   
   dom.style.position = "absolute";
   
   dom.style.zIndex = "9999999";
   
   dom.style.top = _y + "px";
   
   dom.style.left = _x + "px";
   
   dom.style.color = "#fff";
   
   dom.style.textAlign = "center";
   
   dom.style.borderRadius = "100px";
   
   dom.style.borderBlockColor = "#fff";
   
   dom.style.borderColor = "unset";
   
   dom.style.borderRightStyle = "solid";
   
   dom.style.borderWidth = "3px";
   
   dom.style.animation = "scale-animation 2s infinite";
   
   dom.addEventListener("click", () => {
   
     console.log(link);
   
   });
   
   imgWrapper.value.appendChild(dom);
   
     });
   
   }
   
   

   
   


4. 
   

   然后再 for 循环以后开始绘画小蓝块。
   
   

   
   


5. 
   

   让我们预览一下现在的效果:
   
   

   
   


6. 
   

   让我们测试一下相对应的点击事件
   
   

   
   

七. 源码

八.总结

本篇文章的关键点就是讲解了我在实现处理多张二维码的场景时的思路，利用 canvas 遮挡识别过的二维码这个思路是pbk-bin大佬最先想到的，在实现这个需求以后还是很感叹这个思路的巧妙。👏

再次特别感谢pbk-bin🎁～

如果文章对你有帮助，不妨赠人玫瑰，手有余香，预计将会在下篇更新较为完整的微信扫一扫界面和功能。

在我的mall电商实战项目中，有着从商品加入购物车到订单支付成功的一整套功能，这套功能的设计与实现对于有购物需求的网站来说，应该是一套通用设计了。今天给大家介绍下这套功能设计，涵盖购物车、生成确认单、生成订单、取消订单以及支付成功回调等内容，希望对大家有所帮助！

mall项目简介

这里还是简单介绍下mall项目吧，mall项目是一套基于 SpringBoot + Vue + uni-app 的电商系统（Github标星60K），采用Docker容器化部署。包括前台商城项目和后台管理系统，能支持完整的订单流程！涵盖商品、订单、购物车、权限、优惠券、会员、支付等功能，功能很强大！

• 项目地址：github.com/macrozheng/…


• 官方文档：http://www.macrozheng.com

后台管理系统演示

前台商城项目演示

功能设计

这里介绍下从商品加入购物车到订单支付成功的整个流程，涵盖流程的示意图和效果图。

流程示意图

以下是从商品加入购物车到订单支付成功的流程图。

流程效果图

以下是从商品加入购物车到订单支付成功的效果图，可以对照上面的流程示意图查看。

数据库设计

为了支持以上购物流程，整个订单模块的数据库设计如下。

设计要点

接下来介绍下整个购物流程中的一些设计要点，涵盖加入购物车、生成确认单、生成订单、取消订单以及支付成功回调等内容。

加入购物车

功能逻辑

用户将商品加入购物车后，可以在购物车中查看到商品。购物车的主要功能就是存储用户选择的商品信息及计算购物车中商品的优惠。

购物车优惠计算流程

相关注意点

• 购物车中商品优惠金额不会在购物车中体现，要在生成确认单时才会体现；


• 由于商品优惠都是以商品为单位来设计的，并不是以sku为单位设计的，所以必须以商品为单位来计算商品优惠；


• 代码实现逻辑可以参考mall项目中OmsPromotionServiceImpl类的calcCartPromotion方法。

生成确认单

功能逻辑

用户在购物车页面点击去结算后进入生成确认单页面。确认单主要用于用户确认下单的商品信息、优惠信息、价格信息，以及选择收货地址、选择优惠券和使用积分。

生成确认单流程

相关注意点

• 总金额的计算：购物车中所有商品的总价；


• 活动优惠的计算：购物车中所有商品的优惠金额累加；


• 应付金额的计算：应付金额=总金额-活动优惠；


• 代码实现逻辑可以参考mall项目中OmsPortalOrderServiceImpl类的generateConfirmOrder方法。

生成订单

功能逻辑

用户在生成确认单页面点击提交订单后生成订单，可以从订单详情页查看。生成订单操作主要对购物车中信息进行处理，综合下单用户的信息来生成订单。

下单流程

相关注意点

• 
  

  库存的锁定：库存从获取购物车优惠信息时就已经从pms_sku_stock表中查询出来了，lock_stock字段表示锁定库存的数量，会员看到的商品数量为真实库存减去锁定库存；

  
  


• 
  

  优惠券分解金额的处理：对全场通用、指定分类、指定商品的优惠券分别进行分解金额的计算：

  
  
  
  
  • 全场通用：购物车中所有下单商品进行均摊；
  
  
  • 指定分类：购物车中对应分类的商品进行均摊；
  
  
  • 指定商品：购物车中包含的指定商品进行均摊。
  
  
  
  


• 
  

  订单中每个商品的实际支付金额计算：原价-促销优惠-优惠券抵扣-积分抵扣，促销优惠就是购物车计算优惠流程中计算出来的优惠金额；

  
  


• 
  

  订单号的生成：使用Redis来生成，生成规则:8位日期+2位平台号码+2位支付方式+6位以上自增id；

  
  


• 
  

  优惠券使用完成后需要修改优惠券的使用状态；

  
  


• 
  

  代码实现逻辑可以参考mall项目中OmsPortalOrderServiceImpl类的generateOrder方法。

  
  

取消订单

功能逻辑

订单生成之后还需开启一个延时任务来取消超时的订单，用户也可以在订单未支付的情况下直接取消订单。

订单取消流程

相关注意点

• 代码实现逻辑可以参考mall项目中OmsPortalOrderServiceImpl类的cancelOrder方法。

支付成功回调

功能逻辑

前台用户订单支付完成后，第三方支付平台需要回调支付成功接口。

支付成功回调流程

相关注意点

• 代码实现逻辑可以参考mall项目中OmsPortalOrderServiceImpl类的paySuccess方法。

总结

今天给大家介绍了mall项目中整套购物流程的功能设计，其实对于很多网站来说都需要这么一套功能，说它是通用功能也不为过。从本文中大家可以看到，mall项目的整套购物流程设计的还是比较严谨的，考虑到了方方面面，如果你对mall项目整套购物流程实现感兴趣的话可以学习下mall项目的代码。

项目源码地址

github.com/macrozheng/…

一、Java掉到历史最低

从2023年6月开始Java掉到历史最低排到第4位

2023年10月tiobe编程语言排行榜，Java仍然还是排到了第4位，C# 和 Java 之间的差距从未如此之小。

top 10 编程语言1988年~2023年历史排名

引用tiobe官网上TIOBE Software 首席执行官的话：

10 月头条：C# 越来越接近 Java

C# 和 Java 之间的差距从未如此之小。目前，差距仅为 1.2%，如果保持这种趋势，C# 将在大约 2 个月的时间内超越 Java。在所有编程语言中，Java 的跌幅最大，为 -3.92%，C# 的涨幅最大，为 +3.29%（每年）。这两种语言一直在相似的领域中使用，因此二十多年来一直是竞争对手。Java 受欢迎程度下降的主要原因是 Oracle 在 Java 8 之后决定引入付费许可模式。微软在 C# 上采取了相反的做法。过去，C#只能作为商业工具Visual Studio的一部分。如今，C# 是免费且开源的，受到许多开发人员的欢迎。Java 的衰落还有其他原因。首先，Java 语言的定义在过去几年中没有发生太大变化，而其完全兼容的直接竞争对手 Kotlin 更易于使用且免费。——TIOBE Software 首席执行官 Paul Jansen

二、编程语言排行榜

编程语言排行榜是一种用来衡量编程语言的流行度或受欢迎程度的指标，它通常会根据一些数据或标准来对编程语言进行排序和评价。不同的编程语言排行榜可能会有不同的数据来源、计算方法和评估标准，因此它们的结果也可能会有所差异。

目前，最知名和权威的编程语言排行榜之一是 TIOBE 编程社区指数，它由成立于 2000 年 10 月位于荷兰埃因霍温的 TIOBE Software BV 公司创建和维护。TIOBE 编程社区指数通过对网络搜索引擎中涉及编程语言的查询结果数量进行计算，来衡量各种编程语言的受欢迎程度。TIOBE 编程社区指数每个月都会更新一次，并且每年还会评选出一门年度编程语言，表示该门语言在当年的排名中上升幅度最大。除了 TIOBE 编程社区指数之外，还有一些其他的编程语言排行榜，以下是列举的一些编程语言排行榜。

1、TIOBE编程语言排行榜

TIOBE是一家荷兰的编程软件质量评估公司，每月发布一份编程语言排行榜。它使用搜索引擎查询结果、开发者社区活跃度和其他指标来评估编程语言的受欢迎程度。

2023年10月TIOBE编程语言排行榜

2、Stack Overflow开发者调查

Stack Overflow每年进行一次开发者调查，其中包括有关最受欢迎编程语言的信息。Stack Overflow 开发者调查是最权威的编程语言排行榜之一，该调查可以反映全球开发者对编程语言的喜好和使用情况。在选择编程语言时，可以参考该调查的结果，但也需要根据自己的实际需求和开发环境进行综合考虑。

连续三年最受欢迎编程语言排名，可以明显的看出Java的占比在逐年的降低

3、GitHub编程语言趋势榜

GitHub提供了一个编程语言趋势页面，显示了开发者在GitHub上使用的编程语言趋势。虽然这不是正式的排行榜，但反映了实际的开发趋势。

GitHub在趋势榜比较前的基本者是Python或Go的项目

GitHub官网已经去掉了top的排名榜只保留了趋势榜，由一些GitHub的爱好者和贡献者创建和维护的www.github-zh.com的GitHub中文社区网站，是非官方github网站，它旨在为中文用户提供GitHub的相关资讯、教程、交流和协作平台，还可以查到Github项目排行榜。

三、展望Java

可以看到各种编程语言排行榜的数据，虽然会存在片面的情况，但也大体能表现出Java的地位在下降，遥想当年Java是排行榜霸榜老大哥。

虽然Java明显下降，或许正如TIOBE首席执行官说的“Java 受欢迎程度下降的主要原因是 Oracle 在 Java 8 之后决定引入付费许可模式。微软在 C# 上采取了相反的做法。”在这个开放的世界里真正的开源而不是利用开源来测试付费项目才能真正的让大家推崇。

Java的许可模式变化导致用户流失。自从Java 8之后，甲骨文公司决定对Java的商业使用收取费用，这使得一些企业和开发者转向其他免费或开源的语言，如C#、Python等 。

Java的竞争对手不断发展和创新，提供了更多的选择和优势。例如，C#在.NET平台上不断完善和扩展，支持跨平台、混合开发、WebAssembly等技术 ；Python在数据科学、人工智能、Web开发等领域有着广泛的应用和生态 ；Kotlin作为Android官方推荐的语言，兼容Java，并提供了更多的语法糖和功能 。

Java虽然在编程语言排行榜上有所下降，但并不意味着Java就没有前途和价值。Java仍然是一门成熟、稳定、高效、跨平台的语言，拥有庞大的用户群和丰富的生态系统。Oracle作为Mysql、Java等重量级项目的拥有者，也在不断地改进和创新Java，让Java能够适应时代的变化和需求。包括Java 17的免费、Kafka/Spring Boot新版本最低的Java版本为17、Java 21引入协程等，都是Oracle在努力让Java保持竞争力和活力的例证 。

未来在不断的变化，说不定马斯克的美女机器人就真的造出来了。。。

当然，我们也不能忽视其他编程语言的发展和优势，我们应该保持开放和学习的心态，了解不同语言的特点和适用场景，选择最合适的语言来解决问题。编程语言只是工具，重要的是我们能够用它们创造出有价值的产品和服务。

什么，鸭子还能调试代码？什么神奇的鸭子啊。

当然不是了，是鸭子帮你调试，那好像也有点儿厉害。

初听感觉是傻子，再听感觉是玄学。

什么是小黄鸭调试法

当然不是鸭子调试代码了，也不是鸭子帮你调试，其实还是靠你自己的。

小黄鸭调试法（Rubber Duck Debugging）是一种常用于解决编程问题的技巧，不是代码技术层面的技巧。

大致的调试过程是这样的：

1. 首先你写好了代码，或者有些逻辑一直写不出来，然后很有自信或者不自信；


2. 然后你找到一只鸭子，玩具鸭子，或者任意一个电脑旁边的物件；


3. 最后，把你的代码的逻辑尽量详细的讲个上一步找到的对象，比如一只玩具鸭子；


4. 通过讲解的过程，你很有可能发现代码上的漏洞，有时候还能发现隐藏的漏洞；

你还可以拉过旁边的人，对着他讲，前提是保证别人不会打你。

这个过程更像是一种review的过程，而且是那种非常具体的review，只不过是自己 review 自己的代码或逻辑。

它的核心是通过将问题或逻辑用语言描述出来，在这个过程中找到解决问题的线索。

虽然这个方法听起来可能有点奇怪，但它在实际中确实能够帮助很多人解决问题。解释问题的过程可能会强迫你慢下来，更仔细地思考，从而找到之前忽略的问题点。

另外，在进行这一些列操作的过程中，尽量保证周围没有人，不然别人可能觉得你是个傻子。

当然了，这个操作你可以在心里默默进行，也是一样的效果。

各位平时工作中有没有遇见过有人使用小黄鸭调试法呢？我看到这个概念的时候想了一下，好像还真碰到过。之前有同事在那儿写代码，一边写嘴里一边叨咕，也不知道在说啥，还开玩笑说这是不是你们这个星座的特质（某个星座）。

现在想想，人家当时用的是不是小黄鸭调试法呀，只恨当初孤陋寡闻，没有问清楚啊。

内在原理

小黄鸭调试法的内在原理其实是涉及到认知心理学中的一些概念的，并不真的是玄学和沙雕行为。

认知外部化

这是小黄鸭调试法的核心。当你将问题从内心中的思考状态转移到外部表达时，你会更加仔细地思考问题。解释问题需要你将问题的细节和步骤以清晰的语言描述出来，这个过程可以帮助你整理思路，更好地理解问题。

问题表达

描述问题的过程可以迫使你更具体地考虑问题。将问题分解为不同的部分，逐步地解释代码的执行流程，有助于你更好地理解代码中可能的缺陷或错误。

观察问题:

当你通过语言表达问题时，可能会注意到之前忽略的细节。这可能是因为你在描述问题时需要更仔细地审查代码和逻辑，从而让你注意到潜在的问题点。

听觉和口头处理

讲述问题的过程涉及到将问题从书面表达转化为口头表达。听觉和口头处理可以帮助你以不同的方式来理解问题，可能会在你的大脑中触发新的洞察力。

认知切换:

与代码一起工作时，你可能会一直陷入相同的思维模式中，难以看到问题。通过将问题从代码中抽离出来，并通过描述来关注它，你会进行认知切换，从而能够以不同的角度审视问题。

总结起来其实很简单，如果一个知识点你理解了，你一定能给别人讲出来，或者写出来，而且别人能够理解。如果你在讲的时候发现有模棱两可的地方，那说明你还没有百分百理解。

就像我们平时写技术文章一样，有时候碰到一些细节写半天也写不清楚，那就是还没有完全理解。

前段时间看了实习生的新项目，发现他启动不了项目，因为node版本太低，我让他去用nvm来管理node的版本，然后看到他切换版本的时候是这样的，先用nvm下载安装目标的node版本，然后在把安装好的node版本替换掉原先的node路径下的node_modules，而不是用命令行进行版本切换，才发现原来他使用nvm来切换node版本虽然显示切换成功，但全局的node版本一直是不变的，所以才用文件覆盖的方式强制进行解决，对于这个问题进行解决并且梳理

可以直接跳到第四步查看解决方案

1️⃣ 安装nvm

where nvm

找不到nvm路径的朋友可以用这个命令来找到nvm的安装路径，默认的安装路径都是差不多的

2️⃣ 查看目前node版本

可以看到目前的版本是node V16.14.2

3️⃣ nvm安装目标node版本

nvm的主要作用就是用来切换node的版本，为什么要切换node的版本，就是因为你的当前node版本和你要启动的项目不兼容，有两种可能，要么是你的项目太旧，你的node版本相对来说比较高，需要用到向下兼容；另外一种可能就是你项目用到的node比较新，你需要进行升级

先安装需要安装的目标版本，用isntall来安装你需要的对应node版本

回到你的nvm安装路径，就可以看到你已经安装的各种版本的node文件夹

当然也可以用命令行

nvm list

4️⃣ nvm切换到目标node版本

切换到目标node版本使用nvm use

nvm use

查看目前nvm安装了哪些版本 然后use来进行切换

到切换的时候发现了问题，这里无论怎么切换，node的版本依然不会变

可以看到我用的use来切换到15的版本，但是再次查看nvm的node历史版本，可以看到还是位于16.14.2的node版本，明明就是这么顺利的问题，出了一个让人摸不到头脑的事情

5️⃣寻找问题

既然nvm切换版本已经成功，那么为什么node版本不会变，有没有可能根本改的不是同一个node，或者是存在两个node，直到我打开环境变量一看，为啥会存在两个node的路径，可能的原因就是之前的node版本没有删除，node -v一直输出的是安装前的node

原来已经安装了一个node的，全局的node指向的node路径和nvm切换node的路径是不一样的

nvm切换的node是基于他文件夹中的nodejs

点进去看你会发现他也是有一个node.exe的程序的，所以问题是已经找到的了，目前系统上出现了两个node，并且nvm切换的node版本并不是全局的node，因为环境变量已经指向了旧的node，他的版本不会改变，那么nvm去怎么切换都是没有用的

6️⃣解决方案

看了网上的一些解决方案都是要在nvm中新建两个文件夹的方式来解决，但是其实直接把nodejs删除也是一个很直接的办法，先通过where node找到当前的node的安装目录，直接进行删除

最后是通过把另外一个目录的node进行删除，重新看一下node的安装路径，也就是重新执行一下 where node

可以看到在nvm配置正确的情况下是能直接指向nvm下的node的

最后重新切换一下node的版本，也就是上文的操作

PS

我指的手动切换是nvm下载node版本之后手动去替换node_modules，原来大家觉得用nvm use也是手动替换（确实是我的问题），经过评论区广大jym指正，可以尝试一下volta这个工具来进行切换版本，真正做到不用手动替换，后续我会亲自去体验一下并且发文，感谢评论区小伙伴

🙏 感谢您花时间阅读这篇文章！如果觉得有趣或有收获，请关注我的更新，给个喜欢和分享。您的支持是我写作的最大动力！

前言

最近项目需要封装一个图片加载组件，boss让我们实现类似电报的那种效果，直接上图：

就像把大象装入冰箱一样，图片加载拢共有三种状态：loading、success、fail。

首先是loading，电报的实现效果是底部展示blur image, 上面盖了个progress indicator。blur image有三方库可以实现：flutter_thumbhash | Flutter Package (pub.dev),但是这个库有个bug: 它使用到了MemoryImage, 并且MemoryImage的bytes参数每次都是重新生成的，因而无法使用缓存。所以上面的progress刷新时底部的blur image都会不停闪烁。

//MemoryImage

@override

bool operator ==(Object other) {

    if (other.runtimeType != runtimeType) {

      return false;

    }

    return other is MemoryImage

        && other.bytes == bytes

        && other.scale == scale;

}



@override

int get hashCode => Object.hash(bytes.hashCode, scale);

笔者覆写了equals和hashcode方法，通过listEquals方法来比较bytes，考虑到thumb_hash一般数据量都比较小估计不会有性能问题。
也有人给了个一次性比较8个byte的算法【StackOverflow摘抄】😄

/// Compares two [Uint8List]s by comparing 8 bytes at a time.

bool memEquals(Uint8List bytes1, Uint8List bytes2) {

  if (identical(bytes1, bytes2)) {

    return true;

  }



  if (bytes1.lengthInBytes != bytes2.lengthInBytes) {

    return false;

  }



  // Treat the original byte lists as lists of 8-byte words.

  var numWords = bytes1.lengthInBytes ~/ 8;

  var words1 = bytes1.buffer.asUint64List(0, numWords);

  var words2 = bytes2.buffer.asUint64List(0, numWords);



  for (var i = 0; i < words1.length; i += 1) {

    if (words1[i] != words2[i]) {

      return false;

    }

  }



  // Compare any remaining bytes.

  for (var i = words1.lengthInBytes; i < bytes1.lengthInBytes; i += 1) {

    if (bytes1[i] != bytes2[i]) {

      return false;

    }

  }



  return true;

}

图片加载和取消重试

电报在loading的时候可以手动取消下载，这个在Flutter官方Image组件和cached_network_iamge组件都是不支持的，因为在设计者看来既然图片加载失败了，那重试也肯定还是失败(By design)。
extended_image库对cancel和retry做了支持，这里要给作者点赞👍🏻

取消加载

加载图片是通过官方http库来实现的， 核心逻辑是：

final HttpClientRequest request = await httpClient.getUrl(resolved);

headers?.forEach((String name, String value) {

  request.headers.add(name, value);

});

final HttpClientResponse response = await request.close();

if (timeLimit != null) {

  response.timeout(

    timeLimit!,

  );

}

return response;

返回的response是个Stream对象,通过它来获取图片数据

final Uint8List bytes = await consolidateHttpClientResponseBytes(

        response,

        onBytesReceived: chunkEvents != null

            ? (int cumulative, int? total) {

                chunkEvents.add(ImageChunkEvent(

                  cumulativeBytesLoaded: cumulative,

                  expectedTotalBytes: total,

                ));

              }

            : null,

      );

图片加载进度就是通过ImageChunkEvent来获取的，cumulative代表当前已加载的长度，total是总长度，所有图片加载库都是通过它来显示进度的。所以，如何取消呢？这里就需要用到Flutter异步的一个API了：

Future.any(<Future<T>>[Future cancelTokenFuture, Future<Uint8List> imageLoadingFuture])

在加载的时候除了加载图片数据的Future，我们再额外生成一个Future，当需要取消加载的时候只需要后者抛出Error那加载就会直接终止，extended_image就是这么做的：

class CancellationTokenSource {

  CancellationTokenSource._();

  

  static Future<T> register<T>(

      CancellationToken? cancelToken, Future<T> future) {

    if (cancelToken != null && !cancelToken.isCanceled) {

      final Completer<T> completer = Completer<T>();

      cancelToken._addCompleter(completer);

      

      ///CancellationToken负责管理cancel completer

      return Future.any(<Future<T>>[completer.future, future])

          .then<T>((T result) async {

        cancelToken._removeCompleter(completer);

        return result;

      }).catchError((Object error) {

        cancelToken._removeCompleter(completer);

        throw error;

      });

    } else {

      return future;

    }

  }

}

这种取消机制有个问题：虽然上层会捕获抛出的异常终止加载，但是网络请求还是会继续下去直到加载完图片所有数据，我于是翻看了Flutter的API，发现上面提到的解析HttpResponse的方法consolidateHttpClientResponseBytes有个注释：

/// The `onBytesReceived` callback, if specified, will be invoked for every

/// chunk of bytes that is received while consolidating the response bytes.

/// If the callback throws an error, processing of the response will halt, and

/// the returned future will complete with the error that was thrown by the

/// callback. For more information on how to interpret the parameters to the

/// callback, see the documentation on [BytesReceivedCallback].

即onBytesReceived方法如果抛出异常那么就会终止数据传输，所以可以根据chunkEvents是否alive来判断是否需要继续传输，如果不需要就直接抛出异常，从而终止http请求。

重试

图片加载有两种重试：第一种是自动重试，笔者遇到了一个connection closed before full header was received错误，而且是高概率出现，目前没有好的解决办法，加上自动重试机制后好了很多。

第二种就是手动重试，自动重试达到阈值后还是失败，手动触发加载。我这里主要讲第二种，在电报里的展示效果是这样：

这里卡了我好久，主要是我对Flutter的ImageCache了解不深入导致的，首先看几个问题：

1. 页面有一张图片加载失败，退出页面重新进来图片会自动重新加载吗？

答案是不一定，Flutter图片缓存存储的是ImageStreamController对象，这个对象里有一个FlutterErrorDetails? _currentError;属性，当加载图片失败后_currentError会被赋值，所以退出后重进页面虽然会导致页面重新加载，但是获取到的缓存对象有Error，那就会直接进入fail状态。
缓存的清理是个很复杂的问题， ImageStreamCompleter的清理逻辑主要靠两个属性：_listeners和_keepAliveHandles：

List<ImageStreamListener> _listeners = [];



@mustCallSuper

void _maybeDispose() {

    if (!_hadAtLeastOneListener || _disposed || _listeners.isNotEmpty || _keepAliveHandles != 0) {

      return;

    }



    _currentImage?.dispose();

    _currentImage = null;

    _disposed = true;

}

_listerners的add和remove时机和Image组件有关

/// image.dart

/// 加载图片

void _resolveImage() {

    ......

    final ImageStream newStream =

      provider.resolve(createLocalImageConfiguration(

        context,

        size: widget.width != null && widget.height != null ? Size(widget.width!, widget.height!) : null,

      ));

    _updateSourceStream(newStream);

}



void _updateSourceStream(ImageStream newStream) {

    ......

    /// 向ImageStreamCompleter注册Listener

    _imageStream!.addListener(_getListener());

  }

既然有了_listeners那为什么还需要_keepAliveHandles属性呢，原因就是在image组件所在页面不在前台时会移除注册的listerner，如果没有_keepAliveHandles属性那缓存可能会被错误清理：

@override

void didChangeDependencies() {

    _updateInvertColors();

    _resolveImage();



    if (TickerMode.of(context)) {

       ///页面在前台的时候获取最新的ImageStreamCompleter对象

      _listenToStream();

    } else {

      ///页面不在前台移除Listener

      _stopListeningToStream(keepStreamAlive: true);

    }

    super.didChangeDependencies();

}

回到最开始的问题：如果加载失败的图片组件在其他页面不存在，那image组件dispose的时候就会清理掉缓存，第二次进入该页面的时候就会重新加载。反之，如果其他页面也在使用该缓存，那二次进入的时候就会直接fail。

一个很好玩的现象是，假如两个页面在加载同一张图片，那么其中一个页面图片加载失败另外一个页面也会同步失败。

2. 判定加载的是同一张图片

这里的相同很重要，因为它决定了ImageCache的存储，比如笔者自定义一个NetworkImage:

class _NetworkImage extends ImageProvider<_NetworkImage> {



  _NetworkImage(this.url);



  final String url;

  

  @override

  ImageStreamCompleter loadImage(NetworkImage key, ImageDecoderCallback decode);



  @override

  Future<ExtendedNetworkImageProvider> obtainKey();

}

obtainKey一般都会返回SynchronousFuture<_NetworkImage>(this)，它代表的是ImageCache使用的键，ImageCache判断当前是否存在缓存的时候会拿Key和缓存的所有键进行比对，这个时候equals和hashcode就开始起作用了：

@override

bool operator ==(Object other) {

    if (other.runtimeType != runtimeType) {

      return false;

    }

    return other is _NetworkImage

        && other.url == url;

}



@override

int get hashCode => Object.hash(url);

因为我们需要支持取消加载，所以最初我考虑加上cancel token到相同逻辑的判定，但是这会导致同一张图片被不停重复加载，缓存完全失效。

为了解决上面的问题，我对ImageCache起了歪脑筋：能不能在没有加载成功的时候允许并行下载，但是只要有一张图片成功，那后续都可以复用缓存？
如果要实现这个效果，那就必须缓存下所有下载成功的ImageProvider或者对应的CancelToken。下载成功的监听好办，在MultiFrameImageStreamCompleter加个监听就完事。难的是缓存消除的时机判断，ImageCache的缓存机制很复杂(_pendingImages,_cacheImage,_liveImages)，并且没有缓存移除的回调。

最终，我放弃了这个方案，不把cancel token放入ImageProvider的比较逻辑中。

3. 实现图片重新加载

首先，我给封装的图片组件加了个reloadFlag参数，当需要重新加载的时候+1即可：

@override

void didUpdateWidget(OldWidget old) {

    if(old.reloadFlag != widget.reloadFlag) {

        _resolveImage();

    }

}

但是，这个时候不会起作用，因为之前失败的缓存没被清理，ImageProvider的evict方法可实现清理操作。

4. 多图状态管理

我在适配折叠屏的时候发现了一个场景：多页面下载相同图片时有时无法联动，首先看cancel:

• A页面加载图片时使用CancelToken A,新建缓存


• B页面使用CancelToken B, 复用缓存

B的CancelToken完全没用到，所以是cancel不了的。为了解决这个问题，我创建了一个CancelTokenManager，按需生成CancelToken，并在加载成功或失败时清理掉。

然后是重试，多图无法同时触发重试，虽然可以复用同一个ImageStreamCompleter对象，但ImageStream对象却是Image组件单独生成的，所以只能借助状态管理框架或者事件总线来实现同步刷新。

就业的”就“不是让你将就

  是不是大家常常听到家里人唠叨的一句话：“有工作就行了啊，别那么挑剔，你都这么大了，还指望着家里养着你啊” 。还是老师说：“我们要建立优先就业再择业的就业观，不能一直不去就业呀”什么的叭叭叭。

  其实某方面来说他们并没有说错，我们已经成年了，需要独立自主。在漂亮国，到了18岁好像都要分家了吧。不过我们在中国，中国的国情肯定和漂亮国不一样。除此之外中国家庭从小的哭穷式教育，估计让许多孩子都想自己经济独立吧。这个现象导致了大家认为有工作就行了，我管他什么工作呢。

  但是从自身职业发展来讲，这是对自己极其不负责的表现，往往许多人的第一份工作就决定了人生轨迹，不论是以后决定发展的城市，还是以后工作的方向，其实已经早已埋下种子。你说你可以换工作啊，可以跳槽啊，现实往往会打醒你，你以为你没了应届生身份，凭着你那不到一年的工作经验，人家企业看中你什么。所以我们要就业要为自己，同时也要为自己的未来负责，我们要慎之又慎。所以我们要就业不过的选择自己合适的就业不能盲目就业，家长的思想大部分过时了，停留在了上了大学就有好工作的时代。我们只能参照而不能按部就班，对于老师，大部分是为了提高学校就业率完成指标而已，不必要太大理会，当然和你关系好的老师除外，但是相反如果和你关系好他一定会不会让你草草就业的。

择业的”择“也别太择

钱多事少离家近，位高权重责任轻。睡觉睡到自然醒，数钱数到手抽筋。

  说完就业再谈谈择业，相信上面这句话大家都听过，这简直就是梦中情职，所以择业在我看来无非四种：离家近的、工资高的、自己感兴趣的、清闲的。这四种涵盖了大部分职业了吧。所以我们怎么择业，选择一个适合自己的职位对于未来发展是事半功倍的。

  大家选择职业的时候不知道是从哪方面来选择的，首先离家近，相信很多女生都是考虑这个优先吧，感觉男生就是喜欢仗剑走天涯那种🤣。然后考虑清闲的，想想你二十几岁的年龄你还要工作四五十年可能，选个清闲一点的职业不过分吧，最好就是考一个公务员事业编了，实在不行就去央企国企了，当然这种工作大家都想去，虽然工资不高但是福利好啊。再者就是兴趣了，把自己的兴趣培养成自己的职业也是可以的，大学就是很好的时间，选那种课比较少的专业，这里不得不再次吐槽大学课程的无用性。然后自己选一个自己喜欢的职业，比如摄影、博主什么的。不过当喜欢的事变成职业很多人也就不喜欢了，比如电竞职业选手他们天天十几个小时训练打游戏，他们下班还会想打游戏嘛🤣。就是坚持很重要。再再者，有的人说自己天生无感对什么都没兴趣，那么恭喜你和我一样🤣，就是什么的不是很感兴趣，也不讨厌，那么我建议搞钱，选个高薪的职业搞到足够的钱就退休了，当初就是看程序员薪资高入行了，对钱总感兴趣了吧。总而言之择业择业选择自己合适的再就业。

  鱼和熊掌不可兼得。选择离家近的就得忍受小镇的慢节奏，没有快速的地铁，没有好玩的游乐场，有的只是街坊邻居的互相寒暄，没有夜晚的灯红酒绿，只有晚上八九点就安静的大街。选择清闲的公务员，那么就要懂的人情世故，还有每个月几千块钱的工资。选择自己感兴趣的，那么就得忍受孤独，经得起自我怀疑要有坚定的勇气。高工资的不用多说了吧，996，007时间就是金钱，加班是常态，通宵也是偶尔。所以没有哪份职业好坏，选择自己合适的，加油奋斗吧！

离开北京是计划

2013年去的北京，至今整十年，来去匆匆。

几年前就计划好了，赶在孩子上幼儿园之前离开北京，选一个城市定居。

给孩子一个稳定的环境，在这儿上学成长，建立稳定的、属于他自己的朋友圈。人一生中最珍贵的友谊都是在年少无知、天真烂漫的时候建立的。

我们希望孩子从他有正式的社交关系开始-幼儿园阶段，尽早适应一个省市的教育理念和节奏，不要等到中小学、甚至高中阶段突然的打断孩子的节奏，插班到一个陌生的班级。他同时要面临环境和学业的压力，不是每个孩子都能很快调整过来的。

我自己小学阶段换了好几次学校，成绩的波动很明显，不希望孩子再面临同样的风险。

另一方面，基于我们年龄的考虑，也要尽快离开，岁数太大了，换城市跳槽不一定能找到合适的岗位。

19年，基于对移动端市场的悲观，我开始考虑换一个技术方向。2020年公司内转岗，开始从事图形相关技术开发，计划2023年离开北京，是考虑要留给自己3年的时间从零开始积累一个领域的技术。

来深圳市是意外

这几年一直在关注其他城市的"落户政策"、"互联网市场"、"房价"、"政府公共服务"。有几个城市，按优先级：杭州、广州、武汉、深圳。这些都是容易落户的城市，我们想尽快解决户口的困扰。

看几组数据：

可以看到，杭州的房价排在第6位，但是收入和工作机会排进前4，所以首选杭州，性价比之王。

广州的房价和工作收入都排第5，中策。

武汉的工作机会排进前10，但是房价在10名开外，而且老家在那边，占尽地利，下策。

深圳的房价高的吓人，和这个城市提供的医疗、教育太不匹配，下下策。

最后选择深圳是形势所逼，今年行情史上最差，外面的机会很少。我和老婆都有机会内部转岗到深圳，所以很快就决定了。

初识深圳

来之前做了基本的调研，深圳本科45岁以内 + 1个月社保可以落户。我公司在南山，老婆的在福田，落户只能先落到对应的区。

我提前来深圳，一个星期租好了房子，确定了幼儿园。

老婆步行15分钟到公司，孩子步行500米到幼儿园，我步行 + 地铁1小时到公司。

福田和南山的教育资源相对充足，有些中小学名校今年都招不满，租房也能上，比龙华、宝安、龙岗等区要好很多。

听朋友说，在龙华一个很差的公立小学1000个小孩报名，只有500个学位。

有不少房东愿意把学位给租户使用，办理起来也不麻烦，到社区录入租房信息即可。和北京一样，采取学区划分政策，按积分排名录取，非常好的学校也要摇号碰运气。

租房

中介小哥陪我看了三四天房子，把这一片小区都看了个遍。考虑近地铁、近幼儿园、有电梯、装修良好等因素。

我本来想砍200房租，中介说先砍400，不行再加。结果我说少400，房东直接说好。我原地愣住了，之前排练的戏份都用不上了，或许今年行情不好，租房市场也很冷淡吧。

小区后面是小山，比较安静。

深圳的很多小区里都有泳池

夜晚的深圳，高楼林立，给人一种压迫感，和天空格格不入。明亮的霓虹灯，和北京一样忙碌。

对教育的看法

幸运的人一生都被童年治愈，不幸的人一生都在治愈童年--阿德勒

身边的朋友，有不少对孩子上什么学校有点焦虑，因为教育和高考的压力，有好友极力劝阻我来深圳。我认为在能力的范围内尽力就好，坦然面对一切。

焦虑是对自己无能为力的事情心存妄念。 如果一个人能坦然面对结果，重视当下，不虚度每一分每一秒，人生就不应该有遗憾。人生是来看风景的，结局都是一把灰，躺在盒子里，所以不要太纠结一定要结果怎么样。

学校是培养能力的地方，学历决定一个人的下限，性格和价值观决定上限，你终究成要为你想成为的人，不应该在自我介绍时除了学历能拿出手，一无是处。

不少人不能接受孩子比自己差。可是并没有什么科学依据能证明下一代的基因一定优于上一代吧，或许他们只是不能接受孩子比他们差，他们没有面子，老无所依。我天资一般，我也非常能接受孩子天资平庸，这是上天的旨意。

有些父母根本没有做好家庭教育，试图通过卷学校、一次性的努力把培养的责任寄托于学校。挣钱是成就自己，陪伴是成就孩子，成功的父母居中取舍。

陪伴是最好的家庭教育，如果因为工作而疏忽了孩子，我认为这个家庭是失败的，失败的家庭教育会导致家庭后半生矛盾重重，断送了全家人的幸福。

一个人缺少父爱，就缺少勇敢和力量，缺少母爱就缺少细腻与温和，孩子的性格很容易不健全。除非他自己很有天赋，能自己走出童年的阴影。

因为他长大面对的社会关系是复杂的，他需要在性格层面能融入不同的群体。性格不健全的孩子更容易走向偏激、自私、虚伪、或者懦弱，很多心理学家都是自我治疗的过程中，成为心理学大师。

一个人的一生中，学历不好带来的困扰是非常局部的，但是性格带来的问题将困扰其一生，包括工作、交朋结友、娶妻生子，并且还会传染给下一代。

榜样是最好的教育方法，没有人会喜欢听别人讲大道理，言传不如身教。有些人自己过的很可怜，拼命去鸡娃，那不是培养孩子，那是转移压力，过度投资，有赌棍的嫌疑。你自己过的很苦逼，你如何能说服孩子人生的意义是幸福？鸡娃的尽头是下一代鸡娃。

你只有自己充满能量，积极面对人生，你的孩子才会乐观向上；你只有自己持续的阅读、成长，你的孩子才会心悦诚服的学习；你只有自己做到追求卓越，你的孩子才会把优秀当成习惯。

不要给孩子传递一种信号，人生是苦的，要示范幸福的能力，培养孩子积极地入世观。

2023.9.29中秋节早晨，4个月的宝宝在旁边陪伴着我，记录了28岁一路以来的变化与成长。

关于我

5年前端，现定级为中级前端工程师，有一个很可爱的儿子，小名甜筒🍦，同时还有一个富有智慧的妻子，没错！我用了智慧一词，因为她在能力、为人处事、情绪管控以及子女教育方面优于一般人，这是我的荣幸~

职业发展

关于中级这个头衔，我并不是很满意，在我的规划中，五年作为一个成长的阶梯，仅仅在前端这个领域，应该是要成长为高级开发，毕竟人生能有几个黄金五年呢？

晋升

在我前三年的工作经历中，的确走了一些坎坷，在第二年的时候就已经担任了某私企前端leader的角色，在技术并不是特别拔尖的情况下去做管理工作，属实有点困难，毕竟要兼顾的东西多了，难免有些手忙脚乱，加上当时作为一个技术人的性格胜任这份工作，在沟通上还是吃了蛮多亏，说白了就是需要情商，即做事让人感动，说话让人舒服。关于前半句，我是感动了自己，而后半句呢，虽然没有拉仇恨，但还是差强人意！

感悟

当然了，犯错伴随着成长，在我看来这个过程中最大的收获大于自己的情绪管理和思维方式提升。

作为技术人内敛的性格在遇到问题时容易产生自我怀疑，内耗随之产生，而《非暴露沟通》给了我很多启发，不管是在工作或者家庭关系处理中增加了不少润滑油，以至于后面认识我的朋友给我贴了标签：情绪稳定、逆商高！

其实，更大的成长在于第四年，2022~2023年经历了父亲病痛、职业生涯选择和组建家庭。

在2022年初，我背上了房贷，那时候的薪资不高，只有16k左右，而房贷是一个非常吉利的数字：6666，与此同时父亲生病几个月期间让我意识到自己抗风险能力太低，加上自己除了在技术领域关注甚多，对于其他方面一窍不通，谈时事新闻，我不关注；谈房子车子，我不懂；谈商业逻辑，那真是咸菜炖豆腐，不必多言!。

于是对自己的职业生涯重新定位，除了技术管理这条路，我还能够做什么？对于家人，我又有多少时间陪伴？最终，我选择了离职，在一年空窗中，我尝试了其他非技术领域的项目，跟客户谈合作，跟人打交道，到处出差谈客户，而正是在这段经历中，我懂得了几点：

人性不可挑战：利益能够驱使人变的险恶，有些人为了金钱，不断打破自己的原则，触碰别人的底线，最后两败俱伤！

人的一生都在为自己的认知买单：我在房价最高的时候选择了入手，是因为听信于别人说现在不买以后房价更高了啊，谁谁谁买了不久之后涨了xxx倍啊，在没有多选择对比几个楼盘之后就入手，利率5.85%，同时还被忽悠可以返佣金，大概有三四万，当时还眼前一亮，但只是口头约定，并没有白纸黑字立据，随后就比较随意签了一大堆合同，其中包括首付贷利率10%，同时销售承诺免3年物业费，猴子吞大象，亏他张得开嘴，唯独就这次办事没有录音，最后签合同时一口咬定没有这回事，吃了哑巴亏；还有补充协议，写着房产证要在交房后720天之后才能拿到，这是最致命的，真是谢天谢地谢广坤。

与此同时，做技术也是一样，某个阶段因为自身技术能力、认知缺陷在技术选型或方案选择上存在误差，在一段时间之后产生了历史债务，以往业务在小程序框架选型上就栽了跟头，在没有做过多的调研之后选择了一个组内成员比较熟悉的框架，在后面的业务发展中逐渐显得鸡肋，如不支持多端，框架出现断崖式更新，社区不活跃等等问题，所以在技术选型方面，我们需要考虑包括但不限于以下因素：业务发展方向、行业解决方案对比、解决了什么问题、组内成员的熟悉度、社区活跃度等等。

重回技术

看了不少行业，见了不少人，对于一些思维框架也在实际中得到验证，掌握一些思维模型在解决工作生活问题更加快捷，比如MECE法则、结构化思维、透过现象看本质、逻辑链思维等等，站在更高的视角看问题，我重新选择技术道路，在互联网大裁员环境下，基础薪资涨幅也超过40%。着力于以下几点：

• 对于接触新的技术，一上来撸文档或看视频，是一种低效并且不持久的学习方式，零碎的知识点就像是每一个神经元，相互没有连接成网络最终会形成一盘散沙，大脑并不擅长处理这种结构。而要多方面去渗透理解，如发展历史，着重解决哪些问题，相比其他类似技术，优势在哪？从这些角度入手，容易形成自己的知识框架。例如，在node生态中，express解决了什么问题？之后为什么又诞生孪生兄弟koa，两者有什么区别？后起之秀nest凭借什么能够脱颖而出，成为目前最流行企业级框架之一？按照这个逻辑链，梳理形成属于自己的知识体系。


• 源动力，一切行动背后都应该有充分的理由。我的努力工作目的就是在大城市有属于自己的家，想让家人过得更好，让下一代起点高一些，同时摆脱原生家庭因素的影响。在我看来，即便做最基础的工作，都应该思考为什么而做。

生活

生活的琐碎会消磨人的意识，磨平人的棱角，正是因为这样，乐观看待未来的心态决定了一个人成长的速度。

就在前一晚还跟妻子争吵了一番，源于我的原生家庭并没有给予她应该有的尊重和对待，受到的不公平对待，感觉到委屈，这是我作为中间人失责的一方面。

过去的一年中，我们遭受了别人的诋毁、否定和质疑，但最后我们还是走向了婚姻的殿堂，还有了一个很乖、很可爱的宝宝，这是我们最大的欣慰。时间从来不语，但它会回答所有问题！

生活的逐渐变好源于家庭每一个成员的共同努力，很不庆幸在我原生家庭中存在一些负能量的人，她们的内耗能够将家庭其他成员的能量都消耗殆尽，当然啦，我无法改变这些人，但可以通过运动、鸡汤和励志电影不断让自己保持高能量状态，同时减少或不接触这类人，愿我们都能够成为高能量场的人。

总结与展望

失败是成功之母，总结是成功之父。复盘是我成长最大的途径，极客时间中也有关于该话题的专栏，推荐一看。同时，在我看来经历、改变是最宝贵的财富，是我心智成熟的一方面，源于《谁动了我的奶酪？》。

在不久后的将来，当宝宝看到这篇文章的时候，他可以清楚地知道爸爸的过去以及此时所感所悟，所言所想，为他以后的道路再点亮一颗星星⭐️。

引言

好久没有发感触了，之前一直在做讲师授课，接触了好多入门的程序员，有很多感触，但是在做讲师的时候有时候不方便说，在做开发又开始忙，所以就沉淀下来了，忽然今天收到了之前一个学习的小伙伴的消息，心里有些触动，本人也不是一个特别喜欢发朋友圈的人，但是总感觉想说点啥（矫情了，哈哈），所以写写做一个回顾吧。

编程行业从开始到现在被贴上了很多标签: 幸苦，掉头发，工资高，不愁工作等等，这些有好有坏，但是总结起来大多数人对编程行业的认知是：

1、需要一定的学历，尤其对数学和英语要求很高。

2、工作比较累，加班是便饭。

3、收入很可观，10k轻轻松松。

4、岗位比较多，是一个搞高级技术（嘿嘿嘿，之前一个家长和我聊的）的行业。

当然还有很多，但是就是上面这些认知让好多毕业迷茫、家境一般、工作遇到问题的人，把编程行业作为了一个全新开始的选择。于是，就有了市场，有了市场很快就有了资本，有了资本很快就有了营造焦虑氛围的营销策略，然后就有各种各样在掩盖在光鲜下的问题，又得真的很无奈，那么今天就聊聊吧。

问题

1、社会是你做程序员的第一绊脚石

啥意思，啥叫做社会，这里的社会不是一个群居的结构，而是人情世故（嘿嘿嘿），好多小伙伴是转行过来的，老话说的好，人往高处走，水往低处流，大部分转行的小伙伴不是来自于大家认知当中更好的行业（比如：公务员，医生，律师..嘿嘿嘿，扯远了），甚至编程本行业的也很少（程序员自学的能力还是很不错的）,所以大家在学习之前就已经在社会上摸爬滚打了很久，久历人情，好处是好沟通，不好的地方就是真的把人情世故看的比技术更重要了，这一点可能拉低这些小伙伴70%的学习效果，你要明白，程序员这个行业确实也有人情世故，但前提是大家可以在一个水平上，这个水平可以是技术，也可以是职级，但是如果开头就这么琢磨的话，没有一个扎实的编程基础，真的很难立足在这个行业。没有必要的谦让，习惯性的差不多损耗了太多的学习效果了，既然选择编程，首先请把技术学好，哪怕是基础（当然那个行业也会有浑水摸鱼的，但是对于转行的小伙伴来说，概率太低了）

2、学历重要，学力也很重要

编程行业是一个需要终生学习的行业，不论是前端，后端，测试，运维还是其他岗位，如果在做技术就一定需要学习，好多人会说学历不够所以干不了编程，但是在我个人的眼里，学历确实重要，但是并没有完全限制你进入编程行业，因为：

（1）任何行业都是有完整的岗位结构的，需要的高精尖人才是需要的，但是普通的岗位也少不了，编程行业也是如此，有些岗位的学历要求不是很高。

（2）在编程行业除了那些竞争激烈的大厂，自考学历是有一定的市场和认可程度的

但是，在学历背后的学力就不是这样一个概念了，这里想表述的是学习能力，包括：

（1）专注能力，好多小伙伴如果之前有一定的社会经历或者在大学过的比较懒散，在没有聊到学历之前，先决条件就是能静下心来学习，但是很多小伙伴专注力根本不达标，听课走神，练习坐不住...(其实个人感觉任何一个行业，能静下心来做，并且活下来的都不会很差)

（2）学习习惯，这里不贬低学历低的小伙伴，但是不能否认的是，参加高考后获得一个高学历的小伙伴能力不谈，但是99%都有一个很好的学习习惯。比如不会在学习的时候把手机放到旁边，科学的记笔记，有效的复习和预习等等，所以在担心学历之前，请先培养好自己的学习习惯（个人建议，如果真的没有一个好的学习习惯，那么学习的时候就不要在眼前出现多余的东西分散注意力，比如: 课桌上除了听课的电脑，不要有其他的，之前见过的容易分散注意力的：手机，水杯，指尖陀螺，魔方....）

3、不要在没有选择能力的时候做出选择

这里想聊的是一些学习恐慌的小伙伴的惯性，好多小伙伴在选择了一种学习方式（买书，看视频，加入培训班）之后，还会进行类比学习，比如：买了Python的一本基础书，然后再大数据或者小伙伴的推荐下又买了另外一本，或者参加了培训班，又去看其他的教学视频，这些对小白同学的学习伤害会很大，因为，本身对技术没有全面的理解，不同的书，不同的教程传递的教学方法是不一样的，混着来有点像老家喝酒掺着喝，白酒不醉，啤酒不醉，白加啤那么就不一定了（很大概率会醉），所以小白同学最总要的不是再学习的过程当中进行对比，而是可以最快最稳的完成基础感念的学习，在自己脑子当中有了基础概念再做选择。

当然了，还有很多，一次也聊不完，之后有时间再聊吧，今天就先写这么多，欢迎大家讨论交流。

作为一个没有啥家底的小镇做题家，在去年选Offer阶段时，工作强度是我最不看重的一个点，当时觉得自己年轻、身体好、精神足，996算起来一天不过12个小时，去掉吃饭时间，一天也就9到10个小时，完全没有任何问题，对当时热衷于外企、国企、考公的同学非常的不理解，于是毫不犹豫的签了一个外界风评不太佳但是包裹给的相对多的Offer，然后便有了现在的心酸感悟。

入职前的忐忑

在一波三折终于拿到学位证后，怀着忐忑的心入职了。忐忑的原因主要是入职之前我并不知道我要入职什么部门，很怕我一个只会Java的后端被分配去写C++，毕竟Java是最好的语言，打死不学C++（手动狗头）。 也担心被分配到一个没有啥业务复杂度、数据复杂度的业务部门，每天CRUD迎接着产品的一个又一个需求，最后活成了CRUD Boy没有什么技术沉淀。又担心去和钱相关的部门，害怕自己代码出Bug，导致公司产生资损。

就这样忐忑着听完了入职当日上午的培训，中午便被我的mentor接走了，很不幸，我被我的mentor告知，我恰好被分在了和钱最直接相关的部门，我的心陡然沉重起来。

这里给出我最诚挚的建议，选Offer最好选一个实习过的部分，次之就是签了三方后去实习一段时间，如果发现部门的味儿不对或者和自己八字不合，此时还有机会跑路，以很小的代价换一家公司，不然毕业后入职就宛如开盲盒，万一遇到了很不适应的部门，交了社保、几个月的工作经验，到了市场上可谓是爹不疼娘不爱，比着校招时候的境遇差太多了。

熟悉项目的第一个月

得益于和钱相关，我部门的需求都不是很紧急，领导的态度是宁愿需求不上，也不能上出问题。所以每一个需求都没有说产品火急火燎的推动着要上线，都是稳扎稳打的在做，给予了开发比较充足的自测时间。但是呢，另外一方面，由于部门的业务领域比较底层，所以接手的项目往往都已经有了两三年的历史，相信写过代码的同学都知道，写代码的场景中最痛苦的那就是读懂别人的代码然后在别人的基础上进行开发，尤其是读懂几年前已经几经几手的项目代码。

第一个月刚进入公司，只是在熟悉项目代码，没有啥需求上的压力，相对来说还是比较轻松。遇到不熟悉的直接问靠谱的mentor，mentor也给热心的解答还是很幸运的。每天吃完公司订的盒饭。下楼转悠一圈就觉得美滋滋。

这个时候其实觉得，996不过如此嘛，好像也没有啥压力，真不搞不明白有啥可怕的。

进入开发状态的第二个月

在熟悉的差不多后，我就开始慢慢接手业务需求了，坦白的说，由于我接手的项目比较成熟，新接入业务需求往往不需要做什么开发工作，只需要做一些配置项，需求就完成了。 然而呢，作为一个几年的老项目，当然是处处埋的有彩蛋，你永远不知道哪里就会给你来一个惊喜。于是呢，我的工作开始变成，寻找代码中的彩蛋，搞明白各个配置项的含义，以及他们究竟是怎么组合的，然后和上下游联合对数据，发现数据对不上，就需要再埋进项目中一丝一缕的分析。

这个时候已经有些许的压力了，如果因为自己成为整个需求的卡点，那太过意不去了。于是开始每天勤勤恳恳，吃盒饭也没有那么香了，饭后散步的脚步也不再那么的愉悦，这时候开始感受到了肩上的压力。

本来我是坚决第一个离开工位下班，决心整治职场的人，但是往往在debug的路上，不经历的就把下班时间延长了一点又一点。而又由于在北京、上海这种大城市，住在公司旁边往往是一种奢望，导致我每天有较长的通勤时间。工作日一天下来，差不多就是晚上回去睡觉，早上醒来没有多久就出门赶地铁。

日复一日，就有一种流水线上螺丝钉的麻木感，周末往往一觉睡醒就结束了，感觉日子很重复，没有一些自己生活过的痕迹。

努力调整状态的第三个月

积极主动，是《高效能人士的七个习惯》中的第一个习惯，也是我印象最深的一个习惯。既然困难无法克服，那么咱们就要主动解决。

工作中，努力开拓自己的视野，搭理好手中的一亩三分地的同时，仰头看看上游，低头往往下游，对他们的业务也多一些学习，理清楚自己工作的业务价值，同时呢，在当好一名螺丝钉之外，也尝试着找出整个流水线的可优化点和风险点，尝试着给出自己的解决方案，同时积极梳理已有的项目代码的技术难点，是如何通过配置化来应对复杂的业务场景，是如何通过自动重试保证数据一致性。

生活中，周末即使比较累了，但是努力也不再宅在家中，一刷手机一整天，而是尝试着做一些比较有挑战或者更有回忆的事情。比如沿着黄浦江骑行。

比如自己下厨做几个菜

比如邀请三五好友玩个桌游

比如通过图书馆借一些杂书来消遣

对后来人想说的话

部门与部门之间的差异，很有可能比公司之间的都要大，选择Offer尽可能的选一个实习过的、或者比较熟悉的部门，能有效避免开盲盒踩雷的风险。没有绝对完美的公司，即使好评如潮的外企、券商类公司，我仍然有一些不幸运的同学，遇到了很卷的部门，平时要自愿加班或者在公司“学习”。

即使遇到了困境，也需要保持积极良好的心态，退一万步想，即使工作丢了，但是咱们的身心健康不能丢。为了这几斗米，伤了身体，是非常得不偿失的。

在选Offer的时候尽量一步到位，以终为始，如果目标瞄定了二线城市，其实我个人不太建议为了某些原因比如对大厂技术的热衷、对一线城市繁华的向往而选择当北漂沪漂，漂泊在外的日子都比较苦，而且吃这种苦往往是没有啥意义的。

我是日暮与星辰之间，一名努力学习成长的后端练习生，创作不易，求点赞、求关注、求收藏，如果你有什么想法或者求职路上、工作路上遇到了什么问题，欢迎在评论区里和我一起交流讨论。

背景

距离毕业到已经三年多了, 距离实习到现在已经三年半了, 在主管的建议下, 8月17号在公司的研发部门做了
一场关于成长的分享, 从工作方式到技术能力提升对自己三年的成长进行了一个复盘, 幸运的是分享得到的反
馈非常好, 老板看了将录屏在整个研发部进行公布并且推荐大家观看, 这是部门内分享活动以来第一次公示与推荐录
屏的情况, 我自己也感觉非常感慨, 毕业以来, 一直朝着“一年入门, 三年高工、五年资深、七年架构”的目
标前进, 有时候回过头来会发现这一路还是挺有意思的, 借着这样一个平台, 以文字的形式描述出来, 期望
能够给前行路上的各位有一定的帮助

下面的描述中, 为了不暴露个人信息, 对公司名称的描述统一替换为 XX, 涉及到人名的我都会进行打码

一、为什么做这个分享(why)

1.1、原因一

主管说从实习加入XX三年半以来, 看到我成长了很多, 推荐我可以做一下关于个人成长这一块的分享

1.2、原因二

我个人仔细的想了一下, 三年半前加入XX, 当时公司才400多人, 没有一个正式的java团队(公司主c#), 三年半的时间, 公司发展到了750多人, 我经历了java团队从0到1的完整过程(目前已经有3个java团队, 加起来有接近30个java开发), 并且在这三年半的时间, 公司的后端业务项目开始从.net往java迁移, 有大量的重构项目和新的大型项目, 在此期间, 经历了可能有10个以上从0到1的大型项目的落地, 并且这些项目中我个人承担了绝大部分的核心功能开发, 在这些项目的锻炼下, 不管是技术还是工作方式方面, 都有学习到非常多的知识, 借着这样的机会复盘一下, 继续完善自己, 我主观认为这样的经历可能会有一定的参考价值, 期望能够通过这样的一个分享, 能够给一些可能遇到瓶颈或者跟我遇到一样问题的同学一些启发

二、工作方式上的成长及建议

2.1、需求方案的决策

Pre: 遇到问题 / 需求我应该怎么做, 还没有独当一面的能力

Now: 遇到问题 / 需求我思考可以怎么做, 并从自己的角度出发提出方案, 标识每个方案的优缺点, 询问应该怎么做(即使提出的方案都不是最优解, 但是有自己的思考, 并且在遇到更合适的方案时能有一个对比学习)

截图是两个例子, 在我实现功能的时候, 有不同的方案, 在把握不准哪种方案比较合适的情况下, 向主管进行询问, 对可行的方案的优缺点进行分析, 在主管多年的经验下确定最终的实施方案

2.2、需求功能的实现和上线

Pre: 需求处理完, 简单的自测或者压根就不自测, 测试流程走完以后发上线就不管了(在工作过程中其实有遇到许多同事也是这样), 在刚来实习以及刚毕业那段时间, 一个功能编码完以后测试反馈了许多的bug问题, 改了一个旧的出现一个新的, 之前有听过一个段子, 测试听到开发说的最多的是什么(我没改代码 / 网络问题 / 你再试试), 这个段子就在我身上出现了, 当时改一个功能, 连续几次都没改好(因为改完后没有充分验证就提测了), 见下图(2021年的聊天记录)

Now: 需求处理完, 充分的自测, 提测以后多次跟进测试同学的测试情况, 上线后跟进线上是否正常使用, 找产品进行验收流程

Suggest: owner意识、需求从哪里开始就从哪里结束, 回调产生事件的人, 形成闭环

owner意识是主管在小组中提出来的一个工作方式, 是说一个开发, 在多人协作的场景下, 不能只关注自己那一块的功能, 需要对整个流程有充分的了解, 以一个owner的角色参与到项目开发中, 跟进其他端的对接, 把控整个项目的进度, 要做到这个其实是很难的, 需要花费更多的精力, 但是一旦做到了, 对整个项目就有一种非常清晰的感觉, 能够更好的完成多人协作项目的落地, 需求从哪里开始就从哪里结束, 每次一个需求处理完以后, 我会严格按照 自测 -> 提测 -> 联调 -> 督促产品验收 -> 灰度环境发布及验收 -> 正式环境发布及验收 -> 同步所有有关开发自己的功能的发布情况

在这样一个闭环的链路中, 功能的落地和稳定有了非常明显的提高

2.3、句句有回应, 事事有着落

Pre: 忙的时候忘记回消息, 事情多的时候忘记一些临时分配的事情, 遇到的坑重复跳

Now: todoList、QQ置顶, 多检查(防止多次返工), 防止重复的问题重复出现(错别字)

todoList:
我是通过一个txt文件来进行一个记录的(当然有更合适的, 只是用习惯了), 会记录手上的需求有哪些, 每一个的进度是怎么样的, 上线流程是怎么样的, 我给自己定的上线流程中分为以下几步, 并且在上线的过程中严格的按照下面的流程进行操作, 这样极大的提高了上线的稳定性(特别是一些大版本的发布, 有这样的严格流程下, 稳定性有了非常明显的提高)

1、是否有旧数据需要处理

2、是否有sql脚本需要执行

3、是否依赖于其他人的功能

4、是否有单独服务器灰度的需求, 有些业务需要单独一台服务器来进行灰度, 然后通过nginx将部分流量转发过来验收

5、开始灰度, 灰度后产品验收, 全部负载发布完毕后回调需求开始的人, 形成闭环

QQ置顶: 我们公司是采用QQ作为沟通工具的(可能是因为很早之前就是用这个, 即使现在有企业微信, 但是沟通这一块大家都不太倾向于切到企业微信), 当在外面或者遇到其他比较紧急事情时有人找或者发消息, 可能看完就忘记回了, 于是我养成一个习惯, 有人发消息没时间回的, 第一时间置顶, 等有空后再来跟进, 跟进完后取消置顶

防止重复的问题重复出现: 我们需要写周报, 刚开始的时候有出现错别字、格式不正确、周报字数过多的情况(主管规定周报不能超过250个字), 后面为了避免这种情况, 我每次写完都会阅读两遍内容, 防止之前产生的问题重复发生, 每个人都有粗心的时候, 也不能保证不出现错误, 但是我们可以通过一些方式方法来尽量的避免错误的重复发生

2.4、学习别人优秀的地方

人无完人, 比如我有时候说话会比较直接(好吧, 我是直男....), 那时主管就让我在沟通这一块多跟斜对面的同事学习一下, 后面我就观察他的沟通方式, 然后自己从模仿开始, 慢慢的也学会了怎么进行有效的沟通、委婉的拒绝等, 学习别人优秀的地方也是成长中比较重要的一环

2.5、批量接口的重要性

Pre: 对需求的时候遇到一个问题就问一次, 效率低, 刚来实习的时候, 不熟悉业务, 当时接触到一块比较复杂的涉及到购物车优惠计算的业务, 当时跟对方讨论的时候, 遇到一个不懂的就直接去问, 多次打断他的工作, 效率非常低

Now: 对整个需求进行梳理, 整理所有的疑问一次性请教, 效率提高了很多, 也不会容易打断别人的工作(反到现在我经常被别人打断=,=看到了曾经的我....)

2.6、做的事太简单, 没有挑战性

今年带了一个实习生, 刚开始给他分配的工作都是比较简单的, 主要是修bug、小需求, 但是即使是这样简单的功能, 他做的也是磕磕碰碰, 比如代码规范不达标、空指针异常判断不全面、业务涉及到的点想的不全面等等许多瑕疵, 多次需要我来进行一个兜底, 后面他跟HR反馈说太简单没有挑战性, 于是我就分配了一个稍微大的一点需求给他, 结果做的惨不忍睹, 后面他实习结束时这个需求才做到一半, 我转给其他同事帮忙接手....结果那个同事看到代码后对我吐槽了许久....

当时收到反馈后, 我及时的找他进行沟通, 我的观点是他做的每一个简单的需求, 需求的完整稳定上线都是为了给主管建立一个做事靠谱的印象, 如果做事不靠谱, 经常需要他人来进行兜底, 那么谁也不敢把复杂重要的任务交给你做, 公司很多业务都涉及到商家的钱, 一旦这种重要的业务出问题, 那么会给公司造成巨大损失, 其实仔细想想, 自己实习那会也差不多, 想要做很厉害的项目, 用很流行的技术, 但是如果自己给人的感觉是不靠谱的, 那么主管自然就不敢把这些项目交给我了, 明白了这一点后, 当时我毕业一年给主管的目标是一个需求功能下来, 不管大小, 测试反馈的bug不能超过3个, 一个月产生的线上事故不能超过1次, 我努力做到了这一点, 线上事故几乎没发生过, 随之而来的是小组中绝大部分核心的业务、基础组件的开发都由我来处理, 以及一波大的涨薪

2.7、内卷

维基百科: 原是一个社会学概念，指一种文化模式发展到一定水平后，无法突破自身，只能在内部继续发展、复杂化的过程。大约从2018年开始，“内卷”一词在中国大陆变得广为人知，并引申表示付出大量努力却得不到等价的回报，必须在竞争中超过他人的社会文化，包含了恶性竞争、逐底竞争等更为负面的含义。

我们公司965几乎不加班, 所以我们6点会有比较充足的时间, 我一般去楼下吃完饭以后就会回到公司学习, 三年半的时间阅读了大量的源码书籍、学习了许多知识, 个人认为, 深入学习技术, 提高自己其实不属于内卷, 无意义的加班, 内耗等才是内卷, 其他小组也有人说我比较卷, 但是我们小组(包括主管)都是知道我晚上下班后是在公司学习的, 也很少会加班, 借着分享的机会我也跟大家澄清了这样的情况, 并且我们小组的氛围并没有因为我下班后的学习而导致整个小组都晚下班的情况(公司7点左右就基本空了.....)

三、技术能力上的成长及建议

3.1、如何学习

一、我学习一门未接触过的技术时, 会先看视频学习, 建立基本认识, 并且能够从讲师身上学到一些经验, 即先学会简单的使用
二、在了解了基本使用, 并且用起来的情况下, 我会查找跟该技术有关的权威书籍, 对权威书籍的学习是为了建立完整的知识体系

这个学习方式是我从大学以来就保持的, 而我认为这也是对我来说是最合适的学习方式

3.2、打地基-基础知识的重要性

基础知识对一个程序员来说是非常重要的, 个人认为基础越扎实的同学往往在学习技术的时候会吸收的更快, 并且也能够走的更远

一、数据结构, 我学习数据结构的时候, 会手写每个数据结构, 即使是最难的红黑树, 我也手写出来了(当时在大学的时候花了一个下午就为了写一个新增节点和删除节点的方法), 对于数据结构的学习, 我推荐: 恋上数据结构 这套视频, 讲的非常好, 大家如果有兴趣的话可以各显神通的去找找=,=

二、计算机网络, 计算机网络我是通过看视频加书籍的方式来学习的, 视频推荐: 韩立刚, B站就能搜到, 讲的通俗易懂, 我推荐了几个朋友看, 都反馈非常棒, 书籍推荐 计算机网络 第六版(考研408专用)

三、操作系统, 对操作系统的学习, 能够让我们在了解JVM、以及一些底层知识的时候(比如CAS、volatile、synchronize等原理)能够更加的顺利, 他们都是依赖于操作系统相关的知识来的, 视频我推荐: 哈工大的计算机操作系统, B站能搜到, 书籍推荐计算机操作系统(考研408专用)

四、汇编语言, 如果有看过深入理解Java虚拟机这本书, 那么里面就有出现跟汇编相关的话术, 如果对汇编有所了解, 能够亲身的体验到寄存器操作、中断的原理等, 这些在学习操作系统等知识的时候必然会遇到的话术, 视频我推荐推荐: 小甲鱼, B站就能搜到, 书籍我推荐(汇编语言(第3版) 王爽)

五、设计模式, 刚开始写代码的时候, 会一个方法写很多逻辑, 就像流水账一样, 一直写下去, 没有考虑复用等情况, 通过学习设计模式, 我们可以写出更加优雅的代码, 模板方法、单例、工厂等模式的使用能够使得我们的代码阅读性更高、扩展性更强, 学会了设计模式的情况下, 再去看自己之前写的代码就会发现还能写的更好! 并且有了这个知识的基础上, 我们去看一些框架源码的时候会更加顺利, 框架源码用到设计模式的时候命名都是通俗易懂的, 看到名字就知道用了什么模式, 就像程序员之前互相沟通一样, 这个我没有看视频, 我看的是 HeadFirst设计模式 这本书籍, 通过一些生动形象的例子, 把设计模式讲活了...

3.3、创造核心竞争力-不停留在只会用的地步

java开发往往离不开spring的生态系统, 框架开发出来就是给人更加方便开发功能用的, 如果仅仅会用, 那么在遇到一些问题的时候会无从下手, 三年半的时候, 我阅读了spring、springmvc、mybatis、springboot、springcloud等框架的源码, 通过书籍加视频的方式深入的了解了这些框架的原理, 看这些框架源码的时候, 不纠结于一些边线知识, 只管主线流程, 了解主线流程后, 我发现后续遇到问题时, 我能非常自信的跟进源码去排查问题, 在第四章节中我会整理每一个框架我都是通过哪些书籍来深入学习的

3.4、学以致用-尝试输出(github / 博客 / 分享)

学习一个知识, 如果仅仅看了一遍书 / 看了一遍视频, 那么可能过几天就会忘记了, 一般我是通过看视频 -> 记笔记 -> 看书 -> 对书中的知识点进行整理笔记, 笔记采用类似于给他人讲解的方式来记录 -> 将笔记记录在github 或者 以博客的形式分享出来, 在这样的链路下, 我每一步都能更加深刻的学习到知识点, 有时候看书看懂了不代表真懂了, 真正用笔记来描述的时候会发现是磕磕碰碰的, 与此同时, 将这些磕磕碰碰的知识去再次学习, 那么对整个知识点就会有更加全新的认识, 大家也可以看到, 我的掘金的博客是从2020年就开始写了, 都是我个人的口头描述转为文字描述

3.5、有枪不用和无枪可用

在掌握了工作中需要的知识点的情况下, 我们需要去学习流行的技术, 防止自己落伍, 技术的迭代更新是非常快的, 学习这些技术, 往往会给自己带来意想不到的结果

一年前公司我深入的去研究了eureka、zuul等springcloud组件的原理, 后面幸运的是, 公司有一个私有化部署的项目, 主管的计划是用微服务来搭建, 这个项目需要考虑到客户的资源,
有些客户可能预算比较高, 我们就可以提供一套完整的微服务来运行, 有些客户预算比较低, 那么可能最多就跑3-4个java项目, 于是主管的要求是我们的微服务功能, 需要能够满足上述的情况,
能够非常方便的将一个或者多个服务合并成一个服务, 并且自由搭配

正是因为我有对这些组件的深入了解, 我从源码层次提供了一套实现方案, 并且是最简单的实现方案, 主要的原理就是控制bean的加载(打包的时候一起打包, 但是不加载到内存)以及内部
rpc调用时的扩展(利用回环地址来尽可能的忽略http请求的花销), 如果我没有对这一块有所掌握, 那么我可能就失去了这样一个非常好的锻炼机会了

四、从成长的曲线来看侧重点

作者：山猎

茶百道是四川成都的本土茶饮连锁品牌，创立于 2008 年 。经过 15 年的发展，茶百道已成为餐饮标杆品牌，全国门店超 7000 家，遍布全国 31 个省市，实现中国大陆所有省份及各线级城市的全覆盖。2021 年 3 月 31 日，在成渝餐·饮峰会中，茶百道斩获“2021 成渝餐·饮标杆品牌奖”。2021 年 8 月，入选艾媒金榜（iiMedia Ranking）最新发布《2021 年上半年中国新式茶饮品牌排行 Top15》。2023 年 6 月 9 日，新茶饮品牌“茶百道”获得新一轮融资，由兰馨亚洲领投，多家知名投资机构跟投，估值飙升至 180 亿元。

今年 4 月，茶百道在成都总部举行了品牌升级发布会，宣布门店数突破 7000 家。根据中国连锁经营协会的数据，截至 2020 年、2021 年以及 2022 年 12 月 31 日，茶百道门店数量分别为 2,240 间、5,070 间以及 6,532 间，疫情并没有拖慢其扩张步伐。

随着业务规模的急速扩展，茶百道全面加速推进数字化转型战略。 但由于茶百道部分早期业务系统由外部 SaaS 服务商提供，无法满足线上业务高速增长所带来的大规模、高并发、弹性扩展、敏捷性、可观测等要求。为了满足线上线下门店客户需求与业务增长需要，针对店务、POS、用户交易、平台对接、门店管理、餐饮制作等核心链路服务，茶百道选择全面自研与阿里云云原生能力相结合，推动容器化、微服务化、可观测能力全面升级。

云原生化的业务价值

茶饮行业面临着市场竞争的压力和内部运营效率的提升需求。为了应对这些挑战，阿里云与茶百道一起完成云原生上云的转型，开启数字化的新征程。

采用容器和微服务技术实现了应用的轻量化和高可移植性。让企业可以更灵活地部署、扩展应用，快速响应市场需求，使得企业能够实现应用的高可用性和弹性扩展能力，无论面对突发的高峰访问量还是系统故障，都能保持业务的稳定运行。

引入了持续交付和持续集成的开发方式，帮助企业实现了快速迭代和部署。通过自动化的流程，企业能够更快地推出新功能和产品，与市场保持同步，抢占先机。

云原生的上云转型不仅带来了更高的安全性、可用性和可伸缩性，也提升了企业的创新能力和竞争力。

云原生带来的可观测挑战

茶百道作为业务高速发展的新兴餐饮品牌，每天都有海量的在线订单，这背后是与互联网技术的紧密结合，借助极高的数字化建设支撑茶百道庞大的销售量。因此，对于业务系统的连续性与可用性有着非常严苛的要求，以确保交易链路核心服务的稳定运行。特别是在每日高峰订餐时段、营销活动、突发热点事件期间，为了让用户有顺畅的使用体验，整个微服务系统的每个环节都需要保证在高并发大流量下的服务质量。

完善的全链路可观测平台以及 APM  ( Application Performance Management )工具，是保障业务连续性与可用性的前提。在可观测技术体系建设上，茶百道技术团队经历过比较多探索。全面实现容器化之前，茶百道在部分微服务系统上接入了开源 APM 工具，并进行超过一年时间的验证，但最终没有能够推广到整个微服务架构中，主要有这几个方面的原因：

• 
  

  指标数据准确度与采样率之间的平衡难以取舍

  
  

  适当的采样策略是解决链路追踪工具成本与性能的重要手段，如果 APM 工具固定使用 100% 链路全采集，会带来大量重复链路信息被保存。在茶百道的庞大微服务系统规模下，100% 链路采集会造成可观测平台存储成本超出预期，而且在业务高峰期还会对微服务应用本身的性能带来一定影响。但开源工具在设定采样策略的情况下，又会影响指标数据准确度，使错误率、P99 响应时间等重要可观测指标失去观测与告警价值。

  
  


• 
  

  缺少高阶告警能力

  
  

  开源工具在告警方面实现比较简单，用户需要自行分别搭建告警处理及告警分派平台，才能实现告警信息发送到 IM 群等基本功能。由于茶百道微服务化后的服务模块众多、依赖复杂。经常因为某个组件的异常或不可用导致整条链路产生大量冗余告警，形成告警风暴。造成的结果就是运维团队疲于应付五花八门且数量庞大的告警信息，非常容易遗漏真正用于故障排查的重要消息。

  
  


• 
  

  故障排查手段单一

  
  

  开源 APM 工具主要基于 Trace 链路信息帮助用户实现故障定位，对于简单的微服务系统性能问题，用户能够快速找到性能瓶颈点或故障源。但实际生产环境中的很多疑难杂症，根本没有办法通过简单的链路分析去解决，比如 N+1 问题，内存 OOM，CPU 占用率过高，线程池打满等。这样就对技术团队提出了极高要求，团队需要深入了解底层技术细节，并具备丰富 SRE 经验的工程师，才能快速准确的定位故障根源。

  
  

接入阿里云应用实时监控服务 ARMS

在茶百道系统架构全面云原生化的过程中，茶百道技术团队与阿里云的工程师深入探讨了全链路可观测更好的落地方式。

ARMS 应用监控作为阿里云云原生可观测产品家族的重要成员，提供线程剖析、智能洞察、CPU & 内存诊断、告警集成等开源 APM 产品不具备的能力。在阿里云的建议下，茶百道技术团队尝试着将一个业务模块接入 ARMS 应用监控。

由于 ARMS 提供了容器服务 ACK 环境下的应用自动接入，只需要对每个应用的 YAML 文件增加 2 行代码就自动注入探针，完成整个接入流程。经过一段时间试用，ARMS 应用监控提供的实战价值被茶百道的工程师不断挖掘出来。茶百道同时使用了阿里云性能测试产品 PTS，来实现日常态和大促态的容量规划。因为ARMS和 PTS 的引入，茶百道日常运维与稳定性保障体系也发生了众多升级。

围绕 ARMS 告警平台构建应急响应体系

由于之前基于开源产品搭建告警平台时，经常遇到告警风暴的问题，茶百道对于告警规则的配置是非常谨慎的，尽可能将告警目标收敛到最严重的业务故障上，这样虽然可以避免告警风暴对 SRE 团队的频繁骚扰，但也会让很多有价值的信息被忽略，比如接口响应时间的突增等。

其实对于告警风暴问题，业界是有一整套标准解法的，其中涉及到去重、压缩、降噪、静默等关键技术，只是这些技术与可观测产品集成上存在一定复杂度，很多开源产品并没有在这个领域提供完善方案。

这些告警领域的关键技术，在 ARMS 告警平台上都有完整功能。以事件压缩举例，ARMS 提供基于标签压缩和基于时间压缩两种压缩方式。满足条件的多条事件会被自动压缩成为一条告警进行通知（如下图所示）。

图: 基于标签压缩

图：基于时间压缩

配合 ARMS 告警平台所提供的多种技术手段，可以非常有效的解决告警风暴的问题，因此茶百道技术团队开始重视告警的使用，逐步丰富更多的告警规则，覆盖应用接口、主机指标、JVM 参数、数据库访问等不同层面。

通过企业微信群进行对接，使告警通知实现 ISTM 流程的互动，当值班人员收到告警通知后，可以直接通过 IM 工具进行告警关闭、事件升级等能力，快速实现告警处理。（如下图所示）

图：监控告警事件的智能化收敛与通告

灵活开放的告警事件处置策略满足了不同时效、场景的需求。茶百道在此基础上参考阿里巴巴安全生产最佳实践，开始构建企业级应急响应体系。将业务视角的应急场景作为事件应急处置的核心模型，通过不同告警级别，识别与流转对应的故障处理过程。这些都是茶百道在全面云原生化后摸索出的经验，并显著提升生产环境服务质量。

引入采样策略

从链路信息中提取指标数据，是所有 APM 工具的必备功能。不同于开源产品简单粗暴的指标提取方式，ARMS 应用监控使用端侧预聚合能力，捕捉每一次真实请求，先聚合，后采样，再上报，提供精准的指标监控。确保在采样策略开启的情况下，指标数据依然与真实情况保持一致。

图：ARMS 端侧预聚合能力

为了降低 APM 工具带来的应用性能损耗，茶百道对大部分应用采取 10% 采样率，对于 TPS 非常高的应用则采取自适应采样策略，进一步降低高峰期应用性能损耗。通过实测，在业务高峰期，ARMS 应用监控造成的应用性能损耗比开源产品低 30% 以上且指标数据准确性可信赖， 比如接口级别的平均响应时间、错误数等指标都可以满足生产级业务需求。

图：接口级别指标数据

异步链路自动埋点*

在 Java 领域存在异步线程池技术，以及众多开源异步框架，比如 RxJava、Reactor Netty、Vert.x 等。相较于同步链路，异步链路的自动埋点与上下文透传的技术难度更大。开源产品对主流异步框架的覆盖度不全，在特定场景下存在埋点失败问题，一旦出现这样的问题，APM 工具最重要的链路分析能力就难以发挥作用。

在这种情况下，需要开发者自行通过 SDK 手工埋点，以保证异步链路的上下文透传。这就会造成巨大的工作量且难以在团队内部大面积、快速推广。

ARMS 对主流的异步框架都实现了支持，无需任何业务代码上的侵入就能够异步链路上下文透传，即使对一些异步框架的特定版本没有及时支持，只要用户侧提出需求，ARMS 团队就能在新版本的探针中补齐。使用 ARMS 应用监控之后，茶百道技术团队直接将此前异步框架手工埋点代码进行了清理，大幅度减少维护工作量。

图：异步调用的链路上下文

更高阶应用诊断技术的运用

在埋点覆盖度足够高的情况下，传统 APM 工具和链路跟踪工具能够帮助用户快速确定链路的哪一个环节（也就是Span）存在性能瓶颈，但需要更进一步排查问题根源时，就无法提供更有效的帮助了。

举一个例子，当系统 CPU 占用率显著提升时，是否因某个业务方法疯狂的消耗 CPU 资源所导致？这个问题对于大多数的 APM 产品而言，都是难以办法解决的。因为单从链路视图无法知晓每个环节的资源消耗情况。茶百道的工程师在使用开源工具时，曾多次遇到类似问题，当时只能凭借经验去猜测，再去测试环境反复对比来彻底解决，虽然也试过一些 Profiling 工具，但使用门槛比较高，效果不是很好。

ARMS 应用监控提供了 CPU & 内存诊断能力，可以有效发现 Java 程序中因为 CPU、内存和 I/O 导致的瓶颈问题，并按照方法名称、类名称、行号进行细分统计，最终协助开发者优化程序、降低延迟、增加吞吐、节约成本。CPU & 内存诊断可以在需要排查特定问题时临时开启，并通过火焰图帮助用户直接找到问题根源。在一次生产环境某应用 CPU 飙升场景中，茶百道的工程师通过 CPU & 内存诊断一步定位到问题是由一个特定业务算法所导致。

图：通过火焰图分析 CPU 时间

此外，对于线上的业务问题，还可以通过 ARMS 提供的 Arthas 诊断能力在线排查。Arthas 作为诊断 Java 领域线上问题诊断利器，利用字节码增强技术，可以在不重启 JVM 进程的情况下，查看程序运行情况。

虽然 Arthas 使用有一定门槛，需要投入比较多精力进行学习，但茶百道的工程师非常喜欢使用这个工具。针对“到底符合哪种特殊的数据导致某业务异常”此类问题，没有比 Arthas 更方便的排查工具了。

阶段性成果

经过 2 个月时间的调研与对比，茶百道决定全面从开源可观测平台转向 ARMS，从开源压测平台转向 PTS，并在团队内部进行推广。**随着使用的不断深入，ARMS 所提供的智能洞察、线程池分析等高阶可观测能力也逐步被茶百道的技术团队应用于日常运维中，线上问题排查效率相比之前也有了数倍提升。

在可观测产品本身的使用成本上，虽然表面上 ARMS 相比开源产品有所提高，但这是建立在开源方案数据单写，以及存在单点故障的情况下。其实茶百道的技术团队也非常清楚，之前的开源方案是存在高可用性隐患的，某个组件的故障会导致整个可观测方案不可用。只是大家对于开源方案提供的可观测能力并没有重度使用，所以才没有足够重视。所以综合来看，ARMS 整体成本并不会高于开源方案。

利用 ARMS 能力，茶百道实现了可观测指标采样率百分百覆盖，链路全采集，监控数据准确率大幅提供，能够快速实现业务故障的自动发现，有效的配合敏态业务发展。

故障发生后，监控系统需要第一时间通知相关人员，做初步定位，ARMS 告警告警能力实现了 ChatOps 能力，基于 IM 工具，快速触达相关人员，并且提供初步定位能力，是故障的响应能力大幅提升。

故障的快速恢复，对于控制业务影响至关重要，ARMS 利用全链路 Trace 能力，快速定位具体应用、接口、方法、慢sql等，是故障快速恢复的关键助手。茶百道技术团队负责人表示： “在与开源方案成本持平的前提下，ARMS 丰富且全面的全栈观测与告警能力，使茶百道快速建立运维观测与响应能力，故障恢复效率提升 50% 以上，故障恢复耗时****缩短 50%，真正做到用可观测为业务迅猛发展保驾护航。”

故障的预防收敛，在稳定性体系建设中是投入产出比极高的，PTS 利用全国流量施压的能力，和秒级监控能力，验证站点容量并定位性能瓶颈。茶百道在业务上线前，充分对单应用和全链路做压测，累计压测 800 余次，在上线前做到了性能问题的收敛，避免演进为线上故障。

下阶段目标

在可观测领域，Prometheus + Grafana 是指标数据存储、计算、查询、展示的事实标准，ARMS 产品家族提供托管加强的 Prometheus 和 Grafana 服务。ARMS 应用监控生成的指标数据也会自动保存到托管版 Prometheus 中，并预置数张 Grafana 大盘。茶百道的工程师们正在基于 Prometheus 和 Grafana，将应用层指标、关键业务指标、云服务指标进行结合，开发多维度可观测大盘。

在不久的将来，茶百道就会建立覆盖业务层、用户体验层、应用服务层、基础设置层、云服务层的统一可观测技术体系，为千万级用户同时在线的大规模微服务系统实现稳定性保障。