前言

事情是这样的，公司项目发版使用的 Azure DevOps，前段时间测试老师找过来说代码发布失败了，有代码报错，让我查一下，刚开始我猜测应该代码哪里写的有问题，之前也遇到过这种问题，改一下应该就行了

万万没想到，世界真奇妙......

项目框架及版本

• JS框架 Angular: 8.1.0


• TypeScript: 3.4.3


• UI库 devextreme：19.2.5

来分析一下遇到的问题

本地排查

下面是报错截图，看里面的内容似乎是代码报错导致的

具体看一下，看起来像 xxx.ts 里面的代码有问题，npm run build-uat 命令导致的发版失败

在代码仓库中找到了对应的报错文件并找到了控制台中报错行数 11:30, 看着没有问题，整个文件的代码都看了，没有异常的地方

npm run start 本地环境运行查看项目相关报错文件，查看报错情况，没有报错，使用 npm run build-uat 本地打包也正常，没有报错

为了排查个人电脑独特环境配置情况下才正常的情况，找了其他两个前端开发老师执行 npm run build-uat 打包命令，也都正常

果然，我写的代码怎么会有这种问题！😏

本地排查已经说明代码没有问题了，问题应该出在 DevOps 服务的环境上面

服务端排查

把本地的代码 push 到 GitLab 仓库，重新在 DevOps 平台页面上生成测试效果，发现不管生成几次，都是这个报错，DevOps 服务器不知道地址，也没有权限账号，找到有权限的架构部门相关的技术老师，说明原因后，让别人帮忙把代码单独在服务器上的镜像中运行看看效果

这个是单独在服务器上运行以后的报错截图，还是这个报错

第二天再去找架构部负责帮忙排查的那个老师，那个老师说排查后没检查出什么原因，发版的话先走其他方式吧，后面再研究研究看看，提供了一个临时方案

临时方案

由于 npm run build-uat 命令打包失败，又不能不用 DevOps 平台，让我们把线上的打包的环节放到本地，把 DevOps 的上的 install 和 build 安装打包命令先去掉，只留下其他命令脚本；把代码仓库的 .gitignore 中的 dist 文件忽略放开，然后提交把打包好的 dist 文件提交到线上的仓库中

都这年头了自动化发版不能用，仿佛一下子回到了技术领域的石器时代

现在的样子

架构部门的技术老师没搞定，反馈给公司的架构师看了，说帮忙弄下，后来也没了动静，然后就一直用的临时方案到现在，就是我们组的这几个前端开发悲剧了，每次提交都是拉一堆文件，然后本地打包，每次打包十几分钟，然后再提交一堆上去，每次几十个文件，仓库越来越大，本地运行打包速度也会越来越慢

以目前的情况，感觉项目仓库迟早要崩呀 😟

这种问题怎么解决

1. 
   

   和架构部的人也不熟，上次找别人还是和我们这边测试负责人一起去的，别的部门也有自己部门的任务，可能帮忙看了看没找到问题后面也就没顾上再看了，自己直接去找到级别也不够，只能再次给我们这边的测试负责人和部门负责人反馈，推动上级让他们去协调跟进

   
   


2. 
   

   技术层面上分析这个打包问题，看起来是 DevOps 中的 Docker 镜像容器环境出的问题，那么是不是可以本地安装Docker 拉取 Node 镜像搭建前端环境容器，本地在 Docker 容器中进行测试，如果没问题，可以把本地的 Docker 镜像导出来提供给架构部再次测试

   
   

还有更好的解决方案吗？

作者：草帽lufei
来源：juejin.cn/post/7252540034677522490

背景

古茗门店使用的收银机，有些会因为使用年限长、装了杀毒软件、配置低等原因性能较差，导致进钱宝启动响应较慢。然后店员在双击进钱宝图标后，发现没反应，就会重复点击

因此我们希望优化到即使在这些性能不太好的收银机上，也能让进钱宝有较快的启动体验

优化思路

• 测量，得到一个大概的优化目标，并发现可优化的阶段


• 主要方向是优化主进程创建出窗口的时间、让渲染进程页面尽快显示


• 性能优化好后，尽量让人感觉上更快点


• 上报各阶段耗时，建立监控机制，发现变慢了及时优化

测量

测量主进程

编写一个 bat文件 放到应用根目录，通过bat启动程序并获取初始启动时间：

@echo off



set "$=%temp%\Spring"

>%$% Echo WScript.Echo((new Date()).getTime())

for /f %%a in ('cscript -nologo -e:jscript %$%') do set timestamp=%%a

del /f /q %$%

echo %timestamp%

start yourAppName.exe



pause

项目内可以使用如下api打印主进程各时间节点：

this.window.webContents.executeJavaScript(

  `console.log('start', ${start});console.log('onReady', ${onReady});console.log('inCreateWindow', ${inCreateWindow});console.log('afterCreateWindow', ${afterCreateWindow});console.log('beforeInitEvents', ${beforeInitEvents});console.log('afterInitEvents', ${afterInitEvents});console.log('startLoad', ${startLoad});`

);

如果发现主进程有不正常的耗时，可以通过v8-inspect-profiler捕获主进程执行情况，最终生成的文件可以放到浏览器调试工具中生成火焰图

测量渲染进程

1、可以console打印时间点，可以借助preformance API获取一些时间节点

2、可以使用preformance工具测白屏时间等

进钱宝测量结果

以下测量结果中每一项都是时间戳，括号里是距离上一步的时间（ms）

最简单状态(主进程只保留唤起主渲染进程窗口的逻辑)：

未优化状态：

通过上述数据，能看出主进程最大的卡点是执行exe到开始执行代码之间

渲染进程的白屏时间，最初测试大概是1000ms

那么我们的优化目标，就是往最简单应用的时间靠齐，优化重点就是主进程开始执行代码时间，和渲染进程白屏时间

优化步骤

一、让主进程代码尽快执行

使用常见的方式，打包、压缩、支持tree-shaking，让代码体积尽可能的小；

可以把一些依赖按需加载，减少初始包体积

代码压缩

使用electron的一个好处是：chrome版本较高，不用pollyfill，可以直接使用很新的es特性

直接编译目标 ecma2020!!

优化tree-shaking

主进程存在global对象，但一些配置性的变量尽量不要挂载在global上，可以放到编译时配置里，以支持更好的tree-shaking

const exendsGlobal = {

  __DEV__,

  __APP_DIR__,

  __RELEASE__,

  __TEST__,

  __LOCAL__,

  __CONFIG_FILE__,

  __LOG_DRI__,

  GM_BUILD_ENV: JSON.stringify(process.env.GM_BUILD_ENV),

};



// 这里把一些变量挂载在global上，这样不利于tree-shaking

Object.assign(global, exendsGlobal);

慎用注册快捷方式API

实测这样的调用是存在性能损耗的

globalShortcut.register('CommandOrControl+I', () => {

  this.window.webContents.openDevTools();

});

// 这个触发方式，我们改为了在页面某个地方连点三下，因为事件监听基本没性能损耗

// 或者把快捷方式的注册在应用的生命周期中往后移，尽量不影响应用的启动

优化require

因为require在node里是一个耗时操作，而主进程最终是打包成一个cjs格式，里面难免有require

可以使用 node --cpu-prof --heap-prof -e "require('request')" 获取一个包的引用时长。
如下是一些在我本机的测量结果：

具体理论分析可以看这里：
如何加快 Node.js 应用的启动速度

因此我们可以通过一些方式优化require

• 把require的包打进bundle
  
  
  
  • 有两个问题
    
    
    
    • bundle体积会增加，这样还是会影响代码编译和加载时间
    
    
    • 有些库是必须require的，像node和electron的原生api；就进钱宝来说，我们可以通过其他方式优化掉require，因此没使用这种方式
    
    
    
    
  
  
  
  


• 按需require


• v8 code cache / v8 snapshot


• 对应用流程做优化，通过减少启动时的事务，来间接减少启动时的require量

按需require

比如fx-extra模块的按需加载方式：

const noop = () => {};



const proxyFsExtra = new Proxy(

  {},

  {

    get(target, property) {

      return new Proxy(noop, {

        apply(target, ctx, args) {

          const fsEx = require('fs-extra');

          return fsEx[property](...args);

        },

      });

    },

  }

);



export default proxyFsExtra;

前面的步骤总是做了没坏处，但这个步骤因为要重构代码，因此要经过验证

因此我们测量一下：

可以看出，主进程开始执行时间已经有了较大优化（大概700ms）

v8-compile-cache

可以直接用 v8-compile-cache 这个包做require缓存

简单测试如下：

脚本执行时间从388到244，因此这个技术确实是能优化执行时间的

但也有可能没有优化效果：

在总require较少，且包总量不大的情况下，做cache是没有用的。实测对进钱宝也是没用的，因为经过后面的流程优化步骤，进钱宝代码的初始require会很少。因此我们没有使用这项技术

但我们还是可以看下这个包的优化机制，这个包核心代码如下，其实是重写了node的Module模块的_compile函数，编译后把V8字节码缓存，以后要执行时直接使用缓存的字节码省去编译步骤

Module.prototype._compile = function(content, filename) {

	...



  // 读取编译缓存

  var buffer = this._cacheStore.get(filename, invalidationKey);



  // 这一步是去编译代码，但如果传入的cachedData有值，就会直接使用，从而跳过编译

  // 如果没传入cachedData，这段代码就会产生一份script.cachedData

  var script = new vm.Script(wrapper, {

    filename: filename,

    lineOffset: 0,

    displayErrors: true,

    cachedData: buffer,

    produceCachedData: true,

  });



  // 上面的代码会产生一份编译结果，把编译结果写入本地文件

  if (script.cachedDataProduced) {

    this._cacheStore.set(filename, invalidationKey, script.cachedData);

  }



  // 运行代码

  var compiledWrapper = script.runInThisContext({

    filename: filename,

    lineOffset: 0,

    columnOffset: 0,

    displayErrors: true,

  });



  ...

};

这里有个可能的优化点：v8-compile-cache 只是缓存编译结果，但require一个模块除了编译，还有加载这个io操作，因此是否可以考虑连io一起缓存

v8-snapshot

原理是：把代码执行结果的内存，做一个序列化，存到本地，真正执行时，直接加载然后反序列化到内存中

这样跳过了代码编译和执行两个阶段，因此可以提升应用的初始化速度。

优化效果：

对react做快照后，代码中获取的react对象如下图，实际上获得的是一份react库代码执行后的内存快照，跟正常引入react库没什么区别：

这个方案看起来很香，但也存在两个小问题：

1、不能对有副作用的代码做snapshot

因为只是覆写内存，而没有实际代码执行，因此如果有 读写文件、操作dom、console 等副作用，是不会生效的

因此这个步骤更多是针对第三方库，而不是业务代码

2、需要修改打包配置

目前项目一般通过import引用各种包，最终把这些包打包到bundle中；但该方案会在内存直接生成对象，并挂载在全局变量上，因此要使用snapshot，代码中包引用方式需要修改，这个可以通过对编译过程的配置实现

这个技术看起来确实能有优化效果，但考虑如下几点，最后我们没有去使用这项技术：

• 对主进程没用，因为主进程刚进来就是要做打开窗口这个副作用；


• 对渲染进程性价比不高，因为
  
  
  
  • 我们的页面渲染已经够快(0.2s)
  
  
  • 启动时，最大的瓶颈不在前端，而在服务端初始化，前端会长时间停留在launch页面等待服务端初始化，基于这一点，对渲染进程js初始化速度做极限优化带来的收益基本没有，我们真实需要的是让渲染进程能尽快渲染出来一些可见的东西让用户感知
  
  
  • 维护一个新模块、修改编译步骤、引入新模块带来的潜在风险
  
  
  
  

snapshot具体应用方式可看文尾参考文章

二、优化主进程流程，让应该先做的事先做，可以后做的往后放

基于上图的思想，我们对bundle包做了拆分：

新的测量数据：

可以看出，到这里主进程已经跟最简单状态差不多了。而且这一步明显优化非常明显。而这一步做的事情核心就是减少初始事务，从而减少了初始代码量以减少编译和加载负担，也避免了初始时过多比较耗性能的API的执行（比如require，比如new BrowserWindow()）。

那么我们主进程优化基本已经达到目标

三、让渲染进程尽快渲染

requestIdleCallback

程序刚启动的时候，CPU占用会很高（100%），因此有些启动任务可以通过requestIdleCallback，在浏览器空闲时间执行，让浏览器优先去渲染

去掉或改造起始时调用sendSync以及使用electron-store的代码

原因是sendSync是同步执行，会阻塞渲染进程

而electron-store里面初始时会调用sendSync

只加载首屏需要的css

对首屏不需要的ui库、components做按需加载，以减少初始css量，首屏尽量只加载首屏渲染所需的css

因为css量会影响页面的渲染性能

