后端：密码得走密文哇！

我：base64？md5？

后端:这次不行哇，新来的测试不好糊弄呢！必须要国密sm2加密捏

我: 好吧，看我的。

我这边使用的是sm-crypto，当然也有很多优秀的库如：forge,我在业务上搭配jszip做过上传zip文件内藏加密后的私钥进行证书登录，还是不错的支持，但是文档社区不是很友好，所以推荐sm-crypto，接下来让我们一起使用它吧。

sm-crypto是一个基于Node.js的密码学库，专为与国密算法（中国密码算法标准）兼容而设计。它提供了各种加密、解密、签名和验证功能。

sm-crypto包含多种密码算法的实现，例如：

• SM1：对称加密算法，其加密强度与AES相当，但该算法不公开，调用时需要通过加密芯片的接口进行调用。


• SM2：非对称加密算法，基于ECC（椭圆曲线密码学）。该算法已公开，且由于基于ECC，其签名速度与秘钥生成速度都快于RSA。此外，ECC 256位（SM2采用的就是ECC 256位的一种）的安全强度比RSA 2048位高，但运算速度快于RSA。


• SM3：消息摘要算法，可以用MD5作为对比理解，其校验结果为256位。


• SM4：无线局域网标准的分组数据算法，属于对称加密，密钥长度和分组长度均为128位。

sm-crypto内部方法介绍

1.SM2加密与解密

SM2是一种基于椭圆曲线密码学的非对称加密算法。sm-crypto提供了SM2的密钥生成、加密、解密等功能。通过调用相关方法，开发者可以轻松地生成SM2密钥对，并使用公钥进行加密、私钥进行解密。

const { sm2 } = require('sm-crypto');  

const keyPair = sm2.generateKeyPairHex(); // 生成密钥对  

const publicKey = keyPair.publicKey; // 公钥  

const privateKey = keyPair.privateKey; // 私钥  

  

const message = 'Hello, SM2!'; // 待加密的消息  

const encrypted = sm2.doEncrypt(message, publicKey, { hash: true }); // 使用公钥加密  

const decrypted = sm2.doDecrypt(encrypted, privateKey, { hash: true, raw: true }); // 使用私钥解密  

  

console.log('加密结果:', encrypted);  

console.log('解密结果:', decrypted.toString()); // 输出原始消息

2.SM3摘要算法

SM3是一种密码杂凑算法，用于生成消息的摘要值。sm-crypto提供了SM3的摘要计算功能，开发者可以通过调用相关方法计算任意消息的SM3摘要值。

const { sm3 } = require('sm-crypto');  

const message = 'Hello, SM3!'; // 待计算摘要的消息  

const digest = sm3(message); // 计算SM3摘要值  

  

console.log('SM3摘要值:', digest);

3.SM4分组加密算法

SM4是一种分组密码算法，适用于无线局域网等场景。sm-crypto提供了SM4的加密与解密功能，开发者可以使用SM4密钥对数据进行加密和解密操作。

const sm4 = require('sm-crypto').sm4;                                               |

const sm4 = require('sm-crypto').sm4;  

const key = '0123456789abcdeffedcba9876543210'; // 16字节的SM4密钥  

const message = 'Hello, SM4!'; // 待加密的消息  

const encrypted = sm4.encrypt(Buffer.from(message), Buffer.from(key, 'hex')); // 加密  

const decrypted = sm4.decrypt(encrypted, Buffer.from(key, 'hex')); // 解密  

  

console.log('加密结果:', encrypted.toString('hex'));  

console.log('解密结果:', decrypted.toString()); // 输出原始消息

4、签名/验签

签名(Sign)

const { sm2 } = require('sm-crypto'); 

const keyPair = sm2.generateKeyPairHex(); // 生成密钥对 

const publicKey = keyPair.publicKey; // 公钥 

const privateKey = keyPair.privateKey; // 私钥



const message = '这是要签名的消息'; // 替换为实际要签名的消息 

// 使用私钥对消息进行签名  

let sigValueHex = sm2.doSignature(message, privateKey); 

console.log('签名结果:', sigValueHex);

验签(Verify Signature)

const message = '这是要验证签名的消息'; // 应与签名时使用的消息相同  

const sigValueHex = '签名值'; // 替换为实际的签名值字符串，即签名步骤中生成的sigValueHex  

  

// 使用公钥验证签名是否有效  

let verifyResult = sm2.doVerifySignature(message, sigValueHex, publicKey);  

  

console.log('验签结果:', verifyResult); // 如果验证成功，应输出true；否则输出false

实战例子

登录注册，对用户密码进行加密

注意：前端是不储存任何涉及安全的密钥（公钥是直接拿后端生成的）。

新建个工具文件，专门存放加密逻辑，我这用的是SM2

// smCrypto.js

import { sm2 } from 'sm-crypto' // 引入加密库



export const doEncrypt = ( // 加密

  data,

  pKey = publicKey,

  cipherMode = 0

) =>

  sm2.doEncrypt(

    typeof data === 'object'

      ? JSON.stringify(data) : data, 

    pKey, 

    cipherMode

  )

export const encryptionPwd = async data => {  // 加密密码高阶

  let servePublicKey = ''

  await user.getSm2Pkeys()

      .then(res => {

         servePublicKey = res.data.content

      })

  return doEncrypt(

    data,

    servePublicKey

  )

}

sm-crypto作为一款基于Node.js的国密算法库，为开发者提供了丰富的密码学功能。通过调用sm-crypto的内部方法，开发者可以轻松地实现SM2加密与解密、SM3摘要计算以及SM4分组加密等操作。这些功能在保障数据安全、构建安全应用等方面发挥着重要作用。同时，开发者在使用sm-crypto时，也需要注意遵循最佳的安全实践，确保密钥的安全存储和管理，以防止潜在的安全风险。

概述

无痕模式，有些浏览器也叫隐身模式，隐私模式。该模式下所有cookie、缓存是失效的，也就是所有原来的登录信息都会消失，那么是否你打开一个网站，网站平台就真的不确定你是谁了吗？ 不一定哦。这个世界上有一种技术叫浏览器指纹技术，不需要你登录，它就可以根据你的特定标志来区分，从而跟踪你的所有操作记录。今天我们就来看看这种技术的原理，还有用途。

一、原理

浏览器指纹可以在用户没有任何登录的情况下仍然知道你谁，比如你在登录了一下网站A，现在开启无痕模式，再次打开网站A， 那么网站A大概率还是能区分现在操作网站的人是谁。 因为在这个世界上，用户的浏览器环境极小概率才能相同，考虑的因素包括浏览器版本、浏览器型号、屏幕分辨率、系统语言、本地时间、CPU架构、电池状态、网络信息、已安装的浏览器插件等等各种各样。浏览器指纹技术就是用这些因素来综合计算一个哈希值，这个哈希值大概率是唯一的。

二、展示

今天我们就展示一下单单利用Canvas画布这个功能来确定用户的唯一标识，因为Canvas API专为通过JavaScript和HTML绘制图形而设计，而图形在画布上的呈现方式可能因Web浏览器、操作系统、显卡和其他因素而不一样，从而产生可用于创建指纹的唯一图像，我们利用下方代码展示一个图像。

// 输入一个带有小写、大写、标点符号的文本

var txt = "BrowserLeaks,com <canvas> 1.0";

ctx.textBaseline = "top";

ctx.font = "14px 'Arial'";

ctx.textBaseline = "alphabetic";

ctx.fillStyle = "#f60";

ctx.fillRect(125,1,62,20);

ctx.fillStyle = "#069";

ctx.fillText(txt, 2, 15);

ctx.fillStyle = "rgba(102, 204, 0, 0.7)";

ctx.fillText(txt, 4, 17);

下面动画GIF图展示了虽然JavaScript代码相同，但是由于图像在不同系统上的呈现方式不同，因此每一个用户所显示的图像都有细微的差别。这种差别大多数时候人眼通常无法识别，但通过对生成图像的数据进行分析就能发现不一样。

我们直接看成品，利用普通模式和无痕模式打开这个测试网站，就能发现2个哈希值是完全一样的，并且是每15万个用户中有2个人可能是相同的哈希值，唯一性达到了99.99%。

三、用途

1、广告

广告联盟通过浏览器指纹技术，不需要你登录，就可以知道你看过哪些记录，然后在其他站点给你推送你感兴趣的广告。所以有时候我们经常会碰到在淘宝或者百度搜索了一个商品，然后去到其他网站，马上给你推送你搜索过的商品的广告。

2、防刷

针对一些商品的浏览量、内容的阅读量、投票等等各种类似平台，往往会针对用户做一个限制，比如只能浏览一次。这种时候往往也都是用浏览器指纹技术，虽然你可能注册了很多用户账号，但是你的浏览器指纹都是相同的，可以判断你就是同一个人。不过上有政策，下有对策，有个东西叫做指纹浏览器，这类浏览器里面可以随意的切换用户的指纹。 所以这个技术针对广大的普通用户防刷还是有效的，对专业的刷量工作室就没什么效果了。

前言

今天技术博主不聊技术，聊聊生活聊聊情感。先叠个甲，我纯纯乐子人，对婚介所无任何恶意，可能后面还得用上，本次纯纯试探下婚介所是个什么路数！事件源于上周五的一通红娘电话，我一听要给我介绍有钱有颜的小姐姐，直接挂断，这天底下哪有这样的好事。当天下午的时候，又给我来了一通电话，仿佛不知道我给她挂断了一样，基于一些奇妙的想法，我想尝试以及找找素材，我决定让她微信跟我聊。然后因为博主工作比较忙，打了招呼后，就没理她，最关键是到晚上下班后，我也忘了这档子事。周六的下午四点左右，一通电话开启了本次的故事，即使315曝光了相关产业，但是博主依然要冲，就是头铁。

阳光下午的微醺时光

接到电话的时候，我挺疑惑的，这次上来就问我现在是不是有空，出于礼貌，并且我也听出了她是昨天那个红娘，我就没有挂断电话。上来就说，弟弟，我是XX老师，今天来电话主要是聊一下，看能不能进一步推荐小姐姐。说她那里看资料我是97年的程序员，年收入XX，对吗？然后我说是，她就跟我说这里有个小姐姐挺合适的，北京XX工作的，身高165身高，本地的，收入XX。哥们一听就懵了，本地的，心里OS是，那咋遭得住，咱也不是高富帅，纯纯普男。红娘一听就问我有没有考虑常驻北京，然后就问我老家哪里的，我说四川的，她就在资料库里找了找，说真有个四川在北京的，快速给我念了一遍女生的资料。

接着就离谱了，问我怎么称呼？我说姓王，哪里工作，海淀XX公司？红娘直接薄纱，诶，没听过耶( •̀ ω •́ )y，咱们一般服务百度、阿里和字节的比较多。好好好，北京人中龙凤就是多，哥们就是菜中菜，脸都绿了。接着问我加班如何，公司福利啥的，然后说我这个181cm的身高在四川挺高的，她知道的四川男生都不太高来着。然后聊到了哥们的毕业学校，说前两天有个大连理工的女孩，真绝了，大家都这么爱走婚介所吗？我感觉聊到啥，都有女孩能配上，后面说到工作，又聊到一个大二的姑娘还没工作就来找对象了，好好好，走上了人生快车道。

然后聊到了我父母的职业，就说哥们的条件在当地不错，怎么没找上对象？我当时就说到了我的前对象，网恋的，就在掘金找的，一说到这个，好兄弟们，掘金真的能找对象的，不骗人。我的失败不是网恋的问题，纯属我自己的问题，第一次谈吧，不知道咋谈，自己也是摸不准进度，达不到对象的期待，慢慢地就淡了。我也是无脑纯爱战士，这是红娘听了之后的评价，哈哈，不过我觉得前对象确实挺不错的，当时要是硬扛着也能继续，但是我感觉可能是热情燃尽了，她也算是太忙了太累了，无论是生活还是工作，我都挺佩服，主动退出，我感觉应该是我被甩了。不后悔，男人就该当断即断，她也不小了，继续耗着，对她不公平。说远了啊，核心意思就是，网恋也有靠谱的，掘金这质量高的离谱，大家多去相亲角看看。

说着说着，突然红娘聊到了星座，说我应该了解了解星座，也说到了一些星座的小知识。然后顺嘴提到了应该门当户对，不只是能力，还有三观，阶层之类的。接着说道，我条件还行，为啥这么晚谈恋爱，是不是打游戏了？我说姐，没毛病，游戏真好玩！又接着问我单身多久了，身边还有没有介绍的呀，同事父母啥的资源。接着就进入正题了，就说小弟弟你呀，身边没有资源，姐姐这里有呀，你又有点慢热，男人花期这么短，这不得抓紧时间。你没谈就是没有遇到合适的人，圈子太小，北京这边初婚太晚了，25岁才准备开始，你想想四川重庆那边20左右就开始准备结婚了，你回去那就是大龄青年了，不是市场上最合适的那一批了。姐姐之前认识一个大哥，一年给女生花了七八万，环球影城去哈尔滨各种礼物砸下去结果手都没牵上。我？？？这不是大冤种嘛，移动ATM。红娘就跟我说，弟弟你啊，现在这恋爱能力，跟女生比划比划半年结果嘴都亲不上，咱们也不要浪费时间，选对人比胡乱去试强多了。姐姐我这啊，适合你的资源还蛮多的呀，你是B站来的资源，这种比较少，一般只占15%，我们婚介所大部分都是线下和国企政府合作的，所以需要你提供一定的身份和征信资料，因为我们这的姑娘都是认证过的，要对大家负责。接着又说觉得我性格比较好，很坦诚，就问我对女生有没有什么要求，我说年龄上不超过我三岁吧，不抽烟不去酒吧夜店，然后红娘跟我说，你这就没别的要求啦，那还挺低的，然后就问我三观、家庭情况之类的要求，问的很细。然后谈笑间，红娘给我猛推三个女生，嘎嘎读资料，听得哥们心里发慌，动不动就是大厂，家里有矿，问女生条件是否符合我的要求.......我真蚌埠住了，哥们真的配嘛，这条件谷歌，父母地方小领导或者开公司，问我符不符合，好好好，我能傍富婆不？

有一说一，专业红娘就是能聊，我俩聊了得有一小时，最后说让我去线下谈，给我预约了她明早10点半的时间。她想要了解下我这个人的衣着品位、谈吐举止、再做下深度的了解，以及一些信息的认证，同时也给我一些情感上的建议，让我少走些弯路。哥们听到情感上的建议，真的心动了，教练，俺就缺这个，确认了下这次聊天不收钱，就是个单纯的信息认证，我就决定去了。

小雨霖霖的春日午前

因为约好的时间是10点半，我住在石景山，婚介所在朝外SOHO那里，差不多一小时十几分钟的路程，我就九点出发了。到了地方之后，周围有好几个SOHO，没有明显指示牌，而且感觉周日早上那里人也少，当时就觉得奇怪了。因为事前的时候，跟亲友和群里的小伙伴下过军令状，不掏一分钱，实时播报进度，没消息就赶紧救我，所以我倒也没有特别慌。我的想法就很纯粹，想通过红娘的眼睛来认识我在相亲市场中是什么样的，因为我接触的人相对少嘛，所以也算是练练胆，特别是这种情感上的，多积累积累经验总没错。没找到地方，我就拍了个附件的标识给红娘老师，她就指挥我上了楼，上楼之后还蛮吓人的，左边黑的，右边就她家灯亮的。

进门之后有个助理来接待，给了我一张表单去填，相对详细哈，但是身-份-证这敏感信息可以选择不填，其实这会儿我觉得还挺不错，放下了防备，但是打开了录音，哈哈。把我领到一个逼仄的会议室，大概两平米吧，首先给我拍了一张坐着的照片，然后在我填表的时候，说要看下我的征信，简单点的就看芝麻信用就行，看了我的八百多分吧，就说你这还蛮高的。又试探性的问了能不能看下花呗借呗之类的，我寻思着也没多少额度，那就看呗，他一看就挺奇怪的，就说按你这个分数应该有好几万才对呀，你是自己调了吗？我说是呀，没事搞那么多干啥，又问我有没有信用卡，我说就拿花呗当信用卡。又说想看我支付宝里的资产，我寻思着没几个钱，那就看呗。他一看就说，你没炒基金股票啥的嘛，我说没，他就顺着话说，昨天有个姑娘和你一样，也是这样的，她就喜欢这种稳赚不赔的。浅聊了一下就说，去给我叫红娘老师，说红娘老师特别看重我，昨天周六来了好多姑娘，很多都不错的，让我跟红娘老师好好学学。哥们一听这个就来劲了，好啊，就是要这个，我不就缺这套恋爱情商嘛。