使用 tailwind 的同学可能会发现一个现象：如果直接加载所有预置css，页面动画会非常卡，因此 tailwind 会提供 Purge 功能自动移除未使用的css

少用或去掉modulepreload

我们使用的是vite，他会自动给一些js做modulepreload。但实测modulepreload（不是preload）是会拖慢首屏渲染的，用到的同学可以测测看

四、想办法让应用在体验上更快

使用骨架屏提升用户体感

程序开始执行 -> 页面开始渲染， 这段时间内可以使用骨架屏让用户感知到应用在启动，而不是啥都没有

我们这边用c++写了个只有loading界面的exe，在进钱宝启动时首先去唤起这个exe，等渲染进程渲染了，再关掉他（我们首屏就是一个很简单的页面，背景接近下图的纯色，因此loading界面也做的比较简单）

渲染进程骨架屏

渲染进程渲染过程：加载解析html -> 加载并执行js渲染

在js最终执行渲染前，就是白屏时间，可以在html中预先写一点简单的dom来减少白屏时间

一个白屏优化黑科技

我们先看两种渲染效果：

渲染较快的

渲染较慢的

接下来看下代码区别：

快的代码：

<div id="root">

    <span style="color: #000;">哈哈</span> <!-- 就比下面那个多了这行代码 -->

    <div class="container">

      <div class="loading">

        <span></span>

      </div>

    </div>

  </div>



慢的代码：

<div id="root">



    <div class="container">

      <div class="loading">

        <span></span>

      </div>

    </div>

  </div>

就是多了一行文字，就会更快地渲染出来

从下图可以看到，文字渲染出来的同时，背景色和loading动画（就中间那几个白点）也渲染出来了

有兴趣的可以测一下淘宝首页，如果去掉所有文字，还是会较快渲染，但如果再去掉加载的css中的一个background: url(.....jpg)，首次渲染就会变慢了

我猜啊。。。 这个叫信息优先渲染原则。。。🐶就是文字图片可以明确传递信息，纯dom不知道是否传递信息，而如果页面里有明确能传递信息的东西，就尽快渲染出来，否则，渲染任务就可能排到其他初始化任务后面了。

当然了，这只是我根据测试结果反推出来的猜测🐶

好了，现在我们也可以让渲染进程较快的渲染了（至少能先渲染出来一个骨架屏🤣）

五、其他

升级electron版本

electron 官方也是在不断优化bug和性能的

保证后续的持续优化

因为经过后续的维护，比如有人给初始代码加了些不该加的重量，是有可能导致性能下降的

因此我们可以对各节点的数据做上报，数据大盘，异常告警，并及时做优化，从而能持续保证性能

总结

本文介绍了electron应用的优化思路和常见的优化方案。并在进钱宝上取得了实际效果，我们在一台性能不太好的机器上，把感官上的启动时间从10s优化到了1s（可能有人会提个问题，上面列的时间加起来没有10s，为啥说是10s。原因是我们最初是在渲染进程的did-finish-load事件后才显示窗口的，这个时间点是比较晚的）

这其中最有效的步骤是优化流程，让应该先做的事先做，可以往后的就往后排，根据这个原则进行拆包，可以使得初始代码尽可能的简单（体积小，require少，也能减少一些耗性能的动作）。

另外有些网上看起来很秀的东西，不一定对我们的应用有用，是要经过实际测量和分析的，比如code-cache 和 snapshot

还有个点是，如果想进一步提升体验，可以先启动骨架屏应用，再通过骨架屏应用启动进钱宝本身，这样可以做到ms级启动体验，但这样会使骨架屏显示时间更长点（这种体验也不好），也需要考虑win7系统会不会有dll缺失等兼容问题

最后

关注公众号「Goodme前端团队」，获取更多干货实践，欢迎交流分享~

参考文档

v8 code cache

v8.dev/blog/improv…

v8.dev/blog/code-c…

fed.taobao.org/blog/taofed…

blog.csdn.net/szengtal/ar…

v8 snapshot

http://www.javascriptcn.com/post/5eedbc…

blog.inkdrop.app/how-to-make…

github.com/inkdropapp/…

其他

zhuanlan.zhihu.com/p/420238372

blog.csdn.net/qq_37939251…

medium.com/@felixriese…

zhuanlan.zhihu.com/p/376

前段时间看到掘金上有人二面被面试官要求写一个TodoList，今天趁着上班没啥事情，我也来写一个小Demo玩玩。

功能

一个TodoList大致就是长成这个样子，有一个输入框，可以通过输入任务名称进行新增，每个任务可以进行勾选，切换已完成和未完成状态，还可以删除。

组件设计

组件拆分

接下来，我们可以从功能层次上来拆分组件

1. 最外层容器组件，只做一个统一的汇总(红色)


2. 新增组件，管理任务的输入(绿色)


3. 列表组件，管理任务的展示(紫色)，同时我们也可以将每一个item拆分成为单独的组件(粉色)

数据流

组件拆分完毕之后，我们来管理一下数据流向，我们的数据应该存放在哪里？

我们的数据可以放在新增组件里面吗？不可以，我们的数据是要传递到列表组件进行展示的，他们两个是兄弟组件，管理起来非常不方便。同理，数据也不能放在列表组件里面。所以我们把数据放在我们的顶级组件里面去管理。

我们在最外层容器组件中把数据定义好，并写好删除，新增的逻辑，然后将数据交给列表组件进行展示，列表组件只管数据的展示，不管具体的实现逻辑，我只要把列表id抛出来，调用你传递的删除函数就可以了

现在，我们引出组件设计时的一些原则

1. 从功能层次上拆分一些组件


2. 尽量让组件原子化，一个组件只做一个功能就可以了，可以让组件吸收复杂度。每个组件都实现一部分功能，那么整个大复杂度的项目自然就被吸收了


3. 区分容器组件和UI组件。容器组件来管理数据，具体的业务逻辑；UI组件就只管显示视图

数据结构的设计

一个合理的数据结构应该满足以下几点：

1. 用数据描述所有的内容


2. 数据要结构化，易于操作遍历和查找


3. 数据要易于扩展，方便增加功能

[

    {

        id:"1",

        title:'标题一',

        completed:false

    },

    {

        id:"2",

        title:'标题二',

        completed:false

    }

]

coding

codesandbox.io/s/todolist-…

反思

看了下Antd表单组件的设计，它将一个Form拆分出了Form和Form.item

为什么要这么拆分呢？

上文说到，我们在设计一个组件的时候，需要从功能上拆分层次，尽量让组件原子化，只干一件事情。还可以让容器组件（只管理数据）和渲染组件（只管理视图）进行分离

通过Form表单的Api，我们可以发现，Form组件可以控制宏观上的布局，整个表单的样式和数据收集。Form.item控制每个字段的校验等。

个人拙见，如有

前言

这是一道面试题，这个问题出来的一刹那，很容易想到的就是for循环100000次吧，但是这方案着实让浏览器崩溃啊！还有什么解决方案呢？

正文

1. for 循环100000次

虽说for循环有点low，但是，当面试官问，为什么会让浏览器崩溃的时候，你知道咋解释吗？

来个例子吧，我们需要在一个容器（ul）中存放100000项数据（li）：

我们的思路是打印js运行时间和页面渲染时间，第一个console.log的触发时间是在页面进行渲染之前，此时得到的间隔时间为JS运行所需要的时间；第二个console.log是在 setTimeout 中的，它的触发时间是在渲染完成，在下一次Event Loop中执行的。

<!DOCTYPE html>

<html lang="en">



<head>

  <meta charset="UTF-8">

  <meta name="viewport" content="width=device-width, initial-scale=1.0">

  <title>Document</title>

</head>



<body>

  <ul id="ul"></ul>



  <script>

    let now = Date.now();  //Date.now()得到时间戳



    const total = 100000

    const ul = document.getElementById('ul')



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

      let li = document.createElement('li')

      li.innerHTML = ~~(Math.random() * total) 

      ul.appendChild(li)

    }

    console.log('js运行时间',Date.now()-now);



    setTimeout(()=>{  

      console.log('总时间',Date.now()-now);

    },0)

    console.log();

  </script>

</body>



</html>

运行可以看到这个数据：

这渲染开销也太大了吧！而且它是十万条数据一起加载出来，没加载完成我们看到的会是一直白屏；在我们向下滑动过程中，页面也会有卡顿白屏现象，这就需要新的方案了。继续看！

2. 定时器

我们可以使用定时器实现分页渲染，我们继续拿上面那份代码进行优化：

<!DOCTYPE html>

<html lang="en">



<head>

  <meta charset="UTF-8">

  <meta name="viewport" content="width=device-width, initial-scale=1.0">

  <title>Document</title>

</head>



<body>

  <ul id="ul"></ul>



  <script>

    let now = Date.now();  //Date.now()得到时间戳



    const total = 100000  //总共100000条数据

    const once = 20  //每次插入20条

    const page = total / once  //总页数

    let index = 1

    const ul = document.getElementById('ul')



    function loop(curTotal, curIndex) {

      if (curTotal <= 0) {  判断总数居条数是否小于等于0

        return false

      }

      let pageCount = Math.min(curTotal, once)  //以便除不尽有余数

      setTimeout(() => {

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

          let li = document.createElement('li')

          li.innerHTML = curIndex + i + ':' + ~~(Math.random() * total) 

          ul.appendChild(li)

        }

        loop(curTotal - pageCount, curIndex + pageCount)

      }, 0)

    }

    loop(total, index)

  </script>

</body>



</html>

运行后可以看到这十万条数据并不是一次性全部加载出来，浏览器右方的下拉条有顺滑的效果哦，如下图：

但是当我们快速滚动时，页面还是会有白屏现象，如下图所示，这是为什么呢？

可以说有两点原因：

• 一是setTimeout的执行时间是不确定的，它属于宏任务，需要等同步代码以及微任务执行完后执行。


• 二是屏幕刷新频率受分辨率和屏幕尺寸影响，而setTimeout只能设置一个固定的时间间隔，这个时间不一定和屏幕刷新时间相同。

3. requestAnimationFrame

我们这次采用requestAnimationFrame的方法，它是一个用于在下一次浏览器重绘之前调用指定函数的方法，它是 HTML5 提供的 API。

我们插入一个小知识点， requestAnimationFrame 和 setTimeout 的区别：

· requestAnimationFrame的调用频率通常为每秒60次。这意味着我们可以在每次重绘之前更新动画的状态，并确保动画流畅运行，而不会对浏览器的性能造成影响。

· setInterval与setTimeout它可以让我们在指定的时间间隔内重复执行一个操作，不考虑浏览器的重绘，而是按照指定的时间间隔执行回调函数，可能会被延迟执行，从而影响动画的流畅度。

还有一个问题，我们多次创建li挂到ul上，这样会导致回流，所以我们用虚拟文档片段的方式去优化它，因为它不会触发DOM树的重新渲染！

<!DOCTYPE html>

<html lang="en">



![rf.gif](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3eab42b37f53408b981411ee54088d5a~tplv-k3u1fbpfcp-watermark.image?)

<head>

  <meta charset="UTF-8">

  <meta name="viewport" content="width=device-width, initial-scale=1.0">

  <title>Document</title>

</head>



![st.gif](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3e922cc57a044f5e9e48e58bda5f6756~tplv-k3u1fbpfcp-watermark.image?)

<body>

  <ul id="ul"></ul>



  <script>

    let now = Date.now();  //Date.now()得到时间戳



    const total = 10000

    const once = 20

    const page = total / once

    let index = 1

    const ul = document.getElementById('ul')



    function loop(curTotal, curIndex) {

      if (curTotal <= 0) {

        return false

      }

      let pageCount = Math.min(curTotal, once)  //以便除不尽有余数

      requestAnimationFrame(()=>{

        let fragment = document.createDocumentFragment() //虚拟文档

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

          let li = document.createElement('li')

          li.innerHTML = curIndex + i + ':' + ~~(Math.random() * total)  

          fragment.appendChild(li)

        }

        ul.appendChild(fragment)

        loop(curTotal - pageCount, curIndex + pageCount)

      })

    }

    loop(total, index)

  </script>

</body>



</html>

可以看到它白屏时间没有那么长了：


还有没有更好的方案呢？当然有！往下看！

4. 虚拟列表

我们可以通过这张图来表示虚拟列表，红框代表你的手机，黑条代表一条条数据。

思路：我们只要知道手机屏幕最多能放下几条数据，当下拉滑动时，通过双指针的方式截取相应的数据就可以了。

🚩 PS:为了防止滑动过快导致的白屏现象，我们可以使用预加载的方式多加载一些数据出来。

代码如下：

<!DOCTYPE html>

<html lang="en">



<head>

  <meta charset="UTF-8">

  <meta name="viewport" content="width=device-width, initial-scale=1.0">

  <script src="https://unpkg.com/vue@3/dist/vue.global.js"></script>

  <title>虚拟列表</title>

  <style>

    .v-scroll {

      height: 600px;

      width: 400px;

      border: 3px solid #000;

      overflow: auto;

      position: relative;

      -webkit-overflow-scrolling: touch;

    }



    .infinite-list {

      position: absolute;

      left: 0;

      top: 0;

      right: 0;

      z-index: -1;

    }



    .scroll-list {

      left: 0;

      right: 0;

      top: 0;

      position: absolute;

      text-align: center;

    }



    .scroll-item {

      padding: 10px;

      color: #555;

      box-sizing: border-box;

      border-bottom: 1px solid #999;

    }

  </style>

</head>



<body>

  <div id="app">

    <div ref="list" class="v-scroll" @scroll="scrollEvent($event)">

      <div class="infinite-list" :style="{ height: listHeight + 'px' }"></div>

      

      <div class="scroll-list" :style="{ transform: getTransform }">

        <div ref="items" class="scroll-item" v-for="item in visibleData" :key="item.id"

          :style="{ height: itemHeight + 'px',lineHeight: itemHeight + 'px' }">{{ item.msg }}</div>

      </div>

    </div>

  </div>



  <script>

    var throttle = (func, delay) => {  //节流

      var prev = Date.now();

      return function () {

        var context = this;

        var args = arguments;

        var now = Date.now();

        if (now - prev >= delay) {

          func.apply(context, args);

          prev = Date.now();

        }

      }

    }

    let listData = []

    for (let i = 1; i <= 10000; i++) {

      listData.push({

        id: i,

        msg: i + ':' + Math.floor(Math.random() * 10000)

      })

    }



    const { createApp } = Vue

    createApp({

      data() {

        return {

          listData: listData,

          itemHeight: 60,

          //可视区域高度

          screenHeight: 600,

          //偏移量

          startOffset: 0,

          //起始索引

          start: 0,

          //结束索引

          end: null,

        };

      },

      computed: {

        //列表总高度

        listHeight() {

          return this.listData.length * this.itemHeight;

        },

        //可显示的列表项数

        visibleCount() {

          return Math.ceil(this.screenHeight / this.itemHeight)

        },

        //偏移量对应的style

        getTransform() {

          return `translate3d(0,${this.startOffset}px,0)`;

        },

        //获取真实显示列表数据

        visibleData() {

          return this.listData.slice(this.start, Math.min(this.end, this.listData.length));

        }

      },

      mounted() {

        this.start = 0;

        this.end = this.start + this.visibleCount;

      },

      methods: {

        scrollEvent() {

          //当前滚动位置

          let scrollTop = this.$refs.list.scrollTop;

          //此时的开始索引

          this.start = Math.floor(scrollTop / this.itemHeight);

          //此时的结束索引

          this.end = this.start + this.visibleCount;

          //此时的偏移量

          this.startOffset = scrollTop - (scrollTop % this.itemHeight);

        }

      }

    }).mount('#app')

  </script>

</body>



</html>

可以看到白屏现象解决了！

结语

解决十万条数据渲染的方案基本都在这儿了，还有更好

大家好啊，又跟大家见面了，最近有个需求就是批量修改公司的数据报表，正式环境！！
而且要执行update！！

update it_xtgnyhcebg I set taskStatus = XXX

而且是没有加where条件的，相当于全表更新，这可马虎不得，我们在任何操作正式数据库之前一定一定要对数据库备份！！不要问我怎么知道的，因为我就因为有一次把测试环境的数据覆盖到正式环境去了。。。

别到时候就后悔莫及，那是没有用的！

由于这个需求是需要在跨库操作的，所以我们在查询数据的时候需要带上库的名称，例如这样

SELECT

	* 

FROM

	BPM00001.ACT_HI_PROCINST P 

	LEFT JOIN BPM00001.ACT_HI_VARINST V ON V.PROC_INST_ID_ = P.ID_ 

	AND V.NAME_ = '__RESULE'

这样如果我们在任何一个库里面，只要在一个mysql服务里面都可以访问到这个数据
查出这个表之后

我们需要根据这里的内容显示出不同的东西
就例如说是“APPROVAL”我就显示“已通过”
这就类似与java中的Switch，其实sql也能实现这样的效果
如下：

这就是sql的case语句的使用
有了这些数据之后我们就可以更新数据表了，回到我们之前讨论过的，这是及其危险的操作
我们先把要set的值给拿出来

但是我们怎么知道这个里面的主键呢？
你如果直接这么加，肯定是不行的

所以我们需要在sql后面加入这样的一条语句

注意，这个语句一定要写在set语句的里面，这样sql就能依据里面判断的条件进行一一赋值
最后，将这个sql语句执行到生产库中

拓展：

作为查询语句的key绝对不能重复，否则会失败（找bug找了半天的人的善意提醒）
例如上面的语句中P.BUSINESS_KEY_必须要保证是唯一的！！

成功执行！！！
怎么样，这些sql

当涉及职场技能的探讨时，如何去编写高质量的代码通常是我们追求的目标。然而，随着时间的推移和思维的转变，我逐渐认识到，在职场中，有比写出优秀代码更为重要的事情存在。

这个事情不仅仅关乎我们的技术能力，而是涉及到我们的思维方式和工作方法；关乎我们能把工作做到什么样的级别，关乎到能给自己带来多大的成长和给公司带来多大价值。

在本篇文章中，我们将探讨逻辑思维与结构化思维。常言道：让你与众不同的不是努力，而是思维方式。所以无论你是一名开发人员、设计师、项目经理，或者在任何与技术相关的领域工作，掌握逻辑思维和结构化思维都是至关重要的。

我们为什么要掌握逻辑思维和结构化思维

在职场中，你应该见过那种初次见面便能感觉到他工作能力很强的人。

• 听他发言，说话非常有条理


• 看他文档目录层级清晰、各部分内容之间逻辑清晰，看他文档本身变成一种享受


• 听他给解决方案。有框架、有依据，直击问题要害

那这种感觉是从哪来的呢？就是依托于清晰的逻辑思维与结构化思维。

逻辑思维和结构化思维核心影响你与他人的关系，影响信息传递效率，影响你的个人影响力，是非常显性化的两种思维方式，是其他思维方式的基础。显性化是你只要刻意练习，你便能习得这项能力，并且很快在工作中应用得到正反馈，提高你的工作效率、加强你的沟通表达能力。

如果你的思考和表达没有逻辑与结构，这其实是一种灾难。核心不是自己会怎么样，而是非常浪费别人的时间。大家的时间都很宝贵，你浪费了别人的时间，别人怎么还会有耐心信任你。

职场人首要学习这两种思维方式，逻辑思维提高自身说服力，结构化思维提高信息传递效率。越早期越有这种意识，刻意培养自己，越能较早形成自己的核心竞争力。如果你说你不知道自己核心竞争力是什么，那么刻意培养的逻辑思维与结构化思维也可以让你在一堆人中脱颖而出。

逻辑思维

逻辑思维是指我们对问题和情况进行推理和分析的能力。它帮助我们理清思路，从复杂的问题中找到简单而合理的解决方案。当我们在编写代码时，逻辑思维帮助我们识别问题、设计算法和调试错误。然而，逻辑思维不仅仅适用于编码。在职场中，无论是解决问题、制定计划还是做出决策，逻辑思维都是我们必备的工具。

比如在日常的研发工作中，经常会出现因为逻辑不严谨导致给出的解决方案没法真正解决问题，浪费资源不说，还错过了时间窗口。有时候项目上线后看不到明显的转化，根本原因在一开始分析问题的思路就出错了，问题和解决方案之间没有形成逻辑闭环，你预想的“好”其实是错的。

业务：我们想要更换用户个人中心关于订单节点的文案。

我：为什么呢？

业务：因为我们发现当前商城的退换货满意度比天猫京东均低。

我：那低的原因是文案导致的吗？改了文案以后就可以提高退货满意度了吗？

在这个例子里可以发现业务想要做的行动跟原因并不匹配。假如真改了文案，退换货满意度就能提升到跟天猫京东一样了吗？如果事先不进行因果关系的纠正，没有想清楚匆忙投入开发，最终导致功能上线了实际问题也没得到解决。

如何提升逻辑思维

工作中大大小小的事情都需要做决策，回答一些问题，给出解决方案。当你尝试给出一个结论时，这个结论尽要符合逻辑。那么，如何去体现你的逻辑思维呢？

第一种：因果关联

我最近在商城增加分期免息支付方式，转化率得到了提升，为什么会提升？

分期免息降低了购买门槛，让本来没有能力的人可以购买。

结论是：分期免息可以提升转化率。

论据是：分期免息降低购买门槛，这个点无法再产生任何质疑。

世间万物都存在普遍联系，逻辑思维中最重要的就是找准结论与事实之间的因果联系。运用因果逻辑进行推理，一定不要仅停留在单一的因果层次上，必须从多个角度去研究事物发生的原因以及推出的结果。

比如，分析事物之间不同因果联系产生的不同结论。通常情况下，我们在进行因果关系推理时，必须重视因果分析，需要注意的有以下几方面：

① 有明确的结论产生

但是不要回答：也许吧....先看看....不知道结论是什么。再或者出现了问题讲述了一大段原因，但是否产生影响或损失无结论，下一步有无行动也无结论。没有结论的表现就是别人听了你的阐述，像没有听一样，也不知道下步该干什么。

讲因果关系时首要明确结论，且结论肯定、不模糊。听到结论的人明确知道自己下步要做什么行动。明确得出下步不做什么也是一种结论。

② 分析产生问题的真正原因

有些情况下，原因可以分为很多层次，有些现象在表面上看来是引发结果的原因，但其实不然，因为在它们背后还存在着引发它们的原因。

对于拥有多个引发原因的结果，如果仅停留在某个单一层面上，将这一原因当作引发结果的最终因素，论点就会变得相对肤浅，并且很难将分析的问题理清楚，这样的因果逻辑推理得出的结果所拥有的说服力必然不大。

我们常说的第一性原理是讲此点，从头算起，只采用最基本的事实作为依据，然后再层层推导，得出结论。有经验虽好，但有时候人们由于惯性陷入经验主义，而忘记质疑自己“为什么一定是这样”？

在平常的工作中，我们一定要学会多问自己几个为什么。

1. 平时工作只知道自己在做什么，那就是What；


2. 这样当然是不够的，还要常问自己，再来一遍what（我做这的这个到底是什么？）


3. why（为什么要做，为什么要这么做）


4. how（怎么做比较好）


5. why not（为什么不能那样做呢？）

如果你在尝试得出一个结论时，自己没先在内心先演练一遍，跟他人交流时，很容易受到挑战。

③ 分析主要原因和次要原因

很多情况下，一种结果的引发原因可能有很多种，这时我们必须分清其中的主次原因，准确抓住主要原因，通过引起结果的最基本因素来进行逻辑推理。

分析主次原因才会懂真正的MVP。MVP高度训练你对问题做拆解的能力，锻炼把一件事儿做成的能力。什么是当下最主要的矛盾，最应该被解决的痛点是什么，为什么是先做A而不是先做B的逻辑依据。如果一个人一上来就要做大而全的解决方案或者想要走捷径去做很容易实现的次要原因，也容易被受到质疑。

第二种：MECE原则

因果关系强调纵向思考逻辑，一环扣一环，回答“为什么”，MECE原则强调横向思考逻辑，思考无遗漏。

MECE原则来自《金字塔原理》，指相互独立不重复，完全穷尽无遗漏。

• 各部分之间相互独立（MutuallyExclusive），没有重叠，有排他性；


• 所有部分完全穷尽（CollectivelyExhaustive），没有遗漏。

干一件事情之前，我们先把它可能涉及到的要素全部列出来，运用思维导图工具，一层一层剖析到底；将这些要素按相同的性质来进行整理归纳，划分层级，最终呈现在你眼前的思维导图架构就会清晰明了，所有可能触发的点一目了然。

① 时间顺序

时间顺序强调一定要在某个时间节点发生了什么事情对下个时间节点产生影响。有明确时间差的按照时间顺序思考。比如说，过去—现在—未来，阶段1—阶段2—阶段3。

② 流程顺序

按照事物发生的流程顺序思考，先有什么再有什么，什么数据的变动会导致另外一块数据变动，这样避免我们改动了某块功能而遗留另外一块的功能。比如用户在电商网站上下单支付，先后有订单系统和支付系统均要参与这个过程。

③ 结构顺序

做完某件事情一定要所有相关点都能实现，如果一个点遗漏，导致整体无法完成。比如某个支付方式在指定金额区间范围内有效

结构化思维

然而，单纯的逻辑思维并不足以让我们在职场中取得长期成功。这时，结构化思维发挥着关键的作用。结构化思维是指我们将复杂问题和信息组织成有条理的结构，以便更好地理解和处理。它帮助我们将任务分解成可管理的部分，建立清晰的工作流程，并确保每个步骤都有明确的目标和结果。

在职场中：

• 同样沟通事情，有的人三句话就能说清楚，而你可能说了10分钟也说不到核心；