热情似火的夏日狂欢

红娘老师进来首先点评了我的头发，有点长还有点凌乱，说怎么还没理发呀。这一点说的挺对，我快一个月没理了，因为头发烫过，又有点长，显得乱。然后又说我好白呀，南方人皮肤就是好，因为我有痘痘嘛，就聊了聊油性皮肤。然后就跟我说想看看我短发的照片，说比较难想象我短发的照片，又说我这个是不是渣男锡纸烫，认出来了我这是前刺发型，感谢我的四川托尼，摩根前刺音容犹在。然后又说我字写的还不错，我说着就没必要硬夸了吧，她说跟其他人对比算是工整了。因为看到我手机壳了，就问我是个什么图案，我给她看了是二次元，她就问我是不是老爱玩B站，是不是博主，我说我哪是啊，只是喜欢看。她就说你声音还蛮好听的有点像肖战，可以整点视频啥的，说不定还能火。我说没那颜值，哈哈，谈笑间我就给她发了几张我的生活照，还有全身照片。她就说没有很胖呀，看着还好，而且家里还蛮干净的，弟弟习惯不错。

我也比较能说嘛，我就说红娘老师怎么不开个号啥的，吐吐槽啥的，比如B站上的XX说媒啥的。她跟我说她们上班很忙的，周一周二休息，平时都是快九点才下班，哪有时间开视频吐槽，都是朋友之间聊聊。然后她就很好奇我之前电话里说的前对象嘛，就聊了聊我前对象的事。因为我是抱着想要咨询的目的来的，所以我也说的相对比较详细，红娘比较在意的点是各阶段时间点、怎么认识的、告白怎么做的、准备了什么样的礼物和GG的理由。大致说了一遍，我觉得我前女友挺好的，无奈博主高攀不上，也没有达到人家的期望，就选择了默默退出。前女友说实话很不错的，情侣头像是我先换她才换的，我说话她也会回我，是我感觉被甩了，也是她有点冷吧，就放弃了。说这些呢，也是跟前面一样，说一下兄弟们要勇敢冲，掘金相亲角也靠谱，哪有那么多渣女，大部分还是好女孩，希望大家都把握得住，找到合适的另一半！

红娘老师跟我说了几个之前来聊的哥们，就说谈恋爱不能太晚，有一些大哥因为圈子比较小，导致来婚介所就想找个合适的姑娘一步到位。但是哪有这么合适的呀，一点攻略和目标都没有，怎么可能一口吃个胖子！我也附和老师说，对啊，心急吃不了热豆腐。然后就跟我说，昨天来了两哥们，一个京东一个百度的，还有00年来找对象的，我一听都懵了，这不都是人中龙凤嘛，这还愁对象，有没有大厂哥们来现身说法的，让小弟我长长见识。聊着聊着，就跟我看了个小姐姐，大四左右吧，想找个大五岁左右工作稳定的哥们，本身条件很优秀的，北交大硕士进国企，所以想要个稳定的生活。反正红娘老师意识就是说，现在女生吧，恋商普遍比男生多个三五年，现在这么卷，考虑得都比较现实。然后就说现在女生都是要求有钱有颜，小弟弟你也没钱，正在发展期嘛，颜的话还算周正，需要打理打理。然后就说想看看我之前的照片，要看我手机，emmm，这时候我没发现这是个套路，应该之前有哥们也做过这事儿。我有开录音嘛，左上角有小标，很烦，红娘应该是特意盯了这个地方，一开始问我怎么不给她看手机，而是直接发给她。我也没在意，她就老找理由看我手机，然后我也不小心被她看见了，她就问我是不是忘了关导航，哈哈，我打了个马虎眼就过了，然后后面过了一阵又看到了，就直接问我是不是录音。我非常坦诚的告诉她就是在录音，有顾虑，然后我也当着她面关了，我俩嘻嘻哈哈也就把这事过了。

想要摸一下秋天的老虎

聊了聊我的家庭，跟我聊了聊她最近咨询过的男生，有成功也有失败案例，反正都是会员。比较隐晦地指出了我这个水平在北京不够看，在成都也不算特别优秀地类型，但是结合家庭和年龄来讲，也算是还不错，至少还有操作空间。我一开始就想知道我在婚恋市场是个什么档次，以及从红娘视角来看我是什么样的，所以我就直球问她了。或许是基于职业素养，或者我问的有点子收费味道了，她顿了一下，从两方面给了我建议，一是从我初恋这段历程总结出来的，说我就是没有技巧的纯爱战士，需要提高情商，反正套话居多。二是不要乱撒网，要精准定位，选择自己合适的人，基于星座啥的跟我聊了半天，我这金牛座适合什么样的人。然后就说我这个改是来不及了，27也不小了，没救了，就从选对人开始，然后就开始围绕她们的服务开始聊。

总共聊了得有三小时左右吧，前一个半小时唠家常，根据你的资料聊细节，时不时说说女生的资料。后面就开始猛攻，围绕中介所的两项核心服务，一是心动女生匹配筛选，二是全程跟踪指导，结合真实案例开始跟我介绍。比如女生这个，真的是拿了五六份女生的资料，就跟简历似的，问我有没有眼缘，又跟我说这几天来了什么什么姑娘，有还没毕业的，有点子真实案例掺点焦虑的感觉。比如全程指导，给我看了她手下成功的案例，放了点截图和视频啥的，让我看效果。

中间插一下哈，聊聊我对红娘的看法，真的很强。能干这行的都是社牛，还有很强的气场，我确实能感觉出来她是很快乐地在撮合，觉得是在做正确的事，收的钱理所应当。说真的，要不是我去之前就抱着分文不出的想法，她一顿吹我真给了，业务能力太强了。她聊天的话，目的性很强，总是往婚介服务，这个筛选方向去带，会弱化你的劣势，不会很明显地贬低你，但也不会特别夸耀你的长处，就把你当作一个朋友一样，所有都是围绕我们能给你找一个天造地设的对象这一核心点展开。说实在的，动不动认个亲弟弟这操作也太骚了，见面第一次，这社交强度直接拉满，很热情。

聊聊收费啥的，好像每个人都不一样，给我的标准是1年49990，半年29990，3个月19990，后面我说不用了，拉扯半小时，认我做亲弟弟，然后给我亲属价对赌协议，先交10100等成功了再补9890或者给她介绍2个就不用给尾款了。最后博主一是领导在催干活，嘎嘎电话，朋友在催吃饭，也微信电话不停，就想润了，红娘就说要不先交500定金，不行再退，我确实没这想法，就发了50红包给姐买奶茶。反正这吃相一出来就有点尬住了，我这确实是很好说话，没有一甩脸子直接走了，就这么耗着。说实在的，我确实觉得人家说了3小时，这总得有点收益，50块钱在北京不是什么大钱，但是我本来也是抱着聊聊的想法，没想到上来就这么狠，直接2W起步，真恐怖，润了润了。

又到了白色相簿的季节

最后聊聊博主的收获，有用信息不多哈，大部分是一些套话，这大概就是免费内容吧。她给我看了客户的跟踪记录，红娘会全程指导男生的行为，会推一些书或者情感内容啥的，当然，这都是收费内容。怎么说呢，这一次三小时的激烈battle，我也能感觉出来，我还是该在情商上做一些提升，红娘有提到男女之间的情商和朋友之间的情商是两码事，说我上一次挂了就是技巧不足，竟然半年连嘴都没亲，这还是人？？？跟我说她们那里的都是一个月速通，我这样的已经没救了，好好好，这年头纯爱战士就是鲨BEE。

我其实对这家婚介所没啥意见，我也是想着既然聊上了那就去看看呗，没想到第一次这强度就这么大，哈哈，离谱。我看了下女生资源都很不错，男生也很厉害，都是人中龙凤，不知真假。XX爱恋，她跟我说主要还是线下，我的资料是从B站过去的，就离谱，不知道我填啥了，一开始就知道我的性别年龄和手机号，其他一概不知，可能是我资料被卖了吧，根据年龄给我推送的。喔，对了，说是每周给政府或者国企办公益相亲会，我之前倒是没怎么了解，不知道她家是不是在北京属于厉害的了，还是纯诈骗，摸不清楚，这也是我没交钱的理由之一。因为我在B站上看过XX说媒嘛，我就问她，怎么不开个自媒体号吐吐槽，还能挣点外快。哈哈，这姐非常真实，说剪辑、化妆、文案太累了，线下就够赚了，没必要混线上。

写着写着，突然想起来这姐还说过我一个坏毛病，说我没有底线，有点舔狗，女生一般不喜欢姿态放低的男生，希望我有点神秘感，或者说装一点。哈哈，下一个更好，咱们有的是资源，看得出姐是相当洒脱，成年人不改变只选择这话倒是诠释的清清楚楚。还说我应该有个底，不要一上来就跟人托底，比如她一看我就是个逗比的人，结果跟我一聊还真是个嘻嘻哈哈的乐天派，这样就没有神秘感，她说女生一般不太喜欢这种。

最后的最后，她把经理叫来了，做个回访，我是很欣赏红娘老师的，因为我这次没谈成业绩我也是相当抱歉，所以当着经理面说了很多红娘的好话，没有谈成也确实是我的问题。哈哈，经理直接问我，免费给我介绍同意不，我都懵了，这太狠了，我也没答应，这种形式还是太超前了。相亲说实话还是摆条件，看见女生资料搁面前一遍遍刷，人中龙凤太多啦，哈哈，不由得想起了我初恋也就是我前对象，我也得好好努力呀！

锵锵！我闪亮登场！

今天突然想到，好像真是在B站一个UP那里填过资料的，是我错怪人家了。红娘这姐姐挺有意思的，我是真的觉得她干这行很快乐，她还问我对这行有没有兴趣，哈哈。这种撮合有情人就能收钱的事可太行了，我也蛮喜欢这种做好事的感觉。不过骗人的也不少，315曝光过了，大家也长个心眼吧，学会识人。

最后做个总结吧，博主从昨年开始琢磨男女大事，经历了人生第一次相亲会、初恋、婚介所，虽然都只有一次，但都是挺有意思的。哎，母胎SOLO真的太难了，不会谈啊，盲目冲锋的纯爱战士真的不是版本答案了，红娘老师也跟我说，女生感情上比男生早熟三四年以上，难难难，但是博主依旧对生活抱有期望，哈哈，毕竟我是个乐子人。

我的人生信条是，我要让这痛苦压抑的世界绽放幸福快乐之花，向美好的世界献上祝福！！！

写作背景

写背景之前先放一张网图，侵删。

有一个活跃应用包含了2个相似业务场景，所以共用了底层模型。

1. 前期在开发过程中，强行将两波研发组正在研发的产品底层模型和能力统一。底层能力统一遇到了挺多问题，比如数据库字段适配、转换、冗余；repo 层 SQL 条件拼接用了大量 if else，导致建索引困难…等等。


2. 一些历史原因，该应用经手了十多个研发，代码是垒了又垒，出现一个很有规律的现象，大家都是只增代码不减代码。


3. 代码性能随着数据规模增加不断降低，靠着优化补丁缝缝补补支撑着，业务高峰期经常被运维同学拿着 SQL 光顾。

重构该项目想法不止10次，想逮着机会拉着各方大佬商讨重构事项，因为重构对业务是没有收益的，并且重构难度相当大，所以迟迟没有下定决心。

最近刚好产品需要打磨下一个版本，需要挺长时间，几个后端研发商讨要不重构吧。嗯，我想可以，于是我找上前端负责人沟通拉他入伙，找上前端之前测试已经同意了。

于是一场重构拉开序幕了。

1. A 同学负责梳理和收敛模型、数据订正、向上提供能力。