• 同样是做汇报，有的人用5页PPT就能说服对方，而你可能写了20多页还要被反问想表达什么；


• 同样是阐述解决方案，有的人清晰讲出背景、问题、原因、影响和举措，而你挤牙膏式的回答一句紧接着再被问一句。

如果说一个人沟通表达能力差，情商是一个因素，但还有一个更关键点：结构化思维。如果对方听了半天都不知道你在表达什么，情商再高也失去色彩。

人类大脑在处理信息的时候，有两个规律：

第一，不能一次太多，太多信息会让我们的大脑觉得负荷过大；

第二，喜欢有规律的信息。

表达能力强的人，不是比你更聪明，而是知道大脑这个特点，更懂得通过有效的结构化思维，快速对信息进行归纳和整理进行传递。 大脑容易记住有规律的东西，那么你在信息传递时尽量使用规律的东西来传递。把无序变得有规律的过程即结构化思维。

结构化思维是一种从整体到局部、从框架到细节的思维方式。 它要求思考者不先入为主，不会过快地陷入细节，而要经常留意事物的整体框架，在框架的基础上去拓展细节。先看能够解决问题的关键方面，然后再往下分析，从而实现从总体到局部的鸟瞰，最典型的就是金字塔结构图。

结构化思维渗透在工作的方方面面，是建立在逻辑思维之上的另一种显性化思维方式，不可或缺。结构化思维可以带来显著的工作效率提升，尤其是在沟通中。

那为什么在沟通中结构化思维可以发挥巨大作用呢？

因为人和人之间信息差。 结构的越上层，彼此之间信息差越小；结构的越下层，彼此之间信息差越大。如果一上来陷入到最下层的细节之中，对方大概率听不懂时沟通出现低效。

如何提升结构化思维

如果说逻辑思维一定程度上跟人天生智力水平有关，即我们常说的一个人聪不聪明，那么结构化思维则可以通过刻意训练习得。结构化思维完全由自己从0到1主动规划所得，就如同有些人可以做出好看的PPT，其实也是懂得了PPT背后的套路。

提到结构化思维，不得不去看的《金字塔原理》一书，主要有4个原则：结论先行，以下统上，归类分组，逻辑递进。

论：结论先行

证：以上统下

类：归类分组

比：逻辑递进

结构化思维有2种方法：自下向上组结构和自上向下套框架。

第一种：自下向上找结构

自下向上组结构核心在于这个结构是你自创的。根据你自己对接收到信息的理解，把信息重新组装的过程。

比如给领导讲业务数据的PPT，首先会介绍分析数据的整体框架，其次再给一个实际的数据分析的概览，再往下去细看每块的细分数据，针对每块的数据给出结论和TO DO。

• 整体数据指标体系（理论）—— 1页PPT


• 总体数据指标概览（实际数据）—— 1页PPT


• 分模块1数据指标—— 1页PPT


• 分模块2数据指标—— 1页PPT


• 分模块3数据指标—— 1页PPT


• 每页PPT里的结论和TO DO


• 总结—— 1页PPT

先框架后细节，先总结后具体，先结论后原因，先观点后建议，先重要后次要。 这样，才能让对方第一时间抓住重点信息，知道我们要传递的核心内容。

站在自己视角时，先把所有零散的点穷举，再看点与点之间的关联性连接成面，面最终再成体。概括起来大致分为以下4步：

• 尽可能列出所有思考的要点


• 找出关系，进行分类（找出要点间的逻辑关系，利用 MECE 原则归类分组）


• 总结概括要点，提炼观点


• 观点补充，完善思路

第二种：自上向下套框架

如果你是做已存领域的问题解决方案，那通过自上而下找结构：思考一个框架，然后将信息或解决方案放入框架。自上向下套框架依赖我们自身积累了多少种框架，在实际场景中可以随时被调用。

结构化思维是一个建立清晰、稳定、有序的思考结构，学到这个结构之后，知识体系从零散化到系统化，从无序到有序，从低效到高效。

不断的进行归纳和总结，养成做任何事都进行阶段性总结和复盘的习惯是训练结构化思维的核心。思维如果懒惰任何种方法技能也无济于事。

混沌大学创办人李善友教授说过：成年人学习的目的，应该是追求更好的思维模型，而不是更多的知识，在一个落后的思维模型里，即使增加更再多的信息量，也只是低水平的重复。

逻辑思维与结构化思维本身是专门的学科，并不是本文几千字就可以讲清楚的。但我核心想表达的点是：这2种思维方式相当重要，需要刻意去学习和培养。一些行业内的通用书籍，如《金字塔原理》值得反复阅读并且在日常工作中训练。

思维决定了你的认知水平和成长速度。 工作上没有好的思维方式，再努力也是无效努力。思维方式需要主动意识到高价值然后刻意训练习得。愿我们都能拥有更好的思维模型，开启不一样的人生。

作者：黄勇超
来源：juejin.cn/post/7252171148757418039

分享工作中重要的经历，可以当小说来看

一、伪内存泄漏排查

1.1 背景

我们原来有一个刚用 C++ 写的业务服务，迟迟不敢上线，原因是内存泄漏问题一直解决不了。现象是，服务上线后，内存一直慢慢每隔几秒上涨4/8KB，直到服务下线。

我刚入职不久，领导让我来查这个问题，非常具有挑战性，也是领导对我的考察！

1.2 分析

心路历程1：工具分析

使用 Valgrind 跑 N 遍服务，结果中都没有发现内存泄漏，但是有很多没有被释放的内存和很多疑似内存泄漏。实在没有发现线索。

心路历程2：逐个模块排查

工具分析失败，那就挨个模块翻看代码，并且逐个模块写demo验证该模块是否有泄漏（挂 Valgrind），很遗憾，最后还是没有找到内存泄漏。

心路历程3：不抛弃不放弃

这个时候两周快过去了，领导说：“找不到内存泄漏那就先去干别的任务吧”，感觉到一丝凉意，我说：“再给我点时间，快找到了”。这样顶着巨大压力加班加点的跑Valgrind，拿多次数据结果进行对比，第一份跑 10 分钟，第二份跑 20 分钟，看看有哪些差异或异常，寻找蛛丝马迹。遗憾的是还是没有发现内存泄漏在哪。

功夫不负有心人，看了 N 份结果后，对一个队列产生了疑问，它为啥这么大，队列长度 1000 万，直觉告诉我，它不正常。

去代码中找这个队列，确实在初始化的时候设置了 1000 万长度，这个长度太大了。

1.3 定位

进队列需要把虚拟地址映射到物理地址，物理内存就会增加，但是出队列物理内存不会立刻回收，而是保留给程序一段时间（当系统内存紧张时会主动回收），目的是让程序再次使用之前的虚拟地址更快，不需要再次申请物理内存映射了，直接使用刚才要释放的物理内存即可。

当服务启动时，程序在这 1000 万队列上一直不停的进/出队列，有点像貔貅，光吃不拉，物理内存自然会一直涨，直到貔貅跑到了队尾，物理内存才会达到顶峰，开始处在一个平衡点。

图1 中，红色代表程序占用的物理内存，绿色为虚拟内存。

图1

然而每次上线还没等 到达平衡点前就下线了，担心服务内存一直涨，担心出事故就停服务了。解决办法就是把队列长度调小，最后调到了 2 万，再上线，貔貅很快跑到了队尾，达到了平衡点，内存就不再增涨。

其实，本来就没有内存泄漏，这就是伪内存泄漏。

二、周期性事故处理

2.1 背景

我们有一个业务，2019 年到 2020 年间发生四次（1025、0322、0511 和 0629）大流量事故，事故时网络流量理论峰值 3000 Gbps，导致网络运营商封禁入口 IP，造成几百万元经济损失，均没有找到具体原因，一开始怀疑是服务器受到网络攻击。

后来随着事故发生次数增加，发现事故发生时间具有规律性，越发感觉不像是被攻击，而是业务服务本身的流量瞬间增多导致。服务指标都是事故造成的结果，很难倒推出事故原因。

2.2 猜想（大胆假设）

2.2.1 发现事故大概每50天发生一次

清晰记得 2020 年 7 月 15 日那天巡检服务时，我把 snmp.xxx.InErrors 指标拉到一年的跨度，如图2 发现多个尖刺的间距似乎相等，然后我就看了下各个尖刺时间节点，记录下来，并且具体计算出各个尖刺间的间隔记录在下面表格中。着实吓了一跳，大概是 50 天一个周期。并且预测了 8月18日 可能还有一次事故。

图2 服务指标

2.2.2 联想50天与uint溢出有关

7 月 15 日下班的路上，我在想 3600（一个小时的秒数），86400（一天的秒数），50 天，5 x 8 等于 40，感觉好像和 42 亿有关系，那就是 uint（2^32），就往上面靠，怎么才能等于 42 亿，86400 x 50 x 1000 是 40 多亿，这不巧了嘛！拿出手机算了三个数：

2^32                  = 4294967296 

3600 * 24 * 49 * 1000 = 4233600000 

3600 * 24 * 50 * 1000 = 4320000000 

好巧，2^32 在后面的两个结果之间，4294967296 就是 49 天 16 小时多些，验证了大概每 50 天发生一次事故的猜想。

图3 联想过程

2.3 定位（小心求证）

2.3.1 翻看代码中与时间相关的函数

果然找到一个函数有问题，下面的代码，在 64 位系统上没有问题，但是在 32 位系统上会发生溢出截断，导致返回的时间是跳变的，不连续。图4 是该函数随时间输出的折线图，理想情况下是一条向上的蓝色直线，但是在 32 位系统上，结果却是跳变的红线。

uint64_t now_ms() {

    struct timeval t;

    gettimeofday(&t, NULL);

    return t.tv_sec * 1000  +  t.tv_usec / 1000;

}

图4 函数输出

这里解释一下，问题出在了 t.tv_sec * 1000，在 32 位系统上会发生溢出，高于 32 位的部分被截断，数据丢失。不幸的是我们的客户端有一部分是 32 位系统的。

2.3.2 找到出问题的逻辑

继续追踪使用上面函数的逻辑，发现一处问题，客户端和服务端的长链接需要发Ping保活，下一次发Ping时间等于上一次发Ping时间加上 30 秒，代码如下：

next_ping = now_ms() + 30000;

客户端主循环会不断判断当前时间是否大于 next_ping，当大于时发 Ping 保活，代码如下：

if (now_ms() > next_ping) {

    send_ping();

    next_ping = now_ms() + 30000;

}

那怎么就出现大流量打到服务器呢？举个例子，如图3，假如当前时间是 6月29日 20:14:00（20:14:26 时 now_ms 函数返回 0），now_ms 函数的返回值超级大。

那么 next_ping 等于 now_ms() 加上 30000（30s），结果会发生 uint64 溢出，反而变的很小，这就导致在接下来的 26 秒内，now_ms函数返回值一直大于 next_ping，就会不停发 Ping 包，产生了大量流量到服务端。

2.3.3 客户端实际验证

找到一个有问题的客户端设备，把它本地时间拨回 6月29日 20:13:00，让其自然跨过 20:14:26，发现客户端本地 log 中有大量发送 Ping 包日志，8 秒内发送 2 万多个包。证实事故原因就是这个函数造成的。解决办法是对 now_ms 函数做如下修改：

uint64_t now_ms() {

    struct timespec t;

    clock_gettime(CLOCK_MONOTONIC, &t);

    return uint64_t(t.tv_sec) * 1000  +  t.tv_nsec / 1000 / 1000;

}

2.3.4 精准预测后面事故时间点

因为客户端发版周期比较长，需要做好下次事故预案，及时处理事故，所以预测了后面多次事故。

2.4 总结

该事故的难点在于大部分服务端的指标都是事故导致的结果，并且大流量还没有到业务服务，就被网络运营商封禁了 IP；并且事故周期跨度大，50 天发生一次，发现规律比较困难。

发现规律是第一步，重点是能把 50 天和 uint32 的最大值联系起来，这一步是解决该问题的灵魂。

• 大胆假设：客户端和服务端的代码中与时间相关的函数有问题；


• 小心求证：找到有问题的函数，别写代码验证，最后通过复现定位问题；

经过不屑努力从没有头绪到逐渐缩小排查范围，最后定位和解决问题。

**

程序猿的九年广漂感悟

广漂第九年了,成为了一名老码农,混迹于各种论坛博客中,我感觉总得写点什么.讲讲技术也好,发泄一下码农的无奈也好.希望对年轻的同行有点帮助吧.

非广东人,但从小在广东生活,一口不标准的粤语,毕业自然而然就就来了广州,总以为广州是最合适的城市,无论饮食和文化,跟大多数毕业生一样,总会有一些不着边际的理由漂泊在北上广深,没有过来人指导职业规划,全凭一股初生牛犊不怕虎的拼劲.其实这是一件很可怕且无奈的事情.建议大家多听听张雪峰对大学生的指导.不说太多废话,先讲自己的经历吧.
14-15年毕业季,毕业于很普通的二本母校,在面试公司实在是抬不起头来,后来入职了一家搞微商的公司,一个人干三个人的活,写Android和java后端,天天加班,老板天天喂鸡汤大饼,周末单休,4000大洋的无保障金,还发不出来,年轻的时候只想学技术,希望早日月薪过万.当时住在一个城中村里面,每天来回160分钟的公交地铁,路上都在看慕课网和掘金,这个期间虽然穷且幼稚,但是技术成长很快,相信和大多数刚刚毕业的大学生一样吧,因为想法不多,没有家庭,没有职业规划,才能一心一意的把技术学好.

同时期,那些在老家有规划的同学在干嘛呢,有继承家里工厂的,有直接考试公务员的,他们的人生规划很清晰,有工作然后找老婆,然后家里帮助买房成家,哦对了,我老家附近是二线城市,这一点很重要.

毕业的第一家公司让我像个无头苍蝇,微商公司出来后呢,或多或少也算对我们天朝社会有了一点认知,想找稳定一点的工作,最起码是正常发工资的,很快就找了家超甲级写字楼的中外合资公司,开头就是广东XXXX公司,琶洲那边,直面广东大珠江.每月薪资8500大洋,主攻Android.那时候996不叫流行,叫盛行.

期间有几件有意思的事情.

第一件是公司有很多老外,当时有个德国投资商需要几个产品和设计一起对需求,第一天就跟国产同事说,我工作的节奏很快,也会有加班,你们一定要跟上节奏.当时刚刚毕业于西安外语的小妹妹不知道怎么翻译的,回来给我们说的一愣一愣的,一个月后,德国佬全身而退了,还说了一些让我们啼笑皆非的话,说你们中国人加班太严重了,好像不需要自己的私人时间一样.当时还没有’卷”这种说法.跟着德国佬对需求的产品设计回到国人领导的团队后,感叹,跟着德国人做事太舒服了,几乎也没有加班,节奏慢的舒坦;

第二件事,公司后来给我配了个小弟,让我好好带,小弟的薪资是9500.这货是刚刚培训出来的,理论知识牛逼,啥也做不了.一个月后我怕累死自己,于是让他走人了,后来公司又找了大专没有毕业的小伙子,技术很扎实,薪资5000.领导还说给多了,这小伙子很实在,后来一直跟了我很多年,现在想想有点对不住他,一直没有给他带个好坑位.

第三件事,因为写字楼周末是不开中央空调的,所以我们经常加班的冷热不知;但是资本家可不管这些,虽然公司经常不准时发工资,套路可不少,比如招人来试用期过后就裁员,不多不少3个月,反正便宜好用,或者招外包人员来用几天给人充当大公司的样子,然后在绩效方面下功夫,很多很多套路,有时候不得不佩服国人在这方面的造诣.还有经常在午休期间听到老板撕心裂肺的骂人,哈哈哈,那时候想不明白这货是怎么做成老板的,很多年后向明白了,这货才符合国人老板形象.对了,这家公司背靠我们伟大的某种天朝机构.

这家公司是我呆过最差的公司,通宵加班是常有的,你们打工的最长加班时间是多长呢,我是两天两夜....你们肯定很想知道这家公司结局怎样,最老外肯定是撤资走人的,公司最后就剩几个无关紧要的人.你们以为是失败了吗,其实是相当成功的,虽然坑了一波人,但是老板们的豪车豪宅是实现了的,快钱已经到手了,你们细细品....

任职这家中外合资的公司期间,其实说不清是什么人生态度,我除了正常打工还干嘛呢,被朋友忽悠去创业,经常折腾到晚上两三点.年轻就是好呀,好像不用睡觉一样.后来有一件事对我打击很大.我接了一个中国移动的小单子,3万块,每天晚上在家工作到2点左右,刚刚开始还没有什么,一个星期后,突然重感冒,发烧,后来直接请假在家休息了一段时间,也就是这个期间,我的体重从60公斤一下子飙到了65公斤.至于职业规划,买车买房,成家立业啥的,不好意思,8500的月薪,住在见不到阳光的城中村的我,真的不知道自己应该想什么.除了提高技术拼体力以外,我们能想的很少,当然家里也经常叫回去考公务员,但是人出来了,想回去真的很难很难.

这里再说一下同时期的好友,做公务员的朋友,已经在老家买了房子了,有了心爱的姑娘了,虽然自称是房奴,但是公积金已经绰绰有余.接手家里生意的朋友已经做的风生水起.在这里提醒一下刚刚毕业的小码农,家庭的高度以及父母提供的规划很重要.

从那家公司出来以后,我突然想去国企看看,因为那段时间太累了,想要周末,想正常上下班.这里就要提到一家老牌国企.某电视台,做某电视台新闻某电app.当时面试已经通过了,人事谈下来的薪资是1w,很多公司给的薪资都是一点几的w,但是还是想去国企,可能真的是加班怕了吧.一个二十出头的小伙子,经常通宵加班,心里打击还是很大的.但是这家某视台的国企呢,比较让人摸不着头脑,人事已经口头答应录用了,但是offer迟迟没有下来,后来我入职了另外一家公司半个月以后,offer终于来了,人事还介绍了一番,问我什么时候可以入职.后来还发生了一件特别有趣的事情.你以为的国企就很稳定,并没有,一年后,我成为了面试官,他们整个小组的人来求职,是我亲自面试的......

再说说接下来吧,我去了一家上市公司,公司很大,薪资很高,刚刚开始很闲,那时候的我除了学技术以外,终于有时间思考下一步怎么办,这是我遇到的福利最好的一家公司,不过我后来还是离职了,其实任职期间我已经在找下家了.这家公司的项目我认为是没有前途的,后来事实证明确实没有前景,项目很快就裁掉了.这家公司也有一件小插曲,当时公司安排了7个实习生让我带,让我在两个星期内完成一个教育类app,大公司是有各种考核的,每天都要写日报,我当时的前一个星期的日报都是写怎么搭框架,怎么模块化项目, 后来项目经理每天都找到我,她说不关心我做什么框架,什么模块化,他要的是马上实现UI上面的功能,并且她能够体验的到这些功能的完成度,必须要知道我在干什么,对了,这家公司如果使用了第三方库的话,需要提交给上级申请,并且要写评估报告的.对,你没有听错.要求全部使用原生的框架,举个例子,我用 了okhttp,然后被叼了一顿.哈哈哈哈!有一次我去看了一下别人的日报怎么写的,很亮眼睛,全部都是今天我优化了哪里哪里的代码,完成了哪里哪里的注释....

是不是有小伙伴问我为什么不去某大型互联网公司试试,这还用说,任职期间我肯定是有去面试的,某讯面试通过了,但是我不喜欢深圳,放弃了,某易的话,我请了三天假去面试,我印象中最后一轮是某易的某邮箱的组长面的我,拒绝我的理由是因为我不懂C++,当时我挺沮丧的,并且怼了他,简历上就可以看出我不精通C++,电话面试也可以看出我是否精通C++,为什么让我花了几天来面试....他不说话.多年后想了想,其实完全没有必要,一个邮箱app很难吗,拒绝我肯定是其他原因的.谁有话语权就有决定权.出来工作有一点必须要尽快学会成长的,不要对没有意义的事情较劲.

接着讲吧,某上市公司出来之后,我去了一家我当时认为还是比较ok的公司,干了很多年,一直干到公司上市.....我不太想说太多这家公司,怕暴露自己最好的青春都给了这家公司.

说说同时期的好朋友怎么样了吧,某公务员朋友,在家里的帮助下,已经副科,孩子已经打酱油了,他每天聊天的积极性很高,你懂的,家里的帮助下,买了个大房子.另一个接手家庭生意的朋友,已经把公司做到了当地的第一,什么奔驰宝马豪宅,早就实现了,孩子都三个了.也有同学会问,北上广深漂泊的同学呢,他们基本上都回老家了.不好意思,没有太多的人生赢家,大部分的人都是普普通通的.房子始终是我们绕不过的一道坎,尤其是大城市,想通过打工实现大城市安家立业,是一件很难很难的事情,刚刚毕业的程序员小伙伴要考虑清楚这一点哦.

差点忘记了这是一个技术论坛,我们再来聊聊技术吧,可能会有小伙伴好奇我的技术怎么样,ios Android python 设计 都还行,因为永远都有新东西出来,没人敢说自己在新的技术点上多牛,也不敢保证自己永远处于热爱技术的阶段上,至于什么架构师啥的,项目管理什么的,对于目前的我来说就跟煮饭一样简单.目前的阶段处于,什么可以赚钱我就可以学什么,但是大多数的技术都是不赚钱的,你细品...

奉劝新入技术坑的小伙伴,不要纠结于自己学哪种技术,更不要要纠结于哪个技术点谁比较牛逼,你们较劲的东西资本家看着像一个笑话.技术仅仅只是一个工具,先确定好自己要做什么,再决定自己携带什么工具.

再说说三十多岁的程序员的未来方向在哪里,先说说找工作吧,我这个阶段一旦被裁员,大概率找不到工作,不要纠结市场环境为什么这么奇怪,你可以怀疑资本家的人品,但是请不要怀疑资本家对市场的把控.不要问我怎么知道,也不要举例反驳我,市场上总有特例,我们只能拥抱市场大环境.这些年来,我带过团队很多,经常招人,有时候都会感叹我出去以后怎么找工作,慢慢的,我现在已经能接受自己失业后送外卖和开滴滴了.对,你没有听错,宇宙的尽头可能是考公,也可能是美团或者饿了么.

说说职业分水岭吧,第一个5年,你跟身边的同学可能差别不大,无非就是结婚与不结婚,但是到了第二个五年,你会慢慢的发现,原来不同的职业不同的城市,幸福感真的不一样,选择远远比努力重要,做一个普通人就是要很努力很努力的,所以不要看不起一毕业就考公的同学,也不要说谁谁谁读大专是混日子啥的,请不要忽视体制带来的便利,体制这个词你细品.

写了那么多,来个总结吧,毕竟是小爽文嘛,是要写点个人主观的想法的.技术本身是没有出路的,出路在业务,业务驱动技术的开发.所以不要过多纠结于太多技术点,技术牛逼的人未必能赚多钱,技术牛逼的人不一定能去bat,也可能在缅甸菲律宾或者91啥先生的.对了,我忘了说,这些年副业赚到的钱是打工的好几倍,所以你细品.

一个人是否考虑技术上长远发展,首先要考虑自己的家庭,以及自己的身边的资源.如果有条件毕业就回家考公上岸的话,尽量去试试.大城市的技术之路往往伴随着城中村,出租房,996.所以多花点心思在业务上.希望在座的小伙伴尽快规划好自己的职业道路,我文中提了那么多同时期的朋友,不得不承认他们有更好的家庭资源,我想说的是,要懂得利用自己的家庭资源尽早规划自己的职业道路,如果没有足够的家庭资源,更要尽早规划自己的职业道路.技术不是出路,只是暂时的活路

背景介绍

先描述一下需求，要在一个老项目里根据type类型，给一个试题题干组件新增一个class样式，type是在url地址栏上面携带的。简单，一行代码搞定，五分钟部署，十分钟留给测试，然后跟车上线，打卡下班！

《凉凉》送给自己

看标题就知道结果了，第二天下午现网问题来了，一线反馈某个页面题干不展示了，值班同事排查一圈，找到我说我昨天加的代码报错了！

惊了，就加了一行业务代码，其他都是样式，测试也通过了，这也能有问题？绩效C打底稳了（为方便写文章，实际判断用变量代替）：

<div :class="{'addClass': $route.query.type === 'xx'}">

   ...

</div>

问题其实很简单，$route为undefined了，导致query获取有问题，这让我点怀疑自己，难道这写错了？管不了太多，只能先兼容上线了。

$route && $route.query && $route.query.type

其实是可以用?.简写的，但是这个项目实在不“感动”了，保险写法，解决问题优先。提申请，拉评审，走流程，上线，问题解决，松口气，C是保住了。

问题分析

解决完问题，还要写线上问题分析报告，那只能来扒一扒代码来看看了。首先，这个项目使用的是多页应用，每个页面都是一个新的SPA，我改的页面先叫组件A吧，组件A在页面A里被使用，没问题；组件A同样被页面B使用，报错了。那接下来简单了，看代码：

// 2022-09-26 新增

import App from '@/components/pages/页面A'

import router from '@/config/router.js'

// initApp 为封装的 new Vue

import { initApp, Vue } from '../base-import'

initApp(App, router)

// 2020-10-18 新增

import App from '@/components/pages/页面b'

new Vue({

    el: '#app',

    components: { App },

    template: '<App/>'

})

两个页面的index.js文件，两种写法，一个引用了router，一个没有引用，被这个神仙代码整懵了。然后再看了一下其他页面，也都是两种写法掺着写的，心态崩了。这分析报告只能含着泪写了...