2. B 同学负责梳理前端接口，编排底层能力，提供原子接口给前端(最复杂，直接面向Web端业务，接口有很多特殊逻辑）。


3. C 同学负责引擎层，和一些计算类逻辑，另外就是打打杂。

重构

大型重构耗时不说还费人力，搞不好重构完你拿不到业务结果，所以重构前你要明确收益是啥？无非就是下面几种

1. 性能提升产品体验更好；


2. 简化架构并提升架构扩展性（后面迭代基于重构后架构能快速开发上线）；


3. 历史债清理，历史代码可读性差维护费劲(大部分程序员看别人代码都是这样吧）。

我们是三种情况都中，下面简单总结重构的思路吧。

模型梳理和能力收敛

底层模型我认为最重要，要可靠、稳定且变动少，如果在迭代中你的模型变来变去，上层业务根本开发不了或者边开发边改，到项目收尾就是另一坨屎山。

上层业务是根据底层模型长出来的，所以一定要跟产品讨论确定最终模型，若有好的竞品参考更好了，你的设计可能会看的更远，以防过度设计，架构设计满足未来1-2年迭代即可。

模型设计需要预估数据规模，数据规模决定是否采用分库分表/分区表。如果不好预估采用简单原则先上线看看业务效果，但基础框架这些能力一定要预留好，上量后能快速开发上线。

底层模型和能力收敛了，上层业务编排对能力的复用性更高。ps：这次模型梳理我们干掉了 2 张千万级表。

数据订正

模型梳理和收敛一般会涉及数据订正，特指线上模型对应的数据割接在新模型。一般会有下面几种方式

1. 写脚本从数据库捞数据订正数据，一般会先 select 查询到内存中，重新组装数据再 insert 新模型。数据量小场景完全可行，但数据量大是跑不动（已踩过坑，线上数据几天没跑完最后发布失败）。


2. 写 SQL 直接操作数据表，简单的数据处理场景、数据量小场景可行，数据量大场景不可靠，容易超时并且会有数据库稳定性风险，另外订正逻辑复杂是搞不定的（已踩过坑，线上跑数据失败导致发布失败）。


3. oplog、binlog.... 日志采集同步到消息队列（kafka、pulsar 等），启消费组消费订正数据（我最常用也是最可靠的），数据量大的场景特别爽，处理存量数据的同时还能保证增量数据同步处理。

数据订正是清理过期数据最佳时期。假若平台过期数据体量大，这部分数据不迁移新表，留在历史表中当备份就行，亦可快速恢复。ps：本次重构过期数据预估是千万级别。

API 接口

接口是你对外的门面，应该提前规划明确，不能新增需求就干一个接口，需求迭代到后期，大大小小接口加起来几十上百个维护成本是很高的。

我们一般会按照下面几个原则：

1. 按操作分类比如：增、删、改、查是一类，只会定义4个接口上游业务方调用需传入 source 区分调用源。


2. 接口保持简洁，不耦合非当前业务的复杂数据。比如业务上需要回显组织架构数据（员工名称、部门、员工上级等），这类数据需要业务方自行编排组织架构 byids 接口。


3. 接口具备降级能力，不能因为接口内部编排的非重要接口、逻辑报错导致整个接口不可用。
   降级指将某些业务或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。

这次重构 B 同学和前端面临了巨大压力，接口多、混乱、逻辑不清晰，决定梳理业务逻辑按照上面 3 个原则重写接口。

代码重构技巧

代码重构也是本次重构重点，经过长时间迭代已经闻到了坏代码味道。怎么重构早就心中有数，很早就盘点和推演了，下面是我常用的一些重构技巧，这些技巧都是非常经典的，如果看过「重构改善既有代码设计」应该都不陌生。

内联临时变量

项目里有一些临时变量，只被简单赋值了一次。将这些临时变量的赋值语句直接嵌入到使用它们的地方，而不是创建一个新的变量来存储这个临时值。

func Publish() error {

  // ... 省略一部分代码

	err = Producer(context.TODO()).ProducerOne(&obj)

	if err != nil {

		return err

	}

	return nil

}

临时变量内联改造后👇👇👇

func Publish() error {

   // ... 省略一部分代码

	return Producer(context.TODO()).ProducerOne(&obj)

}

魔幻数字"（Magic Number）

指代码中使用未经解释或定义的常数值，这些值通常没有命名并且没有给出其含义或用途。这样的数字使代码难理解和维护，项目里面很多魔幻数字使用。

func Update(ids []string, nodeID string) {

	// ... 省略一部分代码

	Report(context.TODO(), nodeID, "6", ids)

}

要解决魔幻数字比较简单，只需你把业务逻辑理解定义成枚举就可以了，这个数字6表示朋友圈类型，魔幻数字改造后👇👇👇

type TargetType int



const (

	QWMoment TargetType = 6

)



func Update(ids []string, nodeID string) {

	// ... 省略一部分代码

	Report(context.TODO(), nodeID, QWMoment, ids)

}

删除注释、未引用代码「俗称死代码」

根据我 review 代码的经验，不少研发同学会把已注释、未引用代码保留，这部分代码是非常影响后面维护者思路的，我们在重构过程中遇到不少这类代码，来来回回找测试和研发确认为什么会保留，哪些业务常用在用？带来了不小负担。（尤其是越上层的死代码引用了一堆下层代码，比如controller 引用 service，service 再引用 repo ，若重写 repo 非常上头）

所以我强烈建议，一旦代码不用了，应该立刻删除。若删除这部分代码后面迭代可能会使用，我建议重新开发。我列一些删除代码后的收益。

1. 清晰度和简洁性；


2. 减少维护成本；


3. 减少冗余和混乱；


4. 避免误导。

卫语句取代条件表达式

卫语是用来提前结束方法执行的结构。通常情况下，卫语句用来检查某些前置条件是否满足，如果条件不满足，则立即退出方法执行，以避免进入后续的代码块。有助于减少代码嵌套深度，增加代码的可读性和可维护性。

按照我的经验，卫语句应该有下面 2 种情况：

1. 两个条件分支都属于正常行为；


2. 有一个条件分支是正常行为，另一个分支则是异常的情况。

我们review过的代码一般是第二种情况比较严重。

func Recall(exclusion constant.ExclusionType)error  {

	if exclusion == constant.OnlyOneExec {

		if detail.TargetID == "" {

			return nil

		}

		_, err := repo.Update(ctx,....)

		if err != nil {

			return xerrors.Wrapf(err, "Update")

		}

	}

	return nil

}

调整后代码👇👇👇

func Recall(exclusion constant.ExclusionType)error  {

	if exclusion != constant.OnlyOneExec {

		return nil

	}



	if detail.TargetID == "" {

		return nil

	}

	_, err := repo.Update(ctx,....)

	return err

}

变量改名

好的命名能让读者一目了然，变量名可以很好的解释一段代码干了什么。我发现项目里面很多字段名、类名、包名很模糊，很难理解具体的业务（包括我自己也经常命名错）。

下段代码是我整理的坏的命名

TaskCommand 是 Kafka 消费者依赖的实体，收到消息后根据 Type 和 Status 撤回数据。但你看 struct 名 跟撤回没有任何关系。

// TaskCommand 任务相关命令

type TaskCommand struct {

	Type   int8 `json:"type"`   // 执行类型

	Status int8 `json:"status"` 

}

所以我选择把 TaskCommand 替换成跟业务更贴切的名称👇👇👇

type RecallDataParam struct {

	Type   int8 `json:"type"` // 执行类型

	Status int8 `json:"status"`

}

引入参数对象

以一个对象取代一些参数，可以改善代码的可读性和维护性，尤其是在函数参数列表较长或者参数之间存在复杂关系的情况下。将一组相关的参数封装到一个对象中，将该对象作为函数的参数传递，简化函数签名并提高代码的清晰度。

在一些历史比较久的代码里过长参数真的很常见，从 controller 透传到 service 再透传到 repo 层，代码复用性也非常低。

type AppImpl struct {

}



func (app *AppImpl) List(tp []int, status, page, pageSize int, keyword string, domain string) ([]interface{}, error) {

	// .... 省略业务逻辑

	return nil, nil

}

上段代码我一般会在 controller 和 service 中间抽一个 dto 实体。👇👇👇

type AppImpl struct {

}



func (app *AppImpl) List(listDTO *ListDTO) ([]interface{}, error) {

	// .... 省略业务逻辑

	return nil, nil

}



type ListDTO struct {

	tp                     []int

	status, page, pageSize int

	keyword, domain        string

}

提炼类

一个类应该是一个明确的抽象，它的职责是单一的，只处理一些明确的职责。

提炼类一般是下面两种情况

1. 需求是在不停变化和累加，你会这儿加一个函数，那儿加一个方法。导致某些文件或者类非常臃肿。


2. 相似的能力，散落在不同的业务板块，涉及的开发都在重复建设，有一个需求建一个烟囱。

典型案例是项目中事件上报能力，本应该是一个通用能力集中收敛上报代码，据我梳理代码散落在多处，上报触点有 10 来个，每个触点都在写同样的上报代码，假设某一天上报逻辑变化必须在这 10 多处做出许多小修改。

所以我决定把上报能力收敛在一个类，将复杂逻辑封装到该类，定义有限参数露出给使用方。

上报通用能力封装在 EventTracking。👇👇👇

// Tracker 埋点上报接口

type Tracker[T any] interface {

	EventTracking(in T) error

}



type CMSReachDTO struct {

}



type CMSReachTracking[T any] struct {

	ctx context.Context

}



func NewCMSReachTracking[T any](ctx context.Context) Tracker[*CMSReachDTO] {

	return &CMSReachTracking[T]{ctx: ctx}

}



func (t *CMSReachTracking[T]) EventTracking(in *CMSReachDTO) error {

	// ....逻辑省略



	return nil

}

提炼超类

如果两个类在做相似的事，可以利用基本的继承/组合（GO 只有组合）机制把它们的相似之处提炼到超类。一般会把字段、方法都搬移过去。

我遇到的 case 在 entity 上会多一些，比如下面这两个 struct。

type Task struct {

	ID           string `gorm:"column:id"`

	Tenant       string `gorm:"column:tenant"`

	SubDomain    string `gorm:"column:sub_domain"`

	IsDel        int8   `gorm:"column:is_del;default:1" `

	CreateAt     int64  `gorm:"column:create_at;autoCreateTime:milli"`

	UpdateAt     int64  `gorm:"column:update_at;autoUpdateTime:milli"`

	CreateUserID string `gorm:"column:create_uid"`

	UpdateUserID string `gorm:"column:update_uid"`

   // ... 省略其他字段

}



type TaskDetail struct {

	ID           string `gorm:"column:id"`

	TargetID     string `gorm:"column:target_id"`

	Tenant       string `gorm:"column:tenant"`

	SubDomain    string `gorm:"column:sub_domain"`

	IsDel        int8   `gorm:"column:is_del;default:1" `

	CreateAt     int64  `gorm:"column:create_at;autoCreateTime:milli"`

	UpdateAt     int64  `gorm:"column:update_at;autoUpdateTime:milli"`

	CreateUserID string `gorm:"column:create_uid"`

	UpdateUserID string `gorm:"column:update_uid"`

   // ... 省略其他字段

}

上面这段代码他们都有共性的代码，并且我非常熟悉业务是不可能更改的，所以我会提炼一个超类。👇👇👇

type SuperParty struct {

	Tenant       string `gorm:"column:tenant"`

	SubDomain    string `gorm:"column:sub_domain"`

	IsDel        int8   `gorm:"column:is_del;default:1" `

	CreateAt     int64  `gorm:"column:create_at;autoCreateTime:milli"`

	UpdateAt     int64  `gorm:"column:update_at;autoUpdateTime:milli"`

	CreateUserID string `gorm:"column:create_uid"`

	UpdateUserID string `gorm:"column:update_uid"`

}



type Task struct {

	ID string `gorm:"column:id"`

	SuperParty

	// ... 省略其他字段

}



type TaskDetail struct {

	ID       string `gorm:"column:id"`

	TargetID string `gorm:"column:target_id"`

	SuperParty

	// ... 省略其他字段

}

当然某些场景还有一些配套的方法，也可以一并搬迁到 SuperParty 里面。

提炼方法/函数

提炼函数/方法是我常用的一种手段，我不喜欢长函数/方法。我看过一个说法，一个函数/方法应该能在一屏中显示，我一直奉为经典语录（我写的代码函数/方法基本不会超过一百行）；另外只要有一段代码不止被用一次，我就会把他们单独放进一个函数。

有这样一个场景，调用外部 byids 查询员工信息获取 externalId 执行业务逻辑，封装外部接口调用。

type Client struct {

	ctx context.Context

}



func (c *Client) GetByIDs(id []string) ([]*User, error) {

    // ....省略业务逻辑

	return []*User{}, nil

}



type User struct {

	ID         string `json:"id"`

	ExternalID string `json:"externalId"`

}

下面是业务方使用 GetByIDs() 方法

func TestGetUserByIDs(t *testing.T) {

	ids := []string{"1", "2"}

        

	client := &Client{}

	users, err := client.GetByIDs(ids)

	if err != nil {

		panic(err)

	}



	l := make([]string, 0, len(users))

	for _, v := range users {

		l = append(l, v.ExternalID)

	}



	// ...执行业务逻辑

}

 业务方调用 GetByIDs() 方法，遍历 users 获取 ExternalID 执行业务逻辑。在业务上这种操作还真不少，所以决定优化复用一部分代码。👇👇👇

1. 定义 Users 切片。


2. GetByIDs() 方法返回 Users。


3. Users 提供 GetExternalIDs 方法。

type Client struct {

	ctx context.Context

}



func (c *Client) GetByIDs(id []string) (Users, error) {

    // .... 省略业务逻辑

	return Users{}, nil

}



type Users []*User



func (u Users) GetExternalIDs() []string {

	out := make([]string, 0, len(u))

	for _, v := range u {

		out = append(out, v.ExternalID)

	}



	return out

}



type User struct {

	ID         string `json:"id"`

	ExternalID string `json:"externalId"`

}

下面是业务方使用 GetByIDs() 方法

func TestGetUserByIDs(t *testing.T) {

	ids := []string{"1", "2"}

        

	client := &Client{}

	users, err := client.GetByIDs(ids)

	if err != nil {

		panic(err)

	}



	l := users.GetExternalIDs()

	// 执行业务逻辑

   // ....

}

代码空行

我非常非常不喜欢代码从头到尾写下来没有任何空行，难以阅读让读者很难提起兴趣。空行在我看来是必不可少的，在代码中使用空行来分隔不同功能或逻辑块之间的代码，空行使得代码更易读。

下面段代码是没有任何空行的，代码比较短阅读起来可能并不费劲。

适当进行空行优化后👇👇👇

上段代码先不关注逻辑，优化后可读性更强了，代码分为3段逻辑，每段逻辑都有各自的职责。

空行是用来区分不同逻辑块的，过度空行也会影响代码阅读，如下：

引入设计模式

设计模式是被大佬们验证过的、开发经验的总结，可以帮助我们更好地组织和管理代码，并提高代码的可维护性、可读性、可扩展性和可重用性。下面链接是我最常用的设计模式，也在这次重构过程中全部用上了，有兴趣可以看看。

最后总结

1. 如果你的项目不是外包项目（交付了就完事儿），一定要多回头看看自己写的代码，跟着版本迭代持续优化和改进，你才能进步。另外对代码一定要有洁癖。


2. 重构是持续的过程，如果是重要项目，每个版本我们都会推进代码优化，保证代码可维护性、可扩展性、另外就是高性能。千万别堆积最后，那可是大工程到后面很多人是没有决心干这个事儿的，所以大家应该平时迭代中不断优化和完善，才可持续性。


3. 大型重构时，一定要明确收益并且是可量化的，比如重构后 qps 提升了10%，应用消耗资源降低了…等等，你才有跟老板谈判的筹码。

大家好 👋🏻, 新的一年即将开始, 我不想错过这个机会, 与大家分享一篇题为《2024年的安卓现代开发》的文章. 🚀

如果你错过了我的上一篇文章, 可以看看2023年的安卓现代开发并回顾一下今年的变化.

免责声明

📝 本文反映了我的个人观点和专业见解, 并参考了 Android 开发者社区中的不同观点. 此外, 我还定期查看 Google 为 Android 提供的指南.

🚨 需要强调的是, 虽然我可能没有明确提及某些引人注目的工具, 模式和体系结构, 但这并不影响它们作为开发 Android 应用的宝贵替代方案的潜力.

Kotlin 无处不在 ❤️

Kotlin是由JetBrains开发的一种编程语言. 由谷歌推荐, 谷歌于 2017 年 5 月正式发布(查看这里). 它是一种与 Java 兼容的现代编程语言, 可以在 JVM 上运行, 这使得它在 Android 应用开发中的采用非常迅速.

无论你是不是安卓新手, 都应该把 Kotlin 作为首选, 不要逆流而上 🏊🏻 😎, 谷歌在 2019 年谷歌 I/O 大会上宣布了这一做法. 有了 Kotlin, 你就能使用现代语言的所有功能, 包括协程的强大功能和使用为 Android 生态系统开发的现代库.

请查看Kotlin 官方文档

Kotlin 是一门多用途语言, 我们不仅可以用它来开发 Android 应用, 尽管它的流行很大程度上是由于 Android 应用, 我们可以从下图中看到这一点.

KotlinConf ‘23

Kotlin 2.0 要来了

另一个需要强调的重要事件是Kotlin 2.0的发布, 它近在眼前. 截至本文发稿之日, 其版本为 2.0.0-beta4

新的 K2 编译器 也是 Kotlin 2.0 的另一个新增功能, 它将带来显著的性能提升, 加速新语言特性的开发, 统一 Kotlin 支持的所有平台, 并为多平台项目提供更好的架构.

请查看 KotlinConf '23 的回顾, 你可以找到更多信息.

Compose 🚀

Jetpack Compose 是 Android 推荐的用于构建本地 UI 的现代工具包. 它简化并加速了 Android 上的 UI 开发. 通过更少的代码, 强大的工具和直观的 Kotlin API, 快速实现你的应用.

• Jetpack Compose 文档

Jetpack Compose 是 Android Jetpack 库的一部分, 使用 Kotlin 编程语言轻松创建本地UI. 此外, 它还与 LiveData 和 ViewModel 等其他 Android Jetpack 库集成, 使得构建具有强反应性和可维护性的 Android 应用变得更加容易.

Jetpack Compose 的一些主要功能包括

资源:

• Jetpack Compose 文档


• Compose 与 Kotlin 的兼容性图谱


• Jetpack Compose 路线图


• 课程


• Jetpack Compose 中@Composable的API 指南

Android Jetpack ⚙️

Jetpack是一套帮助开发者遵循最佳实践, 减少模板代码, 编写在不同Android版本和设备上一致运行的代码的库, 这样开发者就可以专注于他们的业务代码.

_ Android Jetpack 文档

其中最常用的工具有:

• ViewModel


• Room


• DataStore


• WorkManager


• Navigation


• CameraX


• Compose


• Media3


• Glance

Material You / Material Design 🥰

Material You 是在 Android 12 中引入并在 Material Design 3 中实现的一项新的定制功能, 它使用户能够根据个人喜好定制操作系统的视觉外观. Material Design 是一个由指南, 组件和工具组成的可调整系统, 旨在坚持UI设计的最高标准. 在开源代码的支持下, Material Design 促进了设计师和开发人员之间的无缝协作, 使团队能够高效地创造出令人惊叹的产品.

目前, Material Design 的最新版本是 3, 你可以在这里查看更多信息. 此外, 你还可以利用Material Theme Builder来帮助你定义应用的主题.

代码仓库

使用 Material 3 创建主题

SplashScreen API

Android 中的SplashScreen API对于确保应用在 Android 12 及更高版本上正确显示至关重要. 不更新会影响应用的启动体验. 为了在最新版本的操作系统上获得一致的用户体验, 快速采用该 API 至关重要.

Clean架构

Clean架构的概念是由Robert C. Martin提出的. 它的基础是通过将软件划分为不同层次来实现责任分离.

特点

依赖规则

作者在他的博文Clean代码中很好地描述了依赖规则.

依赖规则是使这一架构得以运行的首要规则. 这条规则规定, 源代码的依赖关系只能指向内部. 内圈中的任何东西都不能知道外圈中的任何东西. 特别是, 外圈中声明的东西的名称不能被内圈中的代码提及. 这包括函数, 类, 变量或任何其他命名的软件实体.

• 博文Clean代码

安卓中的Clean架构:

Presentation 层: Activitiy, Composable, Fragment, ViewModel和其他视图组件.
Domain层: 用例, 实体, 仓库接口和其他Domain组件.
Data层: 仓库的实现类, Mapper, DTO 等.

Presentation层的架构模式

架构模式是一种更高层次的策略, 旨在帮助设计软件架构, 其特点是在一个可重复使用的框架内为常见的架构问题提供解决方案. 架构模式与设计模式类似, 但它们的规模更大, 解决的问题也更全面, 如系统的整体结构, 组件之间的关系以及数据管理的方式等.

在Presentation层中, 我们有一些架构模式, 我想重点介绍以下几种:

• MVVM


• MVI

我不想逐一解释, 因为在互联网上你可以找到太多相关信息. 😅

此外, 你还可以查看应用架构指南.

依赖注入

依赖注入是一种软件设计模式, 它允许客户端从外部获取依赖关系, 而不是自己创建依赖关系. 它是一种在对象及其依赖关系之间实现控制反转(IoC)的技术.

• Hilt ❤️


• Dagger


• Koin

模块化

模块化是一种软件设计技术, 可将应用划分为独立的模块, 每个模块都有自己的功能和职责.

模块化的优势

可重用性: 拥有独立的模块, 就可以在应用的不同部分甚至其他应用中重复使用.

严格的可见性控制: 模块可以让你轻松控制向代码库其他部分公开的内容.

自定义交付: Play特性交付 使用应用Bundle的高级功能, 允许你有条件或按需交付应用的某些功能.

可扩展性: 通过独立模块, 可以添加或删除功能, 而不会影响应用的其他部分.

易于维护: 将应用划分为独立的模块, 每个模块都有自己的功能和责任, 这样就更容易理解和维护代码.

易于测试: 有了独立的模块, 就可以对它们进行隔离测试, 从而便于发现和修复错误.

改进架构: 模块化有助于改进应用的架构, 从而更好地组织和结构代码.

改善协作: 通过独立的模块, 开发人员可以不受干扰地同时开发应用的不同部分.

构建时间: 一些 Gradle 功能, 如增量构建, 构建缓存或并行构建, 可以利用模块化提高构建性能.

更多信息请参阅官方文档.

网络

• OkHttp


• Retrofit


• Ktor

序列化

在本节中, 我想提及两个我认为非常重要的工具: 与 Retrofit 广泛结合使用的Moshi, 以及 JetBrains 的 Kotlin 团队押宝的Kotlin Serialization.

• Moshi


• Kotlin Serialization

Moshi 和 Kotlin Serialization 是用于 Kotlin/Java 的两个序列化/反序列化库, 可将对象转换为 JSON 或其他序列化格式, 反之亦然. 这两个库都提供了友好的接口, 并针对移动和桌面应用进行了优化. Moshi 主要侧重于 JSON 序列化, 而 Kotlin Serialization 则支持包括 JSON 在内的多种序列化格式.

图像加载

要从互联网上加载图片, 有几个第三方库可以帮助你处理这一过程. 图片加载库为你做了很多繁重的工作; 它们既处理缓存(这样你就不用多次下载图片), 也处理下载图片并将其显示在屏幕上的网络逻辑.

_ 官方安卓文档

• Coil


• Glide

响应/线程管理

说到响应式编程和异步进程, Kotlin协程凭借其suspend函数和Flow脱颖而出. 然而, 在 Android 应用开发中, 承认 RxJava 的价值也是至关重要的. 尽管协程和 Flow 的采用率越来越高, 但 RxJava 仍然是多个项目中稳健而受欢迎的选择.

对于新项目, 请始终选择Kotlin协程❤️. 可以在这里探索一些Kotlin协程相关的概念.

本地存储

在构建移动应用时, 重要的一点是能够在本地持久化数据, 例如一些会话数据或缓存数据等. 根据应用的需求选择合适的存储选项非常重要. 我们可以存储键值等非结构化数据, 也可以存储数据库等结构化数据. 请记住, 这一点并没有提到我们可用的所有本地存储类型(如文件存储), 只是提到了允许我们保存数据的工具.

建议:

• S̶h̶a̶r̶e̶d̶P̶r̶e̶f̶e̶r̶e̶n̶c̶e̶s̶


• DataStore


• EncryptedSharedPreferences

测试 🕵🏼

软件开发中的测试对于确保产品质量至关重要. 它能检测错误, 验证需求并确保客户满意. 下面是一些最常用的测试工具::

• JUnit 5


• Mockk


• Kotest


• Kluent


• Turbine


• Espresso


• Robolectric


• Maestro

工具文档的测试部分

截屏测试 📸

Android 中的截屏测试涉及自动捕获应用中各种 UI 元素的屏幕截图, 并将其与基线图像进行比较, 以检测任何意外的视觉变化. 它有助于确保不同版本和配置的应用具有一致的UI外观, 并在开发过程的早期捕捉视觉回归.

• Paparazzi


• Roborazzi

R8 优化

R8 是默认的编译器, 可将项目的 Java 字节码转换为可在 Android 平台上运行的 DEX 格式. 通过缩短类名及其属性, 它可以帮助我们混淆和减少应用的代码, 从而消除项目中未使用的代码和资源. 要了解更多信息, 请查看有关 缩减, 混淆和优化应用 的 Android 文档. 此外, 你还可以通过ProGuard规则文件禁用某些任务或自定义 R8 的行为.

• 代码缩减


• 缩减资源


• 混淆


• 优化

第三方工具

• DexGuard

Play 特性交付

Google Play 的应用服务模式称为动态交付, 它使用 Android 应用Bundle为每个用户的设备配置生成并提供优化的 APK, 因此用户只需下载运行应用所需的代码和资源.

• Android 文档

自适应布局

随着具有不同外形尺寸的移动设备使用量的增长, 我们需要一些工具, 使我们的 Android 应用能够适应不同类型的屏幕. 因此, Android 为我们提供了Window Size Class, 简单地说, 就是三大类屏幕格式, 它们是我们开发设计的关键点. 这样, 我们就可以避免考虑许多屏幕设计的复杂性, 从而将可能性减少到三组, 它们是 Compat, Medium和Expanded.

Window Size Class

支持不同的屏幕尺寸

我们拥有的另一个重要资源是Canonical Layout, 它是预定义的屏幕设计, 可用于 Android 应用中的大多数场景, 还为我们提供了如何将其适用于大屏幕的指南.

其他相关资源

• 2022 年谷歌 I/O 大会形式因素的三件事


• 播放列表: 2022 年谷歌 I/O 大会上的Form-Factor

Form-Factor培训

本地化 🌎

本地化包括调整产品以满足不同地区不同受众的需求. 这包括翻译文本, 调整格式和考虑文化因素. 其优势包括进入全球市场, 增强用户体验, 提高客户满意度, 增强在全球市场的竞争力以及遵守当地法规.

注: BCP 47 是安卓系统使用的国际化标准.

参考资料

• 支持不同语言和文化


• 本地化应用


• 每个应用的语言首选项


• 每个应用的语言偏好 - 第一部分


• 每个应用的语言偏好 - 第二部分

性能 🔋⚙️

在开发 Android 应用时, 我们必须确保用户体验更好, 这不仅体现在应用的开始阶段, 还体现在整个执行过程中. 因此, 我们必须使用一些工具, 对可能影响应用性能的情况进行预防性分析和持续监控:

• 基准


• 基准配置文件


• 应用启动


• Firebase 性能监控


• JankStats 库

应用内更新

当你的用户在他们的设备上不断更新你的应用时, 他们可以尝试新功能, 并从性能改进和错误修复中获益. 虽然有些用户会在设备连接到未计量的连接时启用后台更新, 但其他用户可能需要提醒才能安装更新. 应用内更新是 Google Play 核心库的一项功能, 可提示活跃用户更新你的应用*.

运行 Android 5.0(API 等级 21)或更高版本的设备支持应用内更新功能. 此外, 应用内更新仅支持 Android 移动设备, Android 平板电脑和 Chrome OS 设备.

- 应用内更新文档

应用内评论

Google Play 应用内评论 API 可让你提示用户提交 Play Store 评级和评论, 而无需离开你的应用或游戏.

一般来说, 应用内评论流程可在用户使用应用的整个过程中随时触发. 在流程中, 用户可以使用 1-5 星系统对你的应用进行评分, 并添加可选评论. 一旦提交, 评论将被发送到 Play Store 并最终显示出来.

*为保护用户隐私并避免 API 被滥用, 你的应用应严格遵守有关何时请求应用内评论和评论提示的设计的规定.

- 应用内评论文档

可观察性 👀

在竞争日益激烈的应用生态系统中, 要获得良好的用户体验, 首先要确保应用没有错误. 确保应用无错误的最佳方法之一是在问题出现时立即发现并知道如何着手解决. 使用 Android Vitals 来确定应用中崩溃和响应速度问题最多的区域. 然后, 利用 Firebase Crashlytics 中的自定义崩溃报告获取更多有关根本原因的详细信息, 以便有效地排除故障.

工具

• 谷歌分析


• Android Vitals


• Firebase Crashlytics


• Firebase 性能监控

辅助功能

辅助功能是软件设计和构建中的一项重要功能, 除了改善用户体验外, 还能让有辅助功能需求的人使用应用. 这一概念旨在改善的不能包括: 有视力问题, 色盲, 听力问题, 灵敏性问题和认知障碍等.

考虑因素:

• 增加文字的可视性(颜色对比度, 可调整文字大小)


• 使用大而简单的控件


• 描述每个UI元素

更多详情请查看辅助功能 - Android 文档

安全性 🔐

在开发保护设备完整性, 数据安全性和用户信任的应用时, 安全性是我们必须考虑的一个方面, 甚至是最重要的方面.

• 使用凭证管理器登录用户: 凭据管理器 是一个 Jetpack API, 在一个单一的 API 中支持多种登录方法, 如用户名和密码, 密码匙和联合登录解决方案(如谷歌登录), 从而简化了开发人员的集成.


• 加密敏感数据和文件: 使用EncryptedSharedPreferences 和EncryptedFile.


• 应用基于签名的权限: 在你可控制的应用之间共享数据时, 使用基于签名的权限.

android="http://schemas.android.com/apk/res/android"

    package="com.example.myapp">

    name="my_custom_permission_name"

                android:protectionLevel="signature" />

• 不要将密钥, 令牌或应用配置所需的敏感数据直接放在项目库中的文件或类中. 请使用local.properties.


• 实施 SSL Pinning: 使用 SSL Pinning 进一步确保应用与远程服务器之间的通信安全. 这有助于防止中间人攻击, 并确保只与拥有特定 SSL 证书的受信任服务器进行通信.

res/xml/network_security_config.xml

"1.0" encoding="utf-8"?>

<network-security-config>

    <domain-config>

        <domain includeSubdomains="true">example.comdomain>

        <pin-set expiration="2018-01-01">

            <pin digest="SHA-256">ReplaceWithYourPinpin>

            

            <pin digest="SHA-256">ReplaceWithYourPinpin>

        pin-set>

    domain-config>

network-security-config>

• 实施运行时应用自我保护(RASP): 这是一种在运行时保护应用免受攻击和漏洞的安全技术. RASP 的工作原理是监控应用的行为, 并检测可能预示攻击的可疑活动:
  
  
  
  
  • 代码混淆.
  
  
  • 根检测.
  
  
  • 篡改/应用钩子检测.
  
  
  • 防止逆向工程攻击.
  
  
  • 反调试技术.
  
  
  • 虚拟环境检测
  
  
  • 应用行为的运行时分析.
  
  
  
  

想了解更多信息, 请查看安卓应用中的运行时应用自我保护技术(RASP). 还有一些 Android 安全指南.

版本目录

Gradle 提供了一种集中管理项目依赖关系的标准方式, 叫做版本目录; 它在 7.0 版中被试验性地引入, 并在 7.4 版中正式发布.

优点:

• 对于每个目录, Gradle 都会生成类型安全的访问器, 这样你就可以在 IDE 中通过自动补全轻松添加依赖关系.


• 每个目录对构建过程中的所有项目都是可见的. 它是声明依赖项版本的中心位置, 并确保该版本的变更适用于每个子项目.


• 目录可以声明 dependency bundles, 即通常一起使用的 "依赖关系组".


• 目录可以将依赖项的组和名称与其实际版本分开, 而使用版本引用, 这样就可以在多个依赖项之间共享一个版本声明.

请查看更多信息

Secret Gradle 插件

Google 强烈建议不要将 API key 输入版本控制系统. 相反, 你应该将其存储在本地的 secrets.properties 文件中, 该文件位于项目的根目录下, 但不在版本控制范围内, 然后使用 Secrets Gradle Plugin for Android 来读取 API 密钥.

日志

日志是一种软件工具, 用于记录程序的执行信息, 重要事件, 错误调试信息以及其他有助于诊断问题或了解程序运行情况的信息. 日志可配置为将信息写入不同位置, 如日志文件, 控制台, 数据库, 或将信息发送到日志记录服务器.

• Klogging


• Timber

Linter / 静态代码分析器

Linter 是一种编程工具, 用于分析程序源代码, 查找代码中的潜在问题或错误. 这些问题可能是语法问题, 代码风格不当, 缺乏文档, 安全问题等, 它们会对代码的质量和可维护性产生影响.

• Android Lint


• Detekt ⏫


• Ktlint ⏫


• Konsist

Google Play Instant

Google Play Instant 使本地应用和游戏无需安装即可在运行 Android 5.0(API 等级 21)或更高版本的设备上启动. 你可以使用 Android Studio 构建这类体验, 称为即时应用和即时游戏. 通过允许用户运行即时应用或即时游戏(即提供即时体验), 你可以提高应用或游戏的发现率, 从而有助于吸引更多活跃用户或安装.

• Google Play Instant 概述

新设计中心

安卓团队提供了一个新的设计中心, 帮助创建美观, 现代的安卓应用, 这是一个集中的地方, 可以了解安卓在多种形态因素方面的设计.

点击查看新的设计中心

人工智能

Gemini和PalM 2是谷歌开发的两个最先进的人工智能(AI)模型, 它们将改变安卓应用开发的格局. 这些模型具有一系列优势, 将推动应用的效率, 用户体验和创新.

• Gemini


• PalM 2

人工智能编码助手工具

Studio Bot

Studio Bot 是你的 Android 开发编码助手. 它是 Android Studio 中的一种对话体验, 通过回答 Android 开发问题帮助你提高工作效率. 它采用人工智能技术, 能够理解自然语言, 因此你可以用简单的英语提出开发问题. Studio Bot 可以帮助 Android 开发人员生成代码, 查找相关资源, 学习最佳实践并节省时间.

Studio Bot

Github Copilot

GitHub Copilot 是一个人工智能配对程序员. 你可以使用 GitHub Copilot 直接在编辑器中获取整行或整个函数的建议.

Amazon CodeWhisperer

这是亚马逊的一项服务, 可根据你当前代码的上下文生成代码建议. 它能帮助你编写更高效, 更安全的代码, 并发现新的 API 和工具.

Kotlin Multiplatform 🖥 📱⌚️ 🥰 🚀

最后, 同样重要的是, Kotlin Multiplatform 🎉 是本年度最引人注目的新产品. 它是跨平台应用开发领域的有力竞争者. 虽然我们的主要重点可能是 Android 应用开发, 但 Kotlin Multiplatform 为我们提供了利用 KMP 框架制作完全本地 Android 应用的灵活性. 这一战略举措不仅为我们的项目提供了未来保障, 还为我们提供了必要的基础架构, 以便在我们选择多平台环境时实现无缝过渡. 🚀

如果你想深入了解 Kotlin Multiplatform, 我想与你分享这几篇文章. 在这些文章中, 探讨了这项技术的现状及其对现代软件开发的影响:

• Kotlin Multiplatform - 是这样的


• Kotlin Multiplatform的现状 - 2023年网络研讨会

前一段时间在做一些H5页面，需求中落地页占比较大，落地页承担的职责就是引流。引流有两种形式，同时也是我们对唤端的定义：引导已下载用户打开APP，引导未下载用户下载APP。

引导已下载用户打开APP，从数据上说用户停留在APP中的时间更多了，是在提高用户粘性；从体验上说，APP体验是要比H5好的。引导未下载用户下载APP，可以增加我们的用户量。

上面其实分别解释了 什么是唤端 以及 为什么要唤端，也就是 3W法则 中的 What 和 Why，那么接下来我们就要聊一聊 How 了，也就是 如何唤端 。

我们先来看看常见的唤端方式以及他们适用的场景：

唤端媒介

URL Scheme

来源

我们的手机上有许多私密信息，联系方式、照片、银彳亍卡信息...我们不希望这些信息可以被手机应用随意获取到，信息泄露的危害甚大。所以，如何保证个人信息在设备所有者知情并允许的情况下被使用，是智能设备的核心安全问题。

对此，苹果使用了名为 沙盒 的机制：应用只能访问它声明可能访问的资源。但沙盒也阻碍了应用间合理的信息共享，某种程度上限制了应用的能力。

因此，我们急需要一个辅助工具来帮助我们实现应用通信， URL Scheme 就是这个工具。

URL Scheme 是什么

我们来看一下 URL 的组成：

[scheme:][//authority][path][?query][#fragment]

我们拿 https://www.baidu.com 来举例，scheme 自然就是 https 了。

就像给服务器资源分配一个 URL，以便我们去访问它一样，我们同样也可以给手机APP分配一个特殊格式的 URL，用来访问这个APP或者这个APP中的某个功能(来实现通信)。APP得有一个标识，好让我们可以定位到它，它就是 URL 的 Scheme 部分。

常用APP的 URL Scheme

URL Scheme 语法

上面表格中都是最简单的用于打开 APP 的 URL Scheme，下面才是我们常用的 URL Scheme 格式：

     行为(应用的某个功能)    

            |

scheme://[path][?query]

   |               |

应用标识       功能需要的参数

Intent

安卓的原生谷歌浏览器自从 chrome25 版本开始对于唤端功能做了一些变化，URL Scheme 无法再启动Android应用。 例如，通过 iframe 指向 weixin://，即使用户安装了微信也无法打开。所以，APP需要实现谷歌官方提供的 intent: 语法，或者实现让用户通过自定义手势来打开APP，当然这就是题外话了。

Intent 语法

intent:

   HOST/URI-path // Optional host 

   #Intent; 

      package=[string]; 

      action=[string]; 

      category=[string]; 

      component=[string]; 

      scheme=[string]; 

   end;

如果用户未安装 APP，则会跳转到系统默认商店。当然，如果你想要指定一个唤起失败的跳转地址，添加下面的字符串在 end; 前就可以了:

S.browser_fallback_url=[encoded_full_url]

示例

下面是打开 Zxing 二维码扫描 APP 的 intent。

intent:

   //scan/

   #Intent; 

      package=com.google.zxing.client.android; 

      scheme=zxing; 

   end; 

打开这个 APP ，可以通过如下的方式：

 <a href="intent://scan/#Intent;scheme=zxing;package=com.google.zxing.client.android;S.browser_fallback_url=http%3A%2F%2Fzxing.org;end"> Take a QR code a>

Universal Link

Universal Link 是什么

Universal Link 是苹果在 WWDC2015 上为 iOS9 引入的新功能，通过传统的 HTTP 链接即可打开 APP。如果用户未安装 APP，则会跳转到该链接所对应的页面。

为什么要使用 Universal Link

传统的 Scheme 链接有以下几个痛点：

• 在 ios 上会有确认弹窗提示用户是否打开，对于用户来说唤端，多出了一步操作。若用户未安装 APP ，也会有一个提示窗，告知我们 “打不开该网页，因为网址无效”


• 传统 Scheme 跳转无法得知唤端是否成功，Universal Link 唤端失败可以直接打开此链接对应的页面


• Scheme 在微信、微博、QQ浏览器、手百中都已经被禁止使用，使用 Universal Link 可以避开它们的屏蔽（ 截止到 18年8月21日，微信和QQ浏览器已经禁止了 Universal Link，其他主流APP未发现有禁止 ）

如何让 APP 支持 Universal Link

有大量的文章会详细的告诉我们如何配置，你也可以去看官方文档，我这里简单的写一个12345。

Universal Link 配置中的坑

这里放一下我们在配置过程中遇到的坑，当然首先你在配置过程中必须得严格按照上面的要求去做，尤其是加粗的地方。

如何调用三种唤端媒介

<iframe src="sinaweibo://qrcode">

<a href="intent://scan/#Intent;scheme=zxing;package=com.google.zxing.client.android;end"">扫一扫</a>

// 一般情况下是 visibilitychange 

const visibilityChangeProperty = getVisibilityChangeProperty();

const timer = setTimeout(() => {

  const hidden = isPageHidden();

  if (!hidden) {

    cb();

  }

}, timeout);



if (visibilityChangeProperty) {

  document.addEventListener(visibilityChangeProperty, () => {

    clearTimeout(timer);

  });



  return;

}



window.addEventListener('pagehide', () => {

  clearTimeout(timer);

});

<script src="https://unpkg.com/callapp-lib"></script>

Mysql中Varchar(50)和varchar(500)区别是什么?

一. 问题描述

我们在设计表结构的时候,设计规范里面有一条如下规则:

• 对于可变长度的字段，在满足条件的前提下，尽可能使用较短的变长字段长度。

为什么这么规定,我在网上查了一下,主要基于两个方面

• 基于存储空间的考虑


• 基于性能的考虑

网上说Varchar(50)和varchar(500)存储空间上是一样的,真的是这样吗?

基于性能考虑,是因为过长的字段会影响到查询性能?

本文我将带着这两个问题探讨验证一下

二.验证存储空间区别

1.准备两张表

CREATE TABLE `category_info_varchar_50` (

  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',

  `name` varchar(50) NOT NULL COMMENT '分类名称',

  `is_show` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否展示：0 禁用，1启用',

  `sort` int(11) NOT NULL DEFAULT '0' COMMENT '序号',

  `deleted` tinyint(1) DEFAULT '0' COMMENT '是否删除',

  `create_time` datetime NOT NULL COMMENT '创建时间',

  `update_time` datetime NOT NULL COMMENT '更新时间',

  PRIMARY KEY (`id`) USING BTREE,

  KEY `idx_name` (`name`) USING BTREE COMMENT '名称索引'

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='分类';



CREATE TABLE `category_info_varchar_500` (

  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键',

  `name` varchar(500) NOT NULL COMMENT '分类名称',

  `is_show` tinyint(4) NOT NULL DEFAULT '0' COMMENT '是否展示：0 禁用，1启用',

  `sort` int(11) NOT NULL DEFAULT '0' COMMENT '序号',

  `deleted` tinyint(1) DEFAULT '0' COMMENT '是否删除',

  `create_time` datetime NOT NULL COMMENT '创建时间',

  `update_time` datetime NOT NULL COMMENT '更新时间',

  PRIMARY KEY (`id`) USING BTREE,

  KEY `idx_name` (`name`) USING BTREE COMMENT '名称索引'

) ENGINE=InnoDB AUTO_INCREMENT=288135 DEFAULT CHARSET=utf8mb4 COMMENT='分类';

2.准备数据

给每张表插入相同的数据,为了凸显不同,插入100万条数据

DELIMITER $$

CREATE PROCEDURE batchInsertData(IN total INT)

BEGIN

    DECLARE start_idx INT DEFAULT 1;

    DECLARE end_idx INT;

    DECLARE batch_size INT DEFAULT 500;

    DECLARE insert_values TEXT;

    

    SET end_idx = LEAST(total, start_idx + batch_size - 1);

	

    WHILE start_idx <= total DO

        SET insert_values = '';

        WHILE start_idx <= end_idx DO

            SET insert_values = CONCAT(insert_values, CONCAT('(\'name', start_idx, '\', 0, 0, 0, NOW(), NOW()),'));

            SET start_idx = start_idx + 1;

        END WHILE;

        SET insert_values = LEFT(insert_values, LENGTH(insert_values) - 1); -- Remove the trailing comma

        SET @sql = CONCAT('INSERT INTO category_info_varchar_50 (name, is_show, sort, deleted, create_time, update_time) VALUES ', insert_values, ';');

        

        PREPARE stmt FROM @sql;

        EXECUTE stmt;

	SET @sql = CONCAT('INSERT INTO category_info_varchar_500 (name, is_show, sort, deleted, create_time, update_time) VALUES ', insert_values, ';'); 

	PREPARE stmt FROM @sql;

        EXECUTE stmt;

    

        SET end_idx = LEAST(total, start_idx + batch_size - 1);

    END WHILE;

END$$

DELIMITER ;



CALL batchInsertData(1000000);

3.验证存储空间

查询第一张表SQL

SELECT

    table_schema AS "数据库",

    table_name AS "表名",

    table_rows AS "记录数",

    TRUNCATE ( data_length / 1024 / 1024, 2 )  AS "数据容量（MB）",

    TRUNCATE ( index_length / 1024 / 1024, 2 )  AS "索引容量（MB）" 

FROM

    informati0n—schema.TABLES 

WHERE

    table_schema = 'test_mysql_field' 

		and TABLE_NAME = 'category_info_varchar_50'

ORDER BY

    data_length DESC,

    index_length DESC;

查询结果

查询第二张表SQL

SELECT

    table_schema AS "数据库",

    table_name AS "表名",

    table_rows AS "记录数",

    TRUNCATE ( data_length / 1024 / 1024, 2 )  AS "数据容量（MB）",

    TRUNCATE ( index_length / 1024 / 1024, 2 )  AS "索引容量（MB）" 

FROM

    informati0n—schema.TABLES 

WHERE

    table_schema = 'test_mysql_field' 

		and TABLE_NAME = 'category_info_varchar_500'

ORDER BY

    data_length DESC,

    index_length DESC;

查询结果

4.结论

两张表在占用空间上确实是一样的,并无差别

三.验证性能区别

1.验证索引覆盖查询

select name from category_info_varchar_50 where name = 'name100000'

-- 耗时0.012s

select name from category_info_varchar_500 where name = 'name100000'

-- 耗时0.012s

select name from category_info_varchar_50 order by name;

-- 耗时0.370s

select name from category_info_varchar_500 order by name;

-- 耗时0.379s

通过索引覆盖查询性能差别不大

1.验证索引查询

select * from category_info_varchar_50 where name = 'name100000'

--耗时 0.012s

select * from category_info_varchar_500 where name = 'name100000'

--耗时 0.012s

select * from category_info_varchar_50 where name in('name100','name1000','name100000','name10000','name1100000',

'name200','name2000','name200000','name20000','name2200000','name300','name3000','name300000','name30000','name3300000',

'name400','name4000','name400000','name40000','name4400000','name500','name5000','name500000','name50000','name5500000',

'name600','name6000','name600000','name60000','name6600000','name700','name7000','name700000','name70000','name7700000','name800',

'name8000','name800000','name80000','name6600000','name900','name9000','name900000','name90000','name9900000') 

-- 耗时 0.011s -0.014s 

-- 增加 order by name 耗时 0.012s - 0.015s



select * from category_info_varchar_50 where name in('name100','name1000','name100000','name10000','name1100000',

'name200','name2000','name200000','name20000','name2200000','name300','name3000','name300000','name30000','name3300000',

'name400','name4000','name400000','name40000','name4400000','name500','name5000','name500000','name50000','name5500000',

'name600','name6000','name600000','name60000','name6600000','name700','name7000','name700000','name70000','name7700000','name800',

'name8000','name800000','name80000','name6600000','name900','name9000','name900000','name90000','name9900000') 

-- 耗时  0.012s -0.014s 

-- 增加 order by name 耗时 0.014s - 0.017s

索引范围查询性能基本相同, 增加了order By后开始有一定性能差别;

3.验证全表查询和排序

全表无排序

全表有排序

select * from category_info_varchar_50 order by  name ;

--耗时 1.498s

select * from category_info_varchar_500 order by  name  ;

--耗时 4.875s

结论:

全表扫描无排序情况下,两者性能无差异,在全表有排序的情况下, 两种性能差异巨大;

分析原因

varchar50 全表执行sql分析

我发现86%的时花在数据传输上,接下来我们看状态部分,关注Created_tmp_files和sort_merge_passes

Created_tmp_files为3

sort_merge_passes为95

varchar500 全表执行sql分析

增加了临时表排序

Created_tmp_files 为 4

sort_merge_passes为645

关于sort_merge_passes, Mysql给出了如下描述:

Number of merge passes that the sort algorithm has had to do. If this value is large, you may want to increase the value of the sort_buffer_size.

其实sort_merge_passes对应的就是MySQL做归并排序的次数，也就是说，如果sort_merge_passes值比较大，说明sort_buffer和要排序的数据差距越大，我们可以通过增大sort_buffer_size或者让填入sort_buffer_size的键值对更小来缓解sort_merge_passes归并排序的次数。

四.最终结论

至此,我们不难发现,当我们最该字段进行排序或者其他聚合操作的时候,Mysql会根据该字段的设计的长度进行内存预估, 如果设计过大的可变长度, 会导致内存预估的值超出sort_buffer_size的大小, 导致mysql采用磁盘临时文件排序,最终影响查询性能;

大家好，我卡颂。

最近，华为开源了一款前端框架 —— openInula。根据官网提供的信息，这款框架有3大核心能力：

2. 兼容ReactAPI

🐱前言

每次一到节假日，都好想和好朋友们一起出去玩，但是心里总放不下家里的小猪咪，于是心想能不能找一个喂养师上门喂养呢。于是找了几个上门喂养的平台，并最终下单了服务。

真的不得不说，上门喂养的小姐姐真的非常用心和专业。她们来到我家期间，全情投入地照顾着我的毛孩子，让它吃得饱饱的，看起来胖乎乎的。更令我感动的是，她们还全程录像了照料过程，并将视频发送给我，让我能够时刻了解小猪咪的情况。

分享下小猪咪美照👇

🤔️思考

我也是程序员，为什么我不能自己也做一个上门喂养的小程序呢，于是经过调研，发现了其他的几个平台各有各的弊端和优点，然后诞生出了最初的想法如何做一个把其他平台的弊端去除掉，做一个最好的上门喂养平台。

🎨开始设计

于是开始琢磨figma～～～

因为任何c端都是通过首页再去衍生出其他页面整体样式的，所以先着手制作首页，只要首页定好了其他页面都好说。

一周后....开始着手设计🤔️...思考...参考....初版定稿

由于刚入门设计一开始丑丑的，不忍直视～～～

再经过几天的琢磨思考...改版...最终确定首页

经过不断的练习琢磨参考最后定稿，给大家推荐下我经常参考我素材网站花瓣

N天之后......其他页面陆续出炉

由于页面太多了就不一一展示啦～～～

最满意的设计页面

给各大掘友分享一下我最满意的设计页面

签到

结合了猫咪的元素统一使用了同一只猫咪素材～整体效果偏向手绘风格。

抽奖扭蛋

这个扭蛋机真是一笔一画画了一天才出来的，真的哭😭啦～，由于AE动画太过麻烦所以每一个扭蛋球球的滚动都用代码去实现～～

💻编程

技术选型

uniapp + nestjs + mysql

NestJS是一个基于Node.js的开发框架，它提供了一种构建可扩展且模块化的服务端应用程序的方式，所以对于前端而言是最好上手的一门语法。

Nestjs学习推荐

给各大掘友推荐一下本人从0到1上手nestjs的教程，就是一下小册就是以下这本，初级直接上手跟着写一遍基本就会啦

建议学习到 61章左右就可以开始写后端项目啦

小程序端基本使用逻辑

• 用户下单-服务人员上门服务完成-用户检查完成后确认订单完成-订单款项打款到服务人员钱包


• 用户注册成为服务人员-设置服务范围-上线开始服务-等待用户给服务人员下单

下单流程

选择服务地点-选择服务人员-点击预约-添加服务宠物-付款

服务人员认证流程

根据申请流程逐步填写，由于服务人员是平台与用户产生信任的标准，所以我们加大了通过审核的门槛，把一些只追求利益，而不是真正热爱宠物的人员拒之门外，保护双方利益。

后端Nestjs部署

后端代码写完之后我们需要把服务部署到腾讯云，以下是具体步骤

1.腾讯云创建镜像仓库

前往腾讯云创建容器镜像服务，这样我们就可以把本地docker镜像推送到腾讯云中了，这个容器镜像服务个人版是免费的

2.打包Nestjs

通过执行docker命令部署到本地的docker

👇以下是具体docker代码

FROM --platform=linux/amd64 node:18-alpine3.14 as build-stage



WORKDIR /app



COPY package.json .

COPY cert .

COPY catdogship.com_nginx .

COPY ecosystem.config.js .



RUN npm config set registry https://registry.npmmirror.com/



RUN npm install



COPY . .



# 第一个镜像执行 build

RUN npm run build



# FROM 继承 node 镜像创建一个新镜像

FROM --platform=linux/amd64 node:18-alpine3.14  as production-stage



# 通过 COPY --from-build-stage 从那个镜像内复制 /app/dist 的文件到当前镜像的 /app 下

COPY --from=build-stage /app/package.json /app/package.json

COPY --from=build-stage /app/ecosystem.config.js /app/ecosystem.config.js



COPY --from=build-stage /app/dist /app/src/

COPY --from=build-stage /app/cert /app/cert/

COPY --from=build-stage /app/public /app/public/

COPY --from=build-stage /app/static /app/static/

COPY --from=build-stage /app/catdogship.com_nginx /app/catdogship.com_nginx/



WORKDIR /app



# 切到 /app 目录执行 npm install --production 只安装 dependencies 依赖

RUN npm install --production



RUN npm install pm2 -g



EXPOSE 443



CMD ["pm2-runtime", "/app/ecosystem.config.js"]

3.推送到腾讯云

本地打包完成之后我们需要把本地的docker推送到腾讯云中，所以我们本地写一个sh脚本执行推送

#!/bin/bash



# 生成当前时间

timestamp=$(date +%Y-%m-%d-%H-%M)



# Step 1: 构建镜像

docker build -t hello:$timestamp .



# Step 2: 查找镜像的标签

image_id=$(docker images -q hello:$timestamp)



# Step 3: 为镜像添加新的标签

docker tag $image_id 你的腾讯云镜像地址:$timestamp



docker push 你的腾讯云镜像地址:$timestamp

4.部署到服务器

由于我使用的是轻量级应用服务器，所以直接使用自动化助手去进行部署（PS：可能有一些小伙伴会问为什么用轻量级应用服务器呢，因为目前用户量不是很多，轻量级应用服务器足够支撑，后面用户量起来会考虑转为k8s集群）

然后我们去创建一个自动化执行命令，去执行服务器的docker部署

创建命令

执行命令

👇以下是命令代码

# 停止服务

docker stop hello



# 删除容器

docker rm hello



# 拉取镜像

docker pull 你的腾讯云镜像地:{{key}}



#读取image名称

image_id=$(docker images -q 你的腾讯云镜像地:{{key}})



# 运行容器

docker run -d -p 443:443 -e TZ=Asia/Shanghai --name hello $image_id 

5.部署完成

命令返回执行结果显示执行完成，说明已经部署成功了

6.Nestjs服务器端的管理

由于node是一个单线程，所以我们使用的是pm2去进行管理node，它可以把node变成一个多线程并进行管理

由于nestjs中使用到了定时任务，而定时任务只需要开一条线程去做就好了，所以我增加了一个环境变量NODE_ENV来对定时任务进行管理

module.exports = {

  apps: [

    {

      name: 'wx-applets',

      // 指定要运行的应用程序的入口文件路径

      script: '/app/src/main.js',

      exec_mode: 'cluster',

      // 集群模式下的实例数-启动了2个服务进程

      instances: 4,

      // 如果设置为 true，则避免使用进程 ID 为日志文件添加后缀

      combine_logs: true,

      // 如果服务占用的内存超过300M，会自动进行重启。

      // max_memory_restart: '1000M',

      env: {

        NODE_ENV: 'production',

      },

    },

    {

      name: 'wx-applets-scheduled-tasks',

      script: '/app/src/main.js',

      instances: 1,

      // 采用分叉模式，创建一个单独的进程

      exec_mode: 'fork',

      env: {

        NODE_ENV: 'tasks',

      },

    },

  ],

};

后端总结

到目前为止前台的业务接口都写完了做了个统计一共有179个接口

后期版本更新

预计这个月上线毛孩子用品盲盒抽奖，有兴趣的友友们也可关注下哦

后期展望，帮助更多的流浪动物有一个温暖的家

小程序上线

目前小程序已经上线啦～，友友们可以前往小程序搜索 喵汪舰 前往体验，
或者扫描一下二维码前往

我的学习路线

因为我是一个前端开发，所以对于设计感觉还是挺好的，所以上手比较快。
一条学习建议路线：前端-后端-设计-产品，最终形成了一个完整的产品产出。

以下的链接是这个项目中我经常用到的素材网站：

freepik国外素材网站-可以找到大部份的插画素材

figma自带社区-获取参考的产品素材

花瓣国内素材参考网站-涵盖了国内基本的产品素材

pinterest国外大型素材网-你想到的基本都有

总结

一个产品的产出不仅仅依靠代码，还要好的用户体验，还需要不断的优化迭代，

最后给一起并肩前行的创业者们的一段话：

在创业的道路上，我们正在追逐梦想，挑战极限，为自己和世界创造新的可能性。这个旅程充满了风险和不确定性，但也蕴藏着无限的机遇和成就，不要害怕失败，勇于面对失败，将其视为成功的必经之路。

大家好，我是树哥，好久不见啦。

作为一个工作了 10 多年的开发，写业务代码总是写了不少的。但你想过做到零 bug 吗？我可是想过的，毕竟我还是有点追求的。不然每天都是浑浑噩噩地过，多没意思啊。

大概在一年多前，我给自己立下一个目标 —— 尽量将自己经手的业务需求做到零 bug。不试不知道，一试吓一跳，原来零 bug 还真的还不容易。今天，树哥就跟大家分享关于「业务开发零 bug」的一些思考。

要做到业务开发零 bug，其实挺难的。这涉及到非常多方面，有些方面可能还不只是你能控制的，例如：产品 PRD 详尽程度，产研组织的稳定性等等。经过一段时间的思考与摸索，我自己总结出一些影响因素，分别是：

针对上面说到的影响因素，我们一个个详细聊聊。

需求文档清晰程度

对于研发、测试人员来说，他们获取信息的源头就是产品的 PRD 文档。因此，需求文档是否写得清晰、明确，就显得非常重要。

如果产品自己对功能都不了解，那么输出的需求文档肯定「缺斤少两」，到时候就是边开发边补充需求，甚至是在测试过程中补充需求。遇到这种情况，想要做到零 bug 真的非常难。

因此，清晰明确的需求文档，是我们实现业务开发零 bug 的重要前提。如果这个前提保证不了，那要做到零 bug 真的很难。毕竟想做成啥样都不知道，程序员又不是神仙，咋能猜出你想要什么。但这块内容，更多是对于产品人员专业能力的要求，开发人员无法控制。

在一些公司，会再需求评审之前先对需求文档进行一次初审，筛除那些有明显重大问题的需求，这样可以减少一部分劣质需求。

但初审的作用还是有限的，它没办法对功能的细节做较多的判断。很多时候恰恰就是一些功能细节的缺失，导致了一些 bug 的诞生。

需求的复杂程度

需求的复杂程度，对于实现业务开发零 bug 也有很大的影响。举个简单地例子：一个改文案的需求，和一个完全重新做的功能。

这样的两个需求，其复杂程度差别很大，肯定是改文案的需求实现业务开发零 bug 的难度低很多。对于一个完全重新做的功能，要做到完全零 bug，对于开发人员的要求非常高。

对于越复杂的项目，零 bug 的可能性就越低。因此，很多项目为了追求产出功能的高质量，会采用将功能点拆得非常细的方式，来减少单个需求的复杂度。

笔者公司在去年做过这个尝试，确实是可以较大地提高产出功能的质量。

细心程度

前面说到需求文档的清晰程度很重要，这取决于产品人员对于业务的理解程度，以及对于对于功能的熟悉程度。开发人员的细心，就像是一个质检关卡一样，在开发之前就对产品的需求内容进行详尽的思考与提问。

对于粗心的开发人员来说，其可能不看需求文档就直接参加需求评审，等到开发的时候边写代码边看需求文档，其写得代码也是一边熟悉需求一边改。这样写出来的系统功能是比较差的，没有一个统一、全局的设计与思考，很容易在细节处发生问题。

一个细心的开发人员，其会在评审之前就详细阅读需求文档，甚至会前前后后翻阅好几次。他甚至会逐字逐句地阅读，弄懂每个文字、句子的意思，甚至有时候会让你觉得他是在玩文字游戏（但不得不说，确实有必要细致一些）。

最后会联系上下文思考功能的合理性。如果发现一些不合理的地方，他会积极与产品沟通反馈，以确保其对于需求的理解，与产品经理对于需求的理解是一致的。

通过对比，我们知道细心的开发人员对于产品经理来说，是一个莫大的帮助，可以帮助他查漏补缺，让其对于功能的考虑更加细致、严谨。

这里的开发人员不仅仅指的是后端开发人员，也包括前端开发、移动端开发，他们都会从不同角度提出问题。

对于后端开发人员来说，他们可能会提出性能问题。对于前端开发以及移动端开发同学，他们可能会提出交互问题、样式统一等问题。

简单地说，细心的开发人员可以弥补需求文档的缺陷，从而让大家对于需求的理解更趋于一致，从而减少 bug 的发生。因此，开发人员的细心程度也是决定业务开发能否实现零 bug 的关键因素！

是否详细自测过

即使写过 10 多年代码的开发人员，刷 Leetcode 也不敢说 bug free 一把过，对于更加复杂的业务代码更是如此。因此，要做到业务开发零 bug，其中一个很重要的操作便是 —— 自测。

自测可以帮你再次检查可能出现的问题，从而提高零 bug 的概率。对于我而言，我习惯性在自测的时候再次对照一遍需求文档，从而避免自己遗漏一些功能的细节点。

对于自测而言，业界有很多种自测方法，包括：单测、集成测试、功能测试。一般情况，建议自己选择适合自己的自测方法。

很多时候，功能测试是相对来说性价比较高的方式。除此之外，自测的详细程度也根据实际情况有所不同，例如有些人只会测试正常情况，但有些老手会测试一些边界情况、异常情况。

毫无疑问，你越能像测试人员一样测试，你的提测质量肯定就越高，bug 当然也就越少。

对项目的熟悉程度

这里说的项目熟悉程度，既指技术层面的熟悉程度，也指业务功能层面的熟悉程度。

技术层面的熟悉程度，指的是项目之间是用什么技术栈搭建的，你对这些技术是否都熟悉。举个很简单的例子，项目中采用了微服务的方式进行调用，那么你是否清楚是什么微服务调用？

如果采用了 ElasticSearch 进行搜索，那么你是否对 ElasticSearch 有一些了解，知道一些基本使用及最佳实践？等等。

这些算是技术层面的熟悉程度，你对这些越熟悉，你在技术层面发生问题的可能性就越小。

业务功能层面的熟悉程度，指的是你对项目其他模块的业务是否熟悉。例如你经常负责 A 模块的功能，你对 A 模块肯定很熟悉。

但下个迭代你就要去做 B 迭代的需求了，这时候你肯定不是很熟，相对来说出错的可能性就更大一些。

无论是技术层面，还是业务层面的熟悉程度，都会随着你做了更多的需求，变得更加熟悉。到了后面某个阶段，你基本上就不存在踩坑的问题了，也为你业务开发零 bug 奠定了基础。如果你是一个刚刚进入公司的新手，那么做到零 bug 还是很难的。

开发时间是否充足

开发时间是否充足，决定了你是否有充足的时间去熟悉需求，去和产品经理确定细节。有了充足的时间，你也才能有一定时间去进行更详细的自测。更为关键的一点，有充足的时间，你写代码才能写得更好。因此，开发时间是否充足是很重要的。

在实际的开发过程中，会因为各种各样的原因，其实并没有办法给你留出特别理想的开发时间。这时候该怎么办？有些人选择接受，去压缩自己的时间。

有些人则会选择去沟通，或者协调资源，保证自己有充足的时间。其实，正确的做法还是第二种，这样会更好一些。

这需要开发人员有更强的综合能力（沟通、协调能力），但并不是每个开发人员都具备的。关于这点，又是可以聊的一个话题 —— 当你的需求被压缩工时的时候，你应该怎么做？这里暂不展开，后续有时间可以聊聊。

简单来说，开发时间是基础，没有合理、充足的时间保障的话，要做到业务开发零 bug 是不可能的事情。

总结

要做到业务开发零 bug，其实就是要消除功能开发过程中的所有不确定性，包括：需求功能的不确定性、自己写错代码的不确定性等等。而发生这些不确定性的地方，可能就有：

除了上面说到的 6 个影响业务开发零 bug 的因素之外，肯定还有其他影响因素。

你能想到什么影响业务开发零 bug 的因素吗？欢迎在评论区留言与大家分享。

好了，今天的分享就到此为止，希望大家都能做到业务开发零 bug，业务开发代码一把过！

如果你觉得今天的文章对你有帮助，欢迎点赞转发评论，你的转发对于我很重要，感谢大家！

大家好，我是小趴菜，关于定时任务大家都有接触过，项目中肯定也使用过，只需要在项目中的启动类上加上 @EnableScheduling 注解就可以实现了

现在是单个节点部署，倒是没什么问题。如果是多节点部署呢？

假设现在我们系统要每天给用户新增10积分，那么更新的SQL如下

  update user set point = point + 10 where id = 1;

这时候你的服务部署了两台，那么每一台都会来执行这条更新语句，那么用户的积分就不是+10了。而是+20。

当然这里我们只是举了个例子来引出 @EnableScheduling 的定时任务会存在定时任务重复执行的问题。而且有可能会因为重复执行导致数据不一致的问题

使用数据库乐观锁

在使用乐观锁的时候，首先我们会新增一个字段，也就是更新日期，但是这个更新日期不是指我们修改数据的那个更新时间,比如说今天是2024-03-25,那么到了明天,第一台机器更新成功了，这个值就更新成2024-03-26，其它机器的线程来更新判断这个值是否是2024-03-25,如果不是，说明已经有线程更新了，那么就不需要再次更新了

  update user set point = point + 10,modifyTime = 2023-03-26 where id = 1 and modifyTime = 2024-03-25

基于乐观锁的方式有什么缺点呢？？

现在我们只有两台服务器，那如果有1千台，1万台呢，对于同一条数据的，那么这1万台服务器都会去执行更新操作，但是其实在这1万次更新操作中，只有一次操作是成功的，其余的操作都是不需要执行的

所以使用这种方式当机器数量很多的时候，对数据库的压力是非常大的

分布式锁

我们还可以使用分布式锁的方式来实现，比如要执行这个定时任务之前要先获取一把锁，这个锁是对每一条记录都分别有对应的一把锁

当线程来更新某一条数据的时候，首先要获取这条记录的一个分布式锁，拿到锁了就可以去更新了，没有拿到锁的也不要去等待获取锁了，就直接更新下一条数据即可，同样的步骤，只有拿到某条数据的锁，才可以更新

但是这里有一个注意的点，就是比如服务-1先获取到id=100的这条记录的锁，然后执行更新，但是此时因为某些原因，导致某台服务器过了一会才来执行id=100的这条数据，因为服务-1已经执行完了，所以会释放掉这把锁，所以这台服务器来就能获取到锁，那么也会执行更新操作

所以在更新的时候，还是做一下判断，判断这条记录是否已经被更新了，如果已经更新了，那么就不要再次更新了

分布式锁相对于乐观锁来说，减少了大量的无用的更新操作，但还是会存在极少量的重复更新操作，但是相对来说，对数据库的压力就减少了很多

但是与此同时，这就依赖于Redis，要保证Redis的服务可用

消息队列

我们可以将要更新的数据提前加载到消息队列中去，然后每台服务就是一个消费者，保证一条记录只能让一个消费者消费，这样也就可以避免重复更新的问题了

但是消费失败的记录不要重回队列，可以在数据库记录，让人工进行处理

使用消息队列会有什么问题呢？

如果你的消息数据特别多，比如有上亿条，那么消息队列就会被堆满，，而且每天都要把数据库的数据都加载到消息队列中去

或许有人说，数据量大我可以多弄几个消息队列，这样确实可以解决一个消息队列堆积消息过多的问题，但是你要如何控制某些服务器只访问某个队列呢？不能每台服务都循环获取每一个队列中的消息吧

而且如果你的消息队列是单点的，那么服务宕机那么所有数据都没法更新了，这时候你还要去弄一个集群
，这成本就有点大了

所以不推荐使用这种方式

分布式任务调度-xxl-job

最后就是使用分布式定时任务调度框架 xxl-job了，关于xxl-job的使用大家可以网上自己搜一下资料。

XXL-JOB是一个开源的分布式任务调度框架，它主要用于解决大规模分布式任务的调度和执行问题。该框架提供了任务调度中心、执行器和任务日志等组件，支持任务的定时调度、动态添加和删除、执行情况监控和日志记录等功能。

总结

以上就是为大家提供的定时任务重复执行的解决方案，大家可以根据自己的实际情况来选择不同的方案来实现

说下背景

来公司的第二周，上面下发了新需求，也是我参与公司的第一个项目。

我先说下公司一个项目的大体配置

产品经理 1~2人  一般中小版本就1人

UI      1~2人

研发前端 1~3人 

研发后端 1~5人（包含协同团队）  

   ps:其中后端中1人为项目负责人，负责整体项目进度和协调资源

测试    1~2人

好的，故事由此开始。先铺垫下，该项目是我从业以来最无力最绝望最想扯呼的一个。

需求评审

周一刚来公司，就被公司给我安排的导师L 叫到身边

导师L：「一会儿有个需求评审，我文档先发你，你先抓紧时间看看」

懵懂的我：「好的，我先熟悉下任务」

说实话文档看起来真的有点头疼，主要是上面的一行字我真的无语至极【与线上保持一致】。公司的项目还是比较大的，我上哪儿去了解保持一致是个啥意思......问下导师吧，他也在排查线上问题；问下其他同事吧，也刚来没多久不了解这块业务....

好吧时间应该够，我先打开系统，看看这功能到底在哪里。

「走，A2评审会」 导师L给了我一个眼神

大哥，我才看了不到20分钟，功能我都没看完......

我的情况稍微有点特殊，一般来说，大家跟随导师的节奏，问题都不大

看不懂的需求，一定要整懂了在动手，否则返工风险很大

时间不允许？那要再考虑下该公司是不是适合你了哦！！！总不能说能跑起来就行吧

过程我全程梦游，大家都在提问题：各种数据的兼容方案、功能冲突怎么兼容、有类似功能是否能套用、数据权限是否考虑、特殊逻辑的兜底方案.......

开始还能记一下笔记，后面发现 跟不上，根本跟不上 直接 弃笔，从容 面对现实了

从会议室走出来，嗯~~ 怎么形容心情呢。我高考语文作文那一页名字忘了写出考场都没这么忧虑过（当然作文最后还是有得分）。

分配任务

直接上对话详情，后端加上我一共3人

导师L：「任务我这边大概分配了下，你们先选吧」

我内心很慌，我一个都看不明白要怎么做

不知所措的我：「要不我拿剩下的」

同事P：「那把这个、这个、这个给我吧，剩下的你们分？」

导师L看着我：「那就这样分，你做那个、那个、那个，有问题随时找我」

不知所措的我：「好的，我主要是不熟悉这块业务，有问题我先整理出来再一起问下你呗」

这里有个关键点，整理完问题再一起咨询，切记遇到一个问一个

态度摆正，表现得自信点，第一次在同事面前“刷脸”，印象要留好一些

研发阶段

我的任务主要是客户群统计模块

导师给我开了两个服务的权限，让我先看看代码

懵逼的我：「L哥，要不大概说下在那部分写的统计数据？我应该从哪些表出结果？」

导师L：「你先看代码，里面都有逻辑，你看得懂」

无语的我：「好的」 内心（这么玩儿是吧）

知道那代码有多难懂吗？全都是A队列推到B队列，判断后再推C队列，并且还有了很多观察者模式。可能有兄弟姐妹问：「看不懂注释？」。注释少得可怜，也就一些字段含义，不过看单词也能看出来。

队列和队列之间很难看懂，并且很多跨服务的队列，给我开的两个服务根本不够，前后一共加上4个服务才把统计的逻辑串起来，我还专门画了个流程图出来

不管代码设计和质量如何，作为新人别公开喷前辈的代码

前期不要加入太多个性化的代码和设计，每个公司的要求不一致，最好的方式还是模仿

逻辑复杂的话，建议画一个流程图or时序图，架构图的话还是问下老同事，自己画可能不准确

不要轻易下手编码，确保自己很明确整体逻辑了再跟熟悉的同事复述一遍先

好吧，我终于找到逻辑线了（花了1天半时间，留给我开发的时间很近很近），但我发现，结果表很多很多，有AAA_statistics、BBB_statistics、CCC_statistics...... 我拿不定主意，刚好我也对这几个服务熟悉得差不多了，于是我拿着这些成果去问导师L

诚恳的我：「L哥，帮忙看看这几张表，我感觉有一些数据是重复的，还对不上数，帮忙看看呢？」

导师L：「逻辑都捋清楚了吗？」

我直接掏出了我的流程图

导师L：「这是JW（我们组的TL）给你的吗？」

求知的我：「我自己画的，不晓得准确性怎么样，帮忙check下呢」

导师L：「主要是我这还有点事，你再看看吧，晚点我们过一下」

前期难免会有很多问题，但自己也要有点准备，否则被问成麻瓜，印象分直接拉低

不知道的不要说"不知道"，可以说"我还不太熟悉，我先去看看逻辑，X哥要不跟我说下大概位置或则有啥文档？"

到了晚上7:00左右，我发现L哥不见了，后来才晓得那天他溜得挺早的。只剩我原地爆炸，明天要联调了，我关键的数据组装service还只有一行//TODO。没招了，我按照我的想法和数据指标，找了几张最合适的表，把数据产出了。

第二天

我早早地来公司，重新check了下代码并又调试了几次，除了数据对不上没啥其他问题。导师L带着早饭来到公司，我还等到吃完早饭再去问了下。

疲惫的我：「L哥，你看我用这张统计表去输出功能有问题没？」

导师L：「就那么几张表，你造几条数据不就看出来了」

疲惫的我：「我造了几条数据，但是昨天的数据我看今天才过来，昨天忘了记录过程」

导师L：「怎么可能，你怎么造的数据，算了等会儿我看一下」

......

过程就不细讲了，总之，不好受...... 最后问题也定位到了，是导师L当初做测试，把定时任务往后延了1天。好吧，这还有定时任务的事儿？我只能看代码看到一堆数据同步的接口，真的是应征了那句话：【最怕的是：我不知道我'不知道'】。

时间允许的话，着手开工前还是留一份概要设计的存档，别把坑都留给后面的人了

流程图、时序图、架构图等，前期多花时间，少走弯路

心态摆好，我们是来打工挣钱的，交不交朋友是其次而已，关系不恶化怎么着都行

而后，比较顺利地进行到提测阶段，bug真的是多得要命，主要是以下几点：

1、数据权限没加（就是prd文档上写的跟xxx模块保持一致逻辑）

2、数据同步时好时坏，排查后发现是定时任务不稳定，大家都在一个环境提测版本，都在修改功能

3、未做改造的功能点测出历史bug（功能类似，故测试同学也纳入了测试范围）

4、服务被其他版本覆盖

导致最终版本交付时，我个人产生了大概20+个bug。周五下午TL专门找我谈话，约谈此事，大概意思是版本复杂度不高，但bug数过多，对我的版本质量不满意。对此，我也阐述了我的解释，这里我就不细说解释的话，大概从以下几点去阐述

不要丢锅，先把由自己粗心产生的bug讲一下，记得提一下数据，因自身代码质量产生了X个bug，后续会加强编码质量，多自测

也不要背锅，说下由于环境问题导致了X个bug的产生，并给出自己的建议，是否能做环境隔离，一个环境只能容纳服务不冲突的1~2个版本

注意下，TL直接对话的机会并不是很多，可以结合自身入职以来的经历，提一些建议（不用管是否重要）

总之，事事多总结，否则像这种情况下TL突然找咱们约谈，说不出个123，印象分会很差

项目总结

在项目研发中，不一定能得到公司前辈们的"关照"，这时候就需要先自己憋一下（注意合理安排时间），怎么着也能憋出点内容，那这这些内容再去咨询，效果会好很多。像我这种被孤立的情况，我也不好说是不是常态，我个人还是认为好同事还是居多的。总之还是与同事搞好关系，或者关系一般遇事能帮忙也行，不要跟任何同事把关系闹僵（哪怕脾气差、技术菜、背后勾心斗角）。

还是那句话，遇事不要慌，先调整好心态（道理都看得懂，但希望大家都能做得到），尽力吃透项目再开始施工，否则返工或者低质量产出不好避免。

多做总结，不甩锅不背锅，不管是项目总结还是转正答辩还是晋升答辩，都能有个有条理有依据的总结出来。这点在职场中至关重要。

怎么来定义低谷期？

我觉得真正的低谷期是迷茫，挫败，痛苦，自我怀疑等等，反正一定是比肉体上的痛苦更煎熬！

可能你会觉得暂时性找不到工作，面试受挫，分手等是你的低谷期，实则不然，这大概是一个不敢面对自己的借口。

因为多数人找到工作后，只要能在温饱线上，那么90%的人就会心安理得摆烂，和男女朋友复合后，依然是维持原样，不会被爱情去刺激自己成长。

如果用工作和分手这两件事情来描述真正的低谷期，那么我觉得应该是这样描述的：

自己付出了很多，每天都像一条疯狗干，工作和学习的时长维持在18个小时左右，坚持了很久，但是没有收获自己想要的东西，希望还是如此渺茫，于是产生严重的自我怀疑，挫败，深圳绝望！

自己一直在努力，在慢慢成长，目标越来越近，但是自己爱得死去活来的女朋友实在等不了自己成长，自己变强，所以无情的选择离开。

经过上面的描述，成为了毋庸置疑的低谷期。

因为没经过描述之前其实你是没有任何斗志的，目的就是能安心混日子，可以用摆烂来形容，和女朋友在一起，自己也不需要啥成本，她也没有啥诉求，所以算得上是互相将就。

但是经过描述后，实际上你的努力近乎疯狂，对于成功是无比的渴望，但是迟迟没降临到你的身上，而女朋友是在你身上压了筹码的，而你又非常爱她，但是迟迟不能让她压的筹码赚个翻倍，所以离开成了定局。

这下就一目了然了吧。

所以这时候你再去回想一下自己所谓的低谷期，是否真的是低谷期？还是自己矫情？

从上面的场景我们能看到深刻二字，第一个是根本谈不上深刻，而第二个是无比的深刻，如果你经历过，那么你自然能理解！

只有让自己刻骨铭心和痛苦的事情才能让自己成长，其他的基本不能。

就像你比较肥胖，三高找上你，家里人叫你不要再吃垃圾食品，不要喝饮料，但是这时候你还没真正躺在病床上，你基本上不会去听。

但是如果此刻你躺在病床上，插着呼吸管，医生给你说，如果你再不注意饮食，那么你很快就会死掉。你看你还会不会再去吃垃圾食品，喝饮料。

所以说，只有让自己脱一层皮，自己才会意识到问题的所在。

那么低谷期里，也自然会脱一层皮，甚至还会换骨头，那么你觉得这难道不是最佳的成长期吗？

所以一个人能遇上真正的低谷期，其实是一种幸运，应该要感谢这个遭遇。

就像一个朋友，因为一些原因导致自己不能再继续读书，家里为了自己的事情而负债累累，自己承受巨大的压力，想死的心都有了。

但是在这段堪称被恶魔惩罚的时期，他没有一蹶不振，反而置之死地而后生，最后无论是财富还是个人能力，阅历都有很大的提升！

后面和他聊天的时候，他说那是自己最痛苦，最无助的时候，但是自己庆幸没有放弃，才造就了一身钢筋铁骨？

所以你说这个低谷期是不幸的吗？

不是，这算的上是恩赐，因为并不是谁都有这种机会。

所以我们在低谷期的时候，如果能有把它作为翻盘的机会的思想，那么它一定是很难得的机会！

但是如果把它作为上天对自己的惩罚，从而一蹶不振，那么其实是错失一次很好的机会，并且也学让自己越陷越深！

前言

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

个人IP探索的第三个月，不再是一往无前的埋头苦干，一腔热血之余，对自己的能力探索与兴趣挖掘，成为了日常生活的主线。

为了更好的坚持下去，希望自己能够找到自己最擅长、做起来最愉悦、自身价值观又认可的事情。但最近一段时间，我意识到，我其实并不了解我自己。想认识自己，也不是一件简单的事情。

古希腊哲学家苏格拉底曾说：“未经审视的人生不值得过。“

话不多说，看看最近一段时间，我身边发生的事情与思考吧。

经历AI的诱惑，坚定内心的方向

其实在23年年底刚开始写作的时候，自己就对自己列了几个方向

其中，AI一直是我自己认为一个很重要的方向，时代大趋势下，所有行业只要加上AI，似乎都变得有些不一样。

24年年初，我第一次试着去了解AI的工具，是因为那时看到一个圈友，做了一个AI艺术二维码。于是我也下载下了stable-diffusion，准备大展身手一把。

本来是这样想的，发个朋友圈，如果有想要做艺术二维码的，我5块钱给他生成一个，怎么着也算开启了副业收入对吧。

结果人家做出来的是这样的，蛮好看。

我生成出来的，丑就不说了，问题是扫都扫不出来，就很搞笑。

苦于周边暂时没有大佬支持，也有着别的事情需要做，就暂时被我搁置了。

我的内心其实对AI感兴趣，但实际上，还是以一个程序员思维来考虑的。举一个例子，就想现在.NET的就业环境已经逐渐减少，如果我毕业时选择了一份.NET的工作，那么市场需求一定是很小的。

所以我才会对AI感兴趣，我的思路还是，或许5年后，Java已经不行了，但是算法开发、模型开发可能成为市场需求主流，为了找到工作，不得不去学习AI相关。

这件事情埋在我心里，虽没干成，但毕竟没有搞出来，心里还是有点不甘心的。

从过年伊始，就通过各种渠道，了解到了AI破局社群，即将迎来拉新。那时候我了解到，原来搞AI类应用，其实是有一个专门的社群的，里面也有各种各样的项目让你去落地，还有专业的人给你指导，我之前没跑出来的AI二维码，只要加入，遇到的问题肯定就能解决。

面对着铺天盖地的宣传，自己内心也逐渐有些动摇，一边是追求热点，迅速满足。一边是继续学习写作，延迟满足，看着许多圈友入局，内心还是挺焦虑的。

最终还是克服了自己短期尝试AI的想法，两个原因：

人的精力有限，需要放在有用的地方。

关于写作

上了热榜，占据首页

经过一周时间的打磨，之前经历的一篇文章，竟然上了热榜第一，6000多字的碎碎念能被大家看到，不少朋友给我说能够感同深受，一切的努力都值得了。

被更多的人看到，固然是好事，但在写这篇文章的过程中，也发现了不少问题，其中低效、内耗的问题，最为严重。

首先，6000多字的文章，完全是个人经历与思考，纯手写的话，如何组织语言，安排好顺序，就是一个最大的问题。

其次，如何把结构梳理好，能够更有连贯性，才能让大家在看的过程中，不枯燥乏味，我花费了非常多的时间。

最后，因为事情涉及到不少真实经历，受限于篇幅，不能完全的呈现给大家，如何选择最能让大家共鸣，最能给大家带来价值的地方，也蛮头疼的。

与现在利用AI工具，一天能够四五篇文章的作者比起来，效率简直低的可怕，虽然带来的价值不一样，但是流量就是这么多，想让更多人看到，效率如何提高，是我接下来要重点思考的事情。

关于输出的“困扰”

经过3个月的输出，我不出意外的遇到了“缺少话题”的情况，这也是最近更新频率变低的最主要的原因。

在这段时间，虽然输出频率降低，但话题的收集没有落下，每当有一些小点子，我就会先记录下来，每天翻一翻，去看看哪些是最想写的。

但实际上，即使收集了很多素材，如果你没有太多想说的话，无疑也只是罗列旧知识，没有新观点，我只想说点新颖的，所以迟迟没有动笔。

为了解决这个问题，两个方法和大家分享下

先立后破

先立后破，虽然话题素材减少，但强制要求自己，每周都要有所输出。

为了达成这个任务，我被迫搜集很多素材，先丰富自己的素材库，然后选择自己最有表达欲的主题，详细去写。

为什么要先立后破

任何事情都有一个逻辑，就是先别管技巧或者合理性，也别管效果如何，先给它规定一个数量，把数量做到了，慢慢的，你就会因为数量而倒逼自己去琢磨如何研究质量。

写作这件事也一样，即使我不知道写什么，也要强迫自己动笔去写，自己在输出这件事上，依然坚信着一句话。

数量不一定能决定质量，但一定能决定重量。

定扩联思维

先确定

能输出的点有很多，技术、副业、写作、复盘，先把内容方向定下来，比如我今天选择的方向就是复盘。

后扩展

扩展的话就好说了，既然是复盘，每一件事情都可以展开来讲，AI的一些经历。关于输出的困扰，输出一些方法论。

再联想

根据自己阅读、学习过的内容，进行发散。比如我深入思考的个人定位问题，最近的所学所想，都可以随着复盘输出出来。

个人定位

这个月花费最多的时间，就是在思考如何有一个清晰的定位。思考过程中问自己的几个问题，也在此罗列出来，如果你也想找到个人定位，也不妨对着这几个问题问一下自己。

职业与专业知识

7年后端研发工程师，北漂回二线城市的大厂程序员。毕业半年裸辞北漂，但经过几年北漂后，为了追求内心、照顾家庭，6年后回到二线城市发展。

北漂阶段，从30人小公司，最终进入大厂。大厂期间面试人数50+，对于求职面试、职业规划有着不少宝贵经验。

完成北漂回归二线城市，完成了城市选择，公司判断，薪资谈判，心里建设等一系列流程，各种有些许挫折，但都一一完成拆解。

善于在复杂项目中抽丝剥茧，但缺乏创造力。经手的项目无论难度多大，都可以极快的完成梳理与上手。但每当新业务开展，思路总会比较局限。

喜欢的博主

个人非常喜欢的博主是，半佛仙人，18年从公众号关注至今，文章几乎一篇不落。

为什么喜欢？我简单的想了下，有一下几个原因。

以上，羡慕。在我眼中，能毫无顾及的表达出自己的看法，让这么多人看到，对于一个爱写东西的人来讲，无疑是一件幸福的事情了。如果这件事情还能赚到钱，那更是锦上添花。

业余爱好

大学业余时间除了打游戏，就是谈恋爱，一上高数就睡觉，下课铃响就起床，

直到看了一本书《皮囊》之后，开始热爱上了阅读。虽然自己生在城市，完全没有农村经历，但对《皮囊》《活着》《兄弟》等很多农村作品，阅读的时候却有着特别大的感触，文中主人工经历越苦难，我的感受越心酸。

后来发现，老读这种文章，人都快看emo了（许多穷苦的事情，自己又没有能力改变什么）。

后来大学期间看了《嫌疑人x的现身》（短篇小说，非常精彩），了解了东野圭吾，对悬疑类作品有了极大兴趣，花了半年的时间就把他大多数重要的作品都看了一遍。印象最深的是《白夜行》，从第一次打开《白夜行》到最终看完，几乎过去了半年的时间，但是《嫌疑人x的现身》只需花了2天时间我就看完了。

但最终读完《白夜行》后，其中的精彩程度让我认为这是东野圭吾小说系列在我心中的No.1。这本书也让我意识到长篇小说的精彩之处，前面之前认为的枯燥的铺垫，到最后都是拍手称绝的伏笔。让我对延时满足这四个字，有个更深的体会。

后来又听说了村上春树，《挪威的森林》目前为止读了四遍，闲下来仍然会打开翻一翻。里面一些句子，一直在潜移默化的影响着我

不要同情自己，同情自己是卑劣懦夫干的勾当。

所谓绅士，就是做自己该做之事，而不是想做之事。

擅长的事情

我的盖洛普第二名和第五名，是和谐和体谅，遇见冲突解决冲突，并能够设身处地的体会他人的感受。所以之前有很多朋友和我说过，和我聊天，即使问题解决不了，心理上也能舒服很多。

或许你想找对象，我能帮你发现一些你潜在的问题，帮你去想应该怎么做，才能得到妹妹。

或许你面临裁员、换工作，我能根据你现有的能力与过往的经验，帮你规划提升方向。

或许你面临职场困惑，我也可以根据过往经验给出一些意见。

如果你有类似的问题，也欢迎你来找我聊聊。

说在最后

这次的复盘就先聊到这里了，有小的高光时刻，也有阻碍和自己的思考，感谢你能看到这里。

需求

实现歌词滚动效果，类似网易云音乐播放界面。

实现

1.准备数据

后台一般会返回这样一个歌词数据，每个时间都对应当前这个歌词。

因为是字符串不方便直接使用，我们把他转化为对象格式。封装一个utils工具传入歌词把lyric转化为对象。

// 处理后端返回歌词

export const HandleLyric = (lyric) => {

    function convertToSeconds(timeArray) {

        // 获取分钟和秒（包括毫秒）  

        const minutes = parseFloat(timeArray[0]); // 使用parseFloat来确保即使分钟有小数部分也能正确处理  

        const secondsWithMilliseconds = parseFloat(timeArray[1]);

        // 计算总秒数  

        const totalSeconds = minutes * 60 + secondsWithMilliseconds;

        return totalSeconds;

    }

    let line = lyric.split('\n')

    let value1 = []

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

        let str = line[i]

        // 把字符串分割为数组

        let part = str.split(']')

        let timestr = part[0].substring(1)

        let parts = timestr.split(':')

        let obj = {

            time: convertToSeconds(parts),

            word: part[1]

        }

        value1.push(obj)

    }

    return value1

}

2.计算偏移量

准备audio标签

  <div class="audio">

      <el-button>立即播放/暂停</el-button>

      <audio :src="audio_info['url']" ref="audio" class="audio-sty">11</audio>

  </div>

调用audio标签的currentTime可以获取当前歌曲播放到第几秒，遍历歌词的时间和当前时间（currentTime）比较，返回的i就是当前歌词的在第几行。

const changeplay = () => {

    let audio = document.querySelector('.audio-sty')

     // 找到当前这一句歌词的索引

        function FindIndex() {

            let currentTime = audio.currentTime

            for (var i = 0; i < store.lyicWords.length; i++) {

                if (currentTime < store.lyicWords[i].time) {

                    return i - 1

                }

            }

            return store.lyicWords.length - 1

        } 

}

计算偏移量

        // 计算偏移量 

        /**

         * 偏移量

         * @containerHeight //容器高度

         * @PHeight   //单个歌词高度

         */

        function Setoffset() {

            var index = FindIndex()

            var offset = index * store.PHeight + store.PHeight / 2 - store.containerHeight / 2

            if (offset < 0) {

                offset = 0

            }

            store.index = index

            store.Offset = offset

        }

用当前歌词所偏移的大小加上单个歌词Height1/2的大小,就可以实现歌词偏移，如果想让每次高亮的歌词在中间，需要再减去container盒子自身Height的一半。

调用audio的timeupadte时间触发计算偏移函数

  // audio 时间变化事件

audio.addEventListener('timeupdate', Setoffset)

3.添加样式

<div class="center" ref="center">

            <h1>歌词</h1>

<el-card class="box-center">

      <div class="center-ci" style="overflow: auto;" ref="lyricHeight">

      <p v-for="(item, index) in  songList['txt']" v-if="songList['txt'].length != 0"

                        :class="[index == store.index ? 'active' : '']">{{item }}</p>

       <p v-else>纯音乐，无歌词</p>

       </div>

</el-card>

</div>

使用transform: translateY(-50px);控制偏移

使用transform: scale(1.2);控制文字大小

     .center-ci {

                transform: translateY(-50px);

                display: block;

                height: 100%;

                width: 100%;



                p {

                    transition: 0.2s;

                    font-size: 20px;

                    text-align: center;

                }



                .active {

                    transform: scale(1.2);

                    color: goldenrod;

                }

            }

给歌词容器设置transform就可以实现歌词偏移了

// 根据偏移量滚动歌词 

lyricHeight.value.style.transform = `translateY(-${store.Offset}px)`

4.效果

~谢谢观看

估计谁都没想到2023年，疫情恢复的第一年竟然如此：大厂裁员、楼市继续下跌、年底股市暴跌等。

这篇文章说下笔者对宏观经济的一些理解和判断，以试图解释过去一年发生的一些事情。

宏观经济周期

笔者看来，由于美元具备全球货币属性，美元加息是全球的麻烦。所以总体而言，全球经济处于美元加息影响下的结果中，也就是处于美元回流，全球货币紧缩，全球经济处于下行周期中。

但每个主要经济体又有其自身的宏观经济周期，比如说我们国家，疫情三年为了人民的生命健康，我们国家没有像西方打开方便之门，大肆放水，而是选择严守死防。

三年疫情，我们国家保护了人民的生命健康，但我们也封闭了三年，紧缩了三年。我们国家处于疫情恢复周期中，处于上行周期中。但始作俑者的美国因为超发货币，自身经济过热，所以需要降低过热经济，所以宏观经济也处于下行周期中。

这里说一个题外话，宏观经济是通缩好还是通货膨胀好呢？实际上，过分的通缩和过分的通货膨胀都不好，适度的通胀最好，一般来说维持在2%左右是比较好的，这也就是美国一直想通过加息实现的通胀水平。

不管是通缩还是通胀代表的都是一种趋势，通缩经济逐渐下行，规模逐渐减小，反之通胀经济处于上行，规模逐渐扩大，这样才能实现GDP的增长，实现经济的发展。

回来继续说宏观经济周期，当下国家要做的就是让经济处于扩张区间，或者说实现经济的适度通胀。

2023年CPI和PPI一直不温不火，其实有一点通缩的迹象，所以国家在出台各种手段改善这种迹象：

但改变趋势谈何容易，同时还要考虑美国的加息节奏。所以出台的手段并不是那么尽如人意，也因为受到美国加息节奏的影响，为了维持外汇的稳定性，出台的时机也并未尽如人意。

笔者觉得正因为上述原因：美元加息周期、国内降息周期导致2023大厂裁员、楼市继续下跌、年底股市暴跌。

2024年宏观经济

目前美国已经暂停加息半年，加息周期已经到顶，预期5、6月份后降息。也正因为暂停加息，加息到顶我国央行今天进一步降低5年期贷款利率。

2024年的国内的宏观经济依然是将经济恢复为适度通胀的水平。笔者的判断是在汇率稳定的前提下，稳定楼市，因为楼市涉及的面太大。稳定了楼市才能稳定经济稳定预期，才能稳定股市。

完全有可能的是央行在美国降息后选择再一次降息贷款利息的方式，加强人们的信心，加强人们对国家进一步搞活经济的决心，给人们信心。

稳定楼市而不是大力发展楼市。笔者认为未来国家的发展会逐渐向高科技产业倾斜，从依靠楼市带动GDP增长改为依靠科技带动。

综上，一些配套的改革一定也会有：比如真正支持优秀公司发展的证券市场，比如政府职能转变为服务好企业，比如更加开放的区域市场（现在的浦东新区）等等。

而笔者比较关心的股票市场，隶属于证券市场，笔者觉得未来中国的股市一定会越来越好，尤其优秀的科技公司。

（本文完）

《肖申克的救赎》是一部令人震撼的电影。其给我留下深刻印象的不止男主的筹谋，还有终获假释，却选择上吊自杀的老布。老布是一个悲剧人物。

老布被关押监狱五十年。半个多世纪，老布从青年变为白发苍苍的老头，他最终熟悉了监狱的一切，适应了监狱的一切，也和监狱捆绑在了一起。用电影中的话来说，老布被监狱“体制化”了，包括他的自我认同，自我习惯。他依赖这个监狱。

也正因为此，出狱后的老布因为无法适应、融入发生巨变的社会环境，选择结束自己的一生。

体制化是指是个人或群体在某种环境中逐渐适应并接受其中的规则、习惯、意识和氛围，以至于这些成为其思考和行为的一部分。比如说销售人员更会自我激励，司机师傅更容易记下位置路线，财务人员更细致……

现代社会高度发展，每个人都不可避免的依赖某个组织或企业。为了融入组织或企业，被体制化是必然。但过度被体制化，比如长期生活在农村的老人，长期在高速口收费的收费员，长期无法晋升的公司老白兔……不利于人的发展，应该主动避免。

分工

现代企业建立的基础之一是大规模生产下的分工，分工可以提高生产效率，但分工也让人失去独立性。就拿上面长期在高速口收费的收费员举例，几年前河北高速一个收费员被辞退，就闹了起来，原因是他别的什么都不会了。

长期单一职责一旦被离职很容易陷入困境，轻者生活质量下降；重者长期失业；更重者，如老布一般选择终结自己的生命，事实上前几年就发生了这种事……

企业机会狼多肉少

几年前读过一句话：我们的社会实际是一个精英筛选系统，大多数人存在的意义是辅助筛选。这句话套用在企业也适用，企业是一个小型的精英筛选系统。

这些年互联网行业流行的所谓35岁职场危机，背后实际是部分企业认定35岁没能成为精英，也就不具人力性价比，选择不再对其招聘。

35岁大部分都有了家庭，要是35岁没有成为精英，相关企业招聘的意愿又不强，只能等着被辞退。要是在被过度体制化，被拴在一家企业，那无疑是雪上加霜。

体制化是放弃整个森林

我对企业有很多定义，其中之一企业是社会当中满足一系列特定需求的组织。一系列特定需求实际是局部市场。在局部市场里，企业注定机会有限。而市场本身比企业拥有更多机会，被过度体制化会被动放弃拥有更多机会的可能。

积极培养第二曲线甚至第三曲线

随着技术的提高，经济的发展，现代职业的生命周期在缩短。我认为每个人应该积极培养第二甚至第三职业。第二职业可以是自媒体，比如写作、比如up主、再比如小红书博主……可以是其他擅长的，可以利用下班时间去做的事业。

第三职业可以是投资人，投资是坐顺风车的学问，重要的是识别顺风车。做投资可以先从二级市场，也就是股票市场开始(投资需谨慎)。要能够借国家发展的大势，享受国家发展带来的红利。

我之前写过一篇关于宏观经济的文章《宏观经济的一些判断》。目前，我国经济处于上行周期中，受房地产拖累，经济爬坡有些缓慢。上个月CPI同比上涨0.7%，消费意愿在加强；上个月社融处于增长态势，经济活动相对活跃，上个月规模以上企业工业增加值显著增长……

种种迹象表明经济在好转，我也相信经济一定会好起来，经济好起来叠加国家对证券市场的进一步规范，不久以后股市完全有可能成为新的国民财富蓄水池。

结尾

总之，在工作过程中要识别哪些规则、习惯、意识和氛围，长期来讲是真正的机会，哪些不是。到了一定年龄，看不到成为公司精英的希望，应发展更多社会生存技能，在社会这个更大市场中生根发芽，创造财富，获取财富。

也希望能够直接借到国家发展大势，直接享受国家发展红利。