最后总结

1. 问题不是关键，关键的是代码规范；


2. 修改新项目之前，最好看一下代码逻辑，有熟悉的同事最好，可以沟通了解一下业务（可以避免部分问题）；


3. 当想优化之前代码的时候，要全面评估，统一优化，上面的写法我也找同事了解了，因为之前写法不满足当时的需求，他就封装了新方法，但是老的没有修改，所以就留了坑；

🙋 遇到的问题

在一个新项目中，设计统一了项目中所有的字体，并提供了字体包。在项目中需要按需引入这些字体包。

首先，字体包的使用分为了以下几种情况：

1. 无特殊要求的语言使用字体A，阿拉伯语言使用字体B；


2. 加粗、中等、常规、偏细四种样式，AB两种字体分别对应使用 Bold 、 Medium 、 Regular 、 Thin 四种字体包；

所以，我现在桌面上摆着 8 个字体包：

• A-Bold.tff


• A-Medium.tff


• A-Regular.tff


• A-Thin.tff


• B-Bold.tff


• B-Medium.tff


• B-Regular.tff


• B-Thin.tff

不同语言要使用不同的字体包，不同粗细也要使用不同的字体包！

还有一个前提是，设计给的设计图都是以字体A为准，所以在 Figma 中复制出来的 CSS 代码中字体名称都是A。

刚接到这个需求时还是比较懵的，一时想不出来怎么样才能以最少的逻辑判断、最少的文件下载、最少的代码改动去实现在不同情况下自动的去选择对应的字体包。

因为要涉及到语言的判断，最先想到的还是通过 JS，然后去添加相应的类名。但这样也只能判断语言使用A或B，粗细还是解决不了。

看来还是要用 CSS 解决。

首先我将所有的8个字体先定义好：

@font-face {

    font-family: A-Bold;

    src: url('./fonts/A-Bold.ttf');

}



/* ... */



@font-face {

    font-family: B-Thin;

    src: url('./fonts/B-Thin.ttf');

}

🤲🏼 如何根据粗细程度自动选择对应字体包

有同学可能会问，为什么不直接使用 font-weight 来控制粗细而是用不同的字体包呢？

我们来看下面这个例子，我们使用同一个字体， font-weight 分别设置为900、500、100，结果我们看到的字体粗细是一样的。

对的，很多字体不支持 font-weight 所以我们需要用不同粗细的字体包。

所以，我们可以通过 @font-face 中的 font-weight 属性来设置字体的宽度：

@font-face {

    font-family: A;

    src: url('./fonts/A-Bold.ttf');

		font-weight: 600;

}

@font-face {

    font-family: A;

    src: url('./fonts/A-Medium.ttf');

		font-weight: 500;

}

@font-face {

    font-family: A;

    src: url('./fonts/A-Regular.ttf');

		font-weight: 400;

}

@font-face {

    font-family: A;

    src: url('./fonts/A-Thin.ttf');

		font-weight: 300;

}

注意，这里我们把字体名字都设为相同的，如下图所示，这样我们就成功的解决了第一个问题：不同粗细也要使用不同的字体包；

并且，如果我们只是定义而未真正使用时，不会去下载未使用的字体包，再加上字体包的缓存策略，就可以最大程度节省带宽：

🔤 如何根据不同语言自动选择字体包？

通过张鑫旭的博客找到了解决办法，使用 unicode-range 设置字符 unicode 范围，从而自定义字体包。

unicode-range 是一个 CSS 属性，用于指定字体文件所支持的 Unicode 字符范围，以便在显示文本时选择适合的字体。

它的语法如下：

@font-face {

  font-family: "Font Name";

  src: url("font.woff2") format("woff2");

  unicode-range: U+0020-007E, U+4E00-9FFF;

}

在上述例子中，unicode-range 属性指定了字体文件支持的字符范围。使用逗号分隔不同的范围，并使用 U+XXXX-XXXX 的形式表示 Unicode 字符代码的范围。

通过设置 unicode-range 属性，可以优化字体加载和页面渲染性能，只加载所需的字符范围，减少不必要的网络请求和资源占用。

通过查表得知阿拉伯语的 unicode 的范围为：U+06??, U+0750-077F, U+08A0-08FF, U+FB50-FDFF, U+FE70-FEFF, U+10A60-10A7F, U+10A80-10A9F 这么几个区间。所以我们设置字体如下，因为设计以 A 字体为准，所以在 Figma 中给出的样式代码字体名均为 A，所以我们把 B 字体的字体名也设置为 A：

当使用字体的字符中命中 unicode-rang 的范围时，自动下载相应的字体包。

@font-face {

    font-family: A;

    src: url('./fonts/A-Bold.ttf');

    font-weight: 600;

}



@font-face {

    font-family: A;

    src: url('./fonts/A-Medium.ttf');

    font-weight: 500;

}



@font-face {

    font-family: A;

    src: url('./fonts/A-Regular.ttf');

    font-weight: 400;

}



@font-face {

    font-family: A;

    src: url('./fonts/A-Thin.ttf');

    font-weight: 300;

}



:root {

    --ARABIC_UNICODE_RANGE: U+06??, U+0750-077F, U+08A0-08FF, U+FB50-FDFF, U+FE70-FEFF, U+10A60-10A7F, U+10A80-10A9F;

}

@font-face {

    font-family: A;

    src: url('./fonts/B-Bold.ttf');

    font-weight: 600;

    unicode-range: var(--ARABIC_UNICODE_RANGE);

}

@font-face {

    font-family: A;

    src: url('./fonts/B-Medium.ttf');

    font-weight: 500;

    unicode-range: var(--ARABIC_UNICODE_RANGE);

}

@font-face {

    font-family: A;

    src: url('./fonts/B-Regular.ttf');

    font-weight: 400;

    unicode-range: var(--ARABIC_UNICODE_RANGE);

}

@font-face {

    font-family: A;

    src: url('./fonts/B-Thin.ttf');

    font-weight: 300;

    unicode-range: var(--ARABIC_UNICODE_RANGE);

}

p {

    font-family: A;

}

总结

遇到的问题：

1. 两种字体，B 字体为阿拉伯语使用，A 字体其他语言使用。根据语言自动选择。


2. 根据字宽自动选择相应的字体包。


3. 可以直接使用 Figma 中生成的样式而不必每次手动改动。


4. 尽可能节省带宽。

我们通过 font-weight 解决了问题2，并通过 unicode-range 解决了问题1。

并且实现了按需下载相应字体包，不使用时不下载。

Figma 中的代码可以直接复制粘贴，无需任何修改即可根据语言和自宽自动使用相应字体包。

参考资料：http://www.zhangxinxu.com/wordpr

博主在浏览 medium 社区时，发现了一篇点赞量 1.5k 的文章，名称叫《Java is Dead — 5 Misconceptions of developers that still think Java is relevant today!》直译过来就是《Java 已死 — 开发人员对 Java 在现代编程语言中的5个误解》。这篇文章可以说是标题党得典范，热度全靠标题蹭 😂。当然本文重点在于文章评论区。作者因为标题党惨着评论区大佬们怒怼，不敢回复。

原文地址：medium.com/@sidh.thoma… Thomas

推荐博主开源的 H5 商城项目waynboot-mall，这是一套全部开源的微商城项目，包含三个项目：运营后台、H5 商城前台和服务端接口。实现了商城所需的首页展示、商品分类、商品详情、商品 sku、分词搜索、购物车、结算下单、支付宝/微信支付、收单评论以及完善的后台管理等一系列功能。 技术上基于最新得 Springboot3.0、jdk17，整合了 MySql、Redis、RabbitMQ、ElasticSearch 等常用中间件。分模块设计、简洁易维护，欢迎大家点个 star、关注博主。

github 地址：github.com/wayn111/way…

下面是文章内容：

人们仍然认为 Java 与当今时代相关，这是一种常见的误解。事实上 Java 是一种正在消亡的编程语言。 Java 一直是世界上使用最广泛、最流行的编程语言之一，但它很快就会面临消亡的危险。如今 Java 拥有庞大而活跃的开发者社区，并且仍然用于广泛的应用程序，包括 Web 开发、移动应用程序开发和企业级软件开发，但 Java 能在未来 10 年生存吗？让我们看看开发者对 Java 有哪些误解：

误解 1：Java 拥有庞大且活跃的开发者社区。世界各地有数百万 Java 开发人员，该语言在开发人员共享知识和资源的在线论坛和社区中占有重要地位。

虽然情况仍然如此，但开发人员转向其他平台和编程语言的速度很能说明问题，我个人也看到开发人员惊慌失措地跳槽。主要问题是 Java 作为一种编程语言还没有现代化，因此它仍然很冗长，通过一个步履蹒跚但极其笨重的类型系统结合了静态和动态类型之间最糟糕的两个世界，并且要求在具有以下功能的 VM 上运行宏观启动时间（对于长时间运行的服务器来说不是问题，但对于命令行应用程序来说是痛苦的）。虽然它现在表现得相当不错，但它仍然无法与 C 或 C++ 竞争，并且只要有一点爱，C#、Go、Rust 和 Python 就可以或将会在该领域超越它。对于现实世界的生产服务器，它往往需要大量的 JVM 调整，而且很难做到正确。

误解 2：Java 的应用范围很广。 Java 不仅仅是一种 Web 开发语言，还用于开发移动应用程序、游戏和企业级软件。这种多功能性使其成为许多不同类型项目的有价值的语言。

Java 不再是移动应用程序开发（尤其是 Android）首选的编程语言。 Kotlin 现在统治着 Android，大多数 Android 开发者很久以前就已经跳槽了。就连谷歌也因为几年前与甲骨文的惨败而放弃了 Java 作为 Android 的事实上的语言。 Java 作为一种 Web 开发语言也早已失去了它的受欢迎程度。就企业开发而言，Java 在大型企业中仍然适用，因为它可靠且稳定。尽管许多初创公司并未将 Java 作为企业软件的首选，但他们正在使用其他替代方案。

误解 3：Java 是基础语言。许多较新的编程语言都是基于 Java 的原理和概念构建的，并且旨在以某种方式与其兼容。这意味着即使 Java 的受欢迎程度下降，它的原理和概念仍然具有相关性。

虽然 Java 确实是许多人开始编程之旅的基础语言，但事实是 Java 仍然非常陈旧且不灵活。最重要的是，与其他现代编程语言相比，它仍然很冗长，这意味着它需要大量代码来完成某些任务。这会使编写简洁、优雅的代码变得更加困难，并且可能需要更多的精力来维护大型代码库。此外，Java 是静态类型的这一事实意味着它可能比动态类型语言更严格且灵活性较差，这可能会让一些开发人员感到沮丧。

误解 4：Java 得到各大公司的大力支持。 Oracle 是维护和支持 Java 的公司，对该语言有着坚定的承诺，并持续投资于其开发和改进。此外，包括 Google 和 Amazon 在内的许多大公司都在其产品和服务中使用 Java。

Oracle 的 Java 市场份额正在快速被竞争对手夺走。见下图：

尽管下图显示甲骨文仍然拥有最大的市场份额，但其份额已减少了一半以上。 2020 年，甲骨文占据了“大约 75% 的 Java 市场”，而现在的份额还不到 35%。

根据 New Relic 的数据，排名第二的是亚马逊，自 2021 年 11 月发布 Java 17 以来，其份额急剧上升，当时其份额几乎与 Eclipse Adoptium 相同。

误解 5：Java 在学校和大学中广泛教授。 Java 是一种流行的编程概念教学语言，经常用于学校和大学的计算机科学课程。这意味着有源源不断的新开发人员正在学习 Java 并熟悉其功能。

这种情况正在发生很大的变化。渴望成为软件开发人员的年轻大学生正在迅速转向其他编程语言。由于对这些其他编程语言的普遍需求，这越来越多地促使学院和大学寻找替代方案。

我知道这是一个有争议的话题。虽然我也认为 Java 是一种彻底改变了软件编写方式的语言，并为其他编程语言树立了可以效仿的基准。但不幸的是，该语言的所有权掌握在公司手中，在没有留下太多财务收益的情况下，该公司没有动力继续改进它。

OK，文章内容就这么多，下面是本文重点！

评论区

喜闻乐见评论区来了 😎，看看国外开发者怎么反驳这篇文章得，本文选取评论点赞量较高得5条评论放在下文。

评论一

作者不知道什么是编程语言、它为什么存在以及它在哪里使用。

仅因为许多程序员都在应用程序中最简单的部分工作，就认为 Java 与 Python 等效，这是完全错误的。

假设自因为使用自行车的人比驾驶采矿机的人多，我就认为自行车比卡特彼勒采矿机更好，这是不对得。

评论二

哈哈哈，我想说他甚至可能不是一个程序员，可能会做一些 JavaScript 的事情，即使如此，将 JavaScript 和 TypeScript 归类为两种语言也是没有意义的。

在安卓开发中，他不明白 Kotlin 是什么，虽然它确实有效。

评论三

每次看到这样的文章我都会直接去看评论。（喜闻乐见评论区🤔）

评论四

对于成熟，我有一些话要说。我过去三份工作中有两份是在一些公司开始使用一种性感的新语言（即 ruby 和 python），然后付钱给像我这样的人用 Java 重写他们的应用程序。

评论五

作者似乎不明白编程语言的风格是出于不同的目的而存在的，语言之间进行比较没有意义， 比如拿 sql 或 html/css 与 java 来比？语言是一个丰富的生态系统，我们需要为特定目的选择正确的语言。因此需要多语言开发人员而不是教条主义。

总结

博主这里说下自己得看法，虽然作者对于自己得观点进行了5个误解的阐述，但是博主是并不认同得。

• 文章的标题就是一个误导性的问题，暗示了 Java 已经不行。事实上 Java 仍然是一门非常流行和强大的编程语言，它在很多领域都有广泛的应用和优势，如移动应用、Web 应用、可穿戴设备、大数据、云计算等。Java 也有不断地更新和改进，引入了很多新的特性和功能，以适应不断变化的技术需求。


• Java 也有庞大的社区和丰富的资源，为开发者提供了很多支持和帮助。根据 GitHub Octoverse Report 2022，Java 是第三大最受欢迎的语言，仅次于 JavaScript、Python。根据 JetBrains State of Developer Ecosystem 2022，Java 是过去12个月内使用占有率排名第五的语言，占据了 48% 的份额。根据 StackOverflow Developer Survey 2022，最常用的编程语言排行榜中 Java 是排名第六的语言，占据了 33.27% 的份额。这些数据都表明 Java 并没有死亡或不在流行，而是仍然保持着其重要的地位。

• 文中说 Java 是一门过时和冗长的语言，它没有跟上时代的变化，而其他语言如 Python、JavaScript 和 Kotlin 等都更加简洁和现代化。这个观点忽略了 Java 的设计哲学和目标。Java 是一门成熟、稳定、跨平台、高性能、易维护、易扩展的编程语言，它注重可读性、健壮性和兼容性。Java 的语法可能相对复杂，但它也提供了很多强大的特性和功能，如泛型、注解、枚举、lambda 表达式、流 API、模块化系统等。


• Java 也没有停止创新和改进，它在近几年引入了很多新的特性和功能，如 Record 类、密封类、模式匹配、文本块、虚拟线程、外部函数和内存API等。其他语言可能在某些方面比 Java 更加简洁或现代化，但它们也有自己的局限和缺点，比如运行速度慢、类型系统弱、错误处理困难等。不同的语言适合不同的场景和需求，并不是说一种语言就可以完全取代另一种语言。

总之，我觉得 Java 在未来会被替代的可能性很小，但也不能掉以轻心，在后端开发领域，Go 已经在逐步蚕食 Java 得份额，今年非常火得 ai 模型领域相关，大部分代码也是基于 Python 编写。Java 需要在保持优势领域地位后持续地创新和改进。

关注公众号【waynblog】每周分享技术干货、开源项目、实战经验、高效开发工具等，您的关注将是我的更新动力！

作者：waynaqua
来源：juejin.cn/post/7252127579195736119

语言大模型不断向垂直行业领域拓展，这次出圈的是北大法律大模型。

大模型又「爆了」。

昨晚，一个法律大模型 ChatLaw 登上了知乎热搜榜榜首。热度最高时达到了 2000 万左右。

这个 ChatLaw 由北大团队发布，致力于提供普惠的法律服务。一方面当前全国执业律师不足，供给远远小于法律需求；另一方面普通人对法律知识和条文存在天然鸿沟，无法运用法律武器保护自己。

大语言模型最近的崛起正好为普通人以对话方式咨询法律相关问题提供了一个绝佳契机。

目前，ChatLaw 共有三个版本，分别如下：

• 
  

  ChatLaw-13B，为学术 demo 版，基于姜子牙 Ziya-LLaMA-13B-v1 训练而来，中文各项表现很好。但是，逻辑复杂的法律问答效果不佳，需要用更大参数的模型来解决；

  
  


• 
  

  ChatLaw-33B，也为学术 demo 版，基于 Anima-33B 训练而来，逻辑推理能力大幅提升。但是，由于 Anima 的中文语料过少，问答时常会出现英文数据；

  
  


• 
  

  ChatLaw-Text2Vec，使用 93w 条判决案例做成的数据集，基于 BERT 训练了一个相似度匹配模型，可以将用户提问信息和对应的法条相匹配。

  
  

根据官方演示，ChatLaw 支持用户上传文件、录音等法律材料，帮助他们归纳和分析，生成可视化导图、图表等。此外，ChatLaw 可以基于事实生成法律建议、法律文书。该项目在 GitHub 上的 Star 量达到了 1.1k。

官网地址：
http://www.chatlaw.cloud/

论文地址：
arxiv.org/pdf/2306.16…

GitHub 地址：
github.com/PKU-YuanGro…

目前，由于 ChatLaw 项目太过火爆，服务器暂时崩溃，算力已达上限。该团队正在修复，感兴趣的读者可以在 GitHub 上部署测试版模型。

小编本人也还在内测排队中。所以这里先展示一个 ChatLaw 团队提供的官方对话示例，关于日常网购时可能会遇到的「七天无理由退货」问题。不得不说，ChatLaw 回答挺全的。

不过，小编发现，ChatLaw 的学术 demo 版本可以试用，遗憾的是没有接入法律咨询功能，只提供了简单的对话咨询服务。这里尝试问了几个问题。

其实最近发布法律大模型的不只有北大一家。上个月底，幂律智能联合智谱 AI 发布了千亿参数级法律垂直大模型 PowerLawGLM。据悉该模型针对中文法律场景的应用效果展现出了独特优势。

ChatLaw 的数据来源、训练框架

首先是数据组成。ChatLaw 数据主要由论坛、新闻、法条、司法解释、法律咨询、法考题、判决文书组成，随后经过清洗、数据增强等来构造对话数据。同时，通过与北大国际法学院、行业知名律师事务所进行合作，ChatLaw 团队能够确保知识库能及时更新，同时保证数据的专业性和可靠性。下面我们看看具体示例。

基于法律法规和司法解释的构建示例：

抓取真实法律咨询数据示例：

律师考试多项选择题的建构示例：

然后是模型层面。为了训练 ChatLAW，研究团队在 Ziya-LLaMA-13B 的基础上使用低秩自适应 (Low-Rank Adaptation, LoRA) 对其进行了微调。此外，该研究还引入 self-suggestion 角色，来缓解模型产生幻觉问题。训练过程在多个 A100 GPU 上进行，并借助 deepspeed 进一步降低了训练成本。

如下图为 ChatLAW 架构图，该研究将法律数据注入模型，并对这些知识进行特殊处理和加强；与此同时，他们也在推理时引入多个模块，将通识模型、专业模型和知识库融为一体。

该研究还在推理中对模型进行了约束，这样才能确保模型生成正确的法律法规，尽可能减少模型幻觉。

一开始研究团队尝试传统的软件开发方法，如检索时采用 MySQL 和 Elasticsearch，但结果不尽如人意。因而，该研究开始尝试预训练 BERT 模型来进行嵌入，然后使用 Faiss 等方法以计算余弦相似度，提取与用户查询相关的前 k 个法律法规。

当用户的问题模糊不清时，这种方法通常会产生次优的结果。因此，研究者从用户查询中提取关键信息，并利用该信息的向量嵌入设计算法，以提高匹配准确性。

由于大型模型在理解用户查询方面具有显著优势，该研究对 LLM 进行了微调，以便从用户查询中提取关键字。在获得多个关键字后，该研究采用算法 1 检索相关法律规定。

实验结果

该研究收集了十余年的国家司法考试题目，整理出了一个包含 2000 个问题及其标准答案的测试数据集，用以衡量模型处理法律选择题的能力。

然而，研究发现各个模型的准确率普遍偏低。在这种情况下，仅对准确率进行比较并无多大意义。因此，该研究借鉴英雄联盟的 ELO 匹配机制，做了一个模型对抗的 ELO 机制，以便更有效地评估各模型处理法律选择题的能力。以下分别是 ELO 分数和胜率图：

通过对上述实验结果的分析，我们可以得出以下观察结果

（1）引入与法律相关的问答和法规条文的数据，可以在一定程度上提高模型在选择题上的表现；

（2）加入特定类型任务的数据进行训练，模型在该类任务上的表现会明显提升。例如，ChatLaw 模型优于 GPT-4 的原因是文中使用了大量的选择题作为训练数据；

（3）法律选择题需要进行复杂的逻辑推理，因此，参数量更大的模型通常表现更优。

参考资料

作者：夕小瑶科技说
来源：juejin.cn/post/7252172628450541624

分布式协议一口气学完

一、Raft 协议

1.1 基础概念

Raft 算法是通过一切以领导者为准的方式，实现一系列数据的共识和各节点日志的一致。Raft是强领导模型，集群中只能有一个领导者。

成员身份：领导者（Leader）、跟随者（Follower）和候选者（Candidate）。

图1 成员身份

• 领导者：集群中霸道总裁，一切以我为准，处理写请求、管理日志复制和不断地发送心跳信息。


• 跟随者：普通成员，处理领导者发来的消息，发现领导者心跳超时，推荐自己成为候选人。


• 候选人：先给自己投一票，然后请求其他集群节点投票给自己，得票多者成为新的领导者。


• 任期编号：每任领导者都有任期编号。当领导者心跳超时，跟随者会变成候选人，任期编号 +1，然后发起投票。任期编号小的服从编号大的。


• 心跳超时：每个跟随者节点都设置了随机心跳超时时间，目的是避免跟随者们同时成为候选人，同时发起投票。


• 选举超时：每轮选举的结束时间，随机选举超时时间可以避免多个候选人同时结束选举未果，然后同时发起下一轮选举

1.2 领导选举

1.2.1 选举规则

• 领导者周期性地向跟随者发送心跳消息，告诉跟随者我是领导者，阻止跟随者发变成候选人发起新选举；


• 如果跟随者的随机心跳超时了，那么认为没有领导者了，推荐自己为候选人，发起新的选举；


• 在一轮选举中，赢得一半以上选票的候选人，即成为新的领导者；


• 在一轮选举中，每个节点对每个任期编号的选举只能投出一票，先来先服务原则；


• 日志完整性高（也就是最后一条日志项对应的任期编号值更大，索引号更大）的跟随者A拒绝给完整性低的候选人B投票，即使B的任期编号大；

1.2.2 选举动画

图2 初始选举

图3 领导者宕机/断网

图4 第一轮选举未果，发起第二轮选举

1.3 日志复制

日志项（Log Entry）：是一种数据格式，它主要包含索引值（Log index）、任期编号（Term）和 指令（Command）。

• 索引值：它是用来标识日志项的，是一个连续的、单调递增的整数值。


• 任期编号：创建这条日志项的领导者的任期编号。


• 指令：一条由客户端请求指定的、服务需要执行的指令。

图5 日志信息

1.3.1 日志复制动画

图6 简单日志复制

图7 复杂日志复制

1.3.2 日志恢复

每次选举出来的Leader一定包含在多数节点上最新的已经提交的日志，新的Leader将会覆盖其他节点上不一致的数据。

虽然新Leader一定包括上一个Term的Leader已提交(Committed)日志，但是可能也包含上一个Term的Leader的未提交(Uncommitted)日志。

这部分未提交日志需要转变为Committed，相对比较麻烦，需要考虑Leader多次切换且未完成日志恢复，需要保证最终提案是一致的、确定的，不然就会产生所谓的幽灵复现问题。

为了将上一个Term未提交的日志转为已提交，Raft算法要求Leader当选后立即追加一条Noop的特殊内部日志，并立即同步到其它节点，实现前面未提交日志全部隐式提交。

这样保证客户端不会读到未提交数据，因为只有Noop被大多数节点同意并提交了之后（这样可以连带往期日志一起同步），服务才会对外正常工作；

Noop日志本身是一个分界线，Noop之前的日志被提交，之后的日志将会被丢弃。Noop日志仅包含任期编号和日志索引值，没有指令。

日志“幽灵复现”的场景

图8

第一步，A是领导者，在本地记录4和5日志，并没有提交，然后挂了。

图9

第二步，由于B的日志索引值比C的大，B成为了领导者，仅把日志3同步给了C，然后挂了。

图10

第三步，A恢复了，并且成为了领导者，然后把未提交的日志4和5同步给了B和C（C在A成为了领导者之后、同步日志之前恢复了），然后ABC都提交了日志4和5，就这样原本客户端写失败的日志4和5复活了，进而客户端会读到其认为未提交的日志（实际上集群日志已提交）。

Noop解决日志复现

第一步，同上面一样。

第二步，由于B的日志索引值比C的大，B成为了领导者，这次不仅把日志3同步给了C，还记录了一个Noop日志，并且同步给了C。

图11

第三步，当A恢复了，想成为领导者，发现自己的日志任期编号和日志索引值都不是最大的，即使B挂了也还有C，A也就成为不了领导者，乖乖使用B的日志覆盖自己的日志。

1.4 成员变更

集群成员变更最大的风险是可能同时出现 2 个领导者。比如在成员变更时，节点 A、B 和 C 之间发生了分区错误，节点 A、B 组成旧集群（ABC）中的“大多数”。

而节点 C 和新节点 D、E 组成了新集群（ABCDE）的“大多数”，它们可能会选举出新的领导者（比如节点 C）。结果出现了同时存在 2 个领导者的情况。违反了Raft协议中领导者唯一性原则。

图12 集群（ABC）同时增加节点D和E

最初解决办法是联合共识（Joint Consensus），但实现起来难，后来 Raft 的作者就提出了一种改进后的方法，单节点变更（single-server changes）。

在正常情况下，旧集群的“大多数”和新集群的“大多数”都会有一个重叠的节点。

图13 集群（ABCD）增加新节点E

图14 集群（ABCDE）删除节点A

图15 集群（ABC）增加新节点D

图16 集群（ABCD）删除节点A

需要注意的是，在分区错误、节点故障等情况下，如果并发执行单节点变更，那么就可能出现一次单节点变更尚未完成，新的单节点变更又在执行，导致集群出现 2 个领导者的情况。

二、Gossip 协议

Gossip协议，顾名思义，就像流言蜚语一样，利用一种随机、带有传染性的方式，将信息传播到整个网络中，并在一定时间内，使得系统内的所有节点数据一致。Gossip其实是一种去中心化思路的分布式协议，解决信息在集群中的传播和最终一致性。

2.1 原理

Gossip协议的消息传播主要有两种：反熵（Anti-Entropy）和谣言传播（Rumor-Mongering）。

2.1.1 反熵：节点相对固定，节点数量不多，以固定概率传播所有的数据

每个节点周期性地随机选择其他节点，通过互相交换各自的所有数据来消除两者之间的差异，实现数据的最终一致性。反熵非常可靠，但每次节点两两交换各自的所有数据会带来非常大的通信负担，因此不会频繁使用。通过引入校验和等机制，可以降低需要对比的数据量和传播消息量。

反熵 使用“simple epidemics”方式，其包含两种状态：susceptible和infective，这种模型也称为SI model。处于infective状态的节点代表其有数据更新，并且会将这个数据分享给其他节点；处于susceptible状态的节点代表其并没有收到来自其他节点的更新。

图17 反熵

2.2.2 谣言传播：节点动态变化，节点数量较多，仅传播新到达的数据

当一个节点有了新信息后，这个节点变成活跃状态，并周期性地向其他节点传播新信息。直到所有的节点都知道该新信息。由于节点之间只传播新信息，所以大大减少了通信负担。

谣言传播 使用“complex epidemics”方法，比反熵 多了一种状态：removed，这种模型也称为SIR model。处于removed状态的节点说明其已经接收到来自其他节点的更新，但是其并不会将这个更新分享给其他节点。因为谣言消息会在某个时间标记为removed，然后不会再被传播给其他节点，所以谣言传播有极小概率使得所有节点数据不一致。

图18 谣言传播

一般来说，为了在通信代价和可靠性之间取得折中，需要将这两种方法结合使用。

2.2 通信方式

节点间的交互主要有三种方式：推、拉和推/拉

图19 节点状态

2.2.1 推送模式（push）

节点A随机选择联系节点B，并向其发送自己的信息，节点B在收到信息后比较/更新自己的数据。

图20 推方式

2.2.2 拉取模式（pull）

节点A随机选择联系节点B，从对方获取信息，节点A在收到信息后比较/更新自己的数据。

图21 拉方式

2.2.3 推/拉模式（push/pull）

节点A向选择的节点B发送信息，同时从对方获取信息，节点A和节点B在收到信息后各自比较/更新自己的数据。

图22 推/拉方式

2.3 优缺点

• 优点
  
  
  
  • 可扩展性（Scalable）: Gossip协议是可扩展的，一般需要 O(logN) 轮就可以将信息传播到所有的节点，其中N代表节点的个数。每个节点仅发送固定数量的消息，并且与网络中节点数目无关。在数据传送时，节点并不会等待消息的Ack，所以消息传送失败也没有关系，因为可以通过其他节点将消息传递给之前传送失败的节点。允许节点的任意增加和减少，新增节点的数据最终会与其他节点一致。
  
  
  • 容错（Fault-tolerance）: 网络中任何节点的重启或者宕机都不会影响 Gossip 消息的传播，具有天然的分布式系统容错特性。
  
  
  • 健壮性（Robust）: Gossip协议是去中心化的协议，集群中的所有节点都是对等的，没有特殊的节点，所以任何节点出现问题都不会阻止其他节点继续发送消息。任何节点都可以随时加入或离开，而不会影响系统的整体服务质量。
  
  
  • 最终一致性（Convergent consistency）: Gossip协议实现信息指数级的快速传播，因此在有新信息需要传播时，消息可以快速地发送到全局节点，在有限的时间内能够做到所有节点都拥有最新的数据。
  
  
  
  


• 缺点
  
  
  
  • 消息延迟：节点随机向少数几个节点发送消息，消息最终是通过多个轮次的散播而到达全网，不可避免的造成消息延迟。
  
  
  • 消息冗余：节点定期随机选择周围节点发送消息，而收到消息的节点也会重复该步骤，不可避免地引起同一节点消息多次接收，增加消息处理压力。
  
  
  
  

三、参考

• raft.github.io


• thesecretlivesofdata.com/raft/


• Raft算法（一）：如何选举领导者？


• Raft算法（二）：如何复制日志？


• Raft算法（三）：如何解决成员变更的问题？


• 如何解决分布式系统中的“幽灵复现”？


• Gossip协议：流言蜚语，原来也可以实现一致性


• 浅谈集群版Redis和Gossip协议，它们之间的联系及用法


• 分布式一致协议Gossip协议


• 分布式原理：一文了解 Gossip 协议


• 从Ping-Pong消息学习Gossip协议的实现

前言

之前面试经常被问到 CSRF， 跨站请求伪造

大概流程比较简单， 大概就是用户登录了A页面，存下来登录凭证（cookie）， 攻击者有诱导受害者打开了B页面， B页面中正好像A发送了一个跨域请求，并把cookie进行了携带， 欺骗浏览器以为是用户的行为，进而达到执行危险行为的目的，完成攻击

上面就是面试时，我们通常的回答， 但是到底是不是真是这样呢? 难道这么容易伪造吗？于是我就打算试一下能不能实现

接下来，我们就通过node起两个服务 A服务（端口3000）和B服务（端口4000）， 然后通过两个页面 A页面、和B页面模拟一下CSRF。

我们先约定一下 B页面是正常的页面， 起一个 4000 的服务， 然后 A页面为伪造者的网站， 服务为3000

先看B页面的代码, B页面有一个登录，和一个获取数据的按钮， 模拟正常网站，需要登录后才可以获取数据

<body>

    <div>

      正常 页面 B

      <button onclick="login()">登录</button>

      <button onclick="getList()">拿数据</button>

      <ul class="box"></ul>

      <div class="tip"></div>

    </div>

  </body>

  <script>

    async function login() {

      const response = await fetch("http://localhost:4000/login", {

        method: "POST",

      });

      const res = await response.json();

      console.log(res, "writeCookie");

      if (res.data === "success") {

        document.querySelector(".tip").innerHTML = "登录成功， 可以拿数据";

      }

    }



    async function getList() {

      const response = await fetch("http://localhost:4000/list", {

        method: "GET",

      });



      if (response.status === 500) {

        document.querySelector(".tip").innerHTML = "cookie失效，请先登录！";

        document.querySelector(".box").innerHTML = "";

      } else {

        document.querySelector(".tip").innerHTML = "";

        const data = await response.json();

        let html = "";

        data.map((el) => {

          html += `<div>${el.id} - ${el.name}</div>`;

        });

        document.querySelector(".box").innerHTML = html;

      }

    }

  </script>

在看B页面的服务端代码如下：

const express = require("express");

const app = express();



app.use(express.json()); // json

app.use(express.urlencoded({ extends: true })); // x-www-form-urlencoded



app.use((req, res, next) => {

  res.header("Access-Control-Allow-Origin", "*");

  // 允许客户端跨域传递的请求头

  res.header("Access-Control-Allow-Headers", "Content-Type");

  next();

});



app.use(express.static("public"));



app.get("/list", (req, res) => {

  const cookie = req.headers.cookie;

  if (cookie !== "user=allow") {

    res.sendStatus("500");

  } else {

    res.json([

      { id: 1, name: "zhangsan" },

      { id: 2, name: "lisi" },

    ]);

  }

});



app.post("/login", (req, res) => {

  res.cookie("user", "allow", {

    expires: new Date(Date.now() + 86400 * 1000),

  });

  res.send({ data: "success" });

});



app.post("/delete", (req, res) => {

  const cookie = req.headers.cookie;

  if (req.headers.referer !== req.headers.host) {

    console.log("should ban!");

  }

  if (cookie !== "user=allow") {

    res.sendStatus("500");

  } else {

    res.json({

      data: "delete success",

    });

  }

});



app.listen(4000, () => {

  console.log("sever 4000");

});

B 服务有三个接口， 登录、获取列表、删除。 再触发登录接口的时候，会像浏览器写入cookie， 再删除或者获取列表的时候，都先检测有没有将指定的cookie传回，如果有就认为有权限

然后我们打开 http://localhost:4000/B.html 先看看B页面功能是否都正常

我们看到此时 B 页面功能和接口都是正常的， cookie 也正常进行了设置，每次获取数据的时候，都是会携带cookie到服务端校验的

那么接下来我们就通过A页面，起一个3000端口的服务，来模拟一下跨域情况下，能否完成获取 B服务器数据，调用 B 服务器删除接口的功能

A页面代码

  <body>

    <div>

      伪造者页面 A

      <form action="http://localhost:4000/delete" method="POST">

        <input type="hidden" name="account" value="xiaoming" />

      </form>

      <script>

        // 这行可以放到控制台执行，便于观察效果

        // document.forms[0].submit();

      </script>

    </div>

    <ul class="box"></ul>

    <div class="tip"></div>

</body>

A页面服务端代码

  <body>

    <div>

      伪造者页面 A

      <form action="http://localhost:4000/delete" method="POST">

        <input type="hidden" name="account" value="xiaoming" />

      </form>

      <script>

        // 这行可以放到控制台输入

        // document.forms[0].submit();

      </script>

      <script src="http://localhost:4000/list"></script>

    </div>

  </body>

于是在我们 访问 http://localhost:3000/A.html 页面的时候发现， 发现list列表确实，请求到了， 控制台输入 document.forms[0].submit() 时发现，确实删除也发送成功了， 是不是说明csrf就成功了呢， 但是其实还不是， 关键的一点是， 我们在B页面设置cookie的时候， domain设置的是 localhost 那么其实在A页面， 发送请求的时候cookie是共享的状态， 真实情况下，肯定不会是这样， 那么为了模拟真实情况， 我们把 http://localhost:3000/A.html 改为 http://127.0.0.1:3000/A.html, 这时发现，以及无法访问了， 那么这是怎么回事呢， 说好的，cookie 会在获取过登录凭证下， 再次访问时可以携带呢。

于是，想了半天也没有想明白， 难道是浏览器限制严格进行了限制， 限制规避了这个问题？ 难道我们背的面试题是错误的？

有知道的

前言

前端领域有多种流程库可供选择，包括但不限于vue-flow、butterfly、JointJS、AntV G6、jsPlumb和Flowchart.js。这些库都提供了用于创建流程图、图形编辑和交互的功能。然而，它们在特性、易用性和生态系统方面存在一些差异。

流程图插件汇总

流程图插件分析

vue-flow

简介

vue-flow是 ReactFlow 的 Vue 版本，目前只支持 在Vue3中使用，对Vue2不兼容，目前国内使用较少。包含四个功能组件 core、background、controls、minimap，可按需使用。

使用

Vue Flow 是Vue下流程绘制库。安装：

npm i --save @vue-flow/core 安装核心组件

npm i --save @vue-flow/background 安装背景组件

npm i --save @vue-flow/controls 安装控件（放大，缩小等）组件

npm i --save @vue-flow/minimap 安装缩略图组件



引入组件：

import { Panel, PanelPosition, VueFlow, isNode, useVueFlow } from '@vue-flow/core'

import { Background } from '@vue-flow/background'

import { Controls } from '@vue-flow/controls'

import { MiniMap } from '@vue-flow/minimap'



引入样式：

@import '@vue-flow/core/dist/style.css';

@import '@vue-flow/core/dist/theme-default.css';