本人写了五年的后台管理。每次面试前就会头疼，因为写的页面除了表单就是表格。抱怨过苦恼过也后悔过，但是站在现在的时间点回想以前，发现有很多事情可以做的更好，于是有了这篇文章。

写优雅的代码

一道面试题

大概两年以前，面试美团的时候，面试官让我写一道代码题，时间单位转换。具体的题目我忘记了。

原题目我没做过，但是我写的业务代码代码里有类似的单位转换，后端返回一个数字，单位是kb，而我要展示成 KB，MB 等形式。大概写一个工具函数（具体怎么写的忘记了，不过功能比这个复杂点）：

function formatSizeUnits(kb) {

    let units = ['KB', 'MB', 'GB', 'TB', 'PB'];

    let unitIndex = 0;



    while (kb >= 1024 && unitIndex < units.length - 1) {

        kb /= 1024;

        unitIndex++;

    }



    return `${kb.toFixed(2)} ${units[unitIndex]}`;

}

而在此之前，是一个后端同学写的代码（说起来，后台管理系统前端人力不够后端帮忙写好像是常规操作，后端总觉得写前端简单，而我只能说你们那代码写的，一言难尽……），如下：

function formatSizeUnits(kb) {

    var result = '';



    if (kb < 1024) {

        result = kb + ' KB';

    } else if (kb < 1024 * 1024) {

        result = (kb / 1024).toFixed(2) + ' MB';

    } else if (kb < 1024 * 1024 * 1024) {

        result = (kb / 1024 / 1024).toFixed(2) + ' GB';

    } else {

        result = (kb / 1024 / 1024 / 1024).toFixed(2) + ' TB';

    }



    return result;

}

虽然功能都一样，但是我写在面试的时候写了上面的代码得到了面试官的赞扬，也因此非常顺利的通过了面试。而如果我写成了下面的样子，估计不会有这种效果。

如何提升代码质量

想提升代码质量，最理想的是靠 code review ，但实际上这玩意在大多数公司根本就不存在。其次就只能多看看大佬们写的代码，但是一来后台管理本来就没太大难度很少有大佬，二来很多时候一个后台管理系统就一两个人负责。

还好现在有了各种 AI 工具，可以非常方便的优化自己的代码了。

还是上面的问题，看看 GPT 给的答案

// 提问：写一个工具函数，对文件大小的单位进行转换，加注释

// 回答：下面是一个JavaScript工具函数，它接受文件大小、初始单位、目标单位和小数位数，然后返回目标单位下的文件大小。



/**

 * 将文件大小从一个单位转换为另一个单位。

 *

 * @param {number} size 文件大小。

 * @param {string} fromUnit 初始单位（'B', 'KB', 'MB', 'GB', 'TB', 'PB', 'EB', 'ZB', 'YB'）。

 * @param {string} toUnit 目标单位（'B', 'KB', 'MB', 'GB', 'TB', 'PB', 'EB', 'ZB', 'YB'）。

 * @param {number} [decimalPoint=2] 结果保留的小数位数，默认为2。

 * @return {string} 转换后的文件大小，带单位。

 */

function convertFileSize(size, fromUnit, toUnit, decimalPoint = 2) {

  // 定义单位与字节之间的转换关系

  const units = ['B', 'KB', 'MB', 'GB', 'TB', 'PB', 'EB', 'ZB', 'YB'];

  // 获取初始单位和目标单位的索引

  const fromIndex = units.indexOf(fromUnit);

  const toIndex = units.indexOf(toUnit);



  // 如果单位不在列表中，抛出错误

  if (fromIndex === -1 || toIndex === -1) {

    throw new Error('Invalid units');

  }



  // 计算初始单位与目标单位之间的转换系数

  const exponent = toIndex - fromIndex;

  // 计算结果大小

  const resultSize = size / Math.pow(1024, exponent);



  // 返回格式化后的结果

  return parseFloat(resultSize.toFixed(decimalPoint)) + ' ' + toUnit;

}



// 示例使用

console.log(convertFileSize(1, 'GB', 'MB')); // 输出: 1024.00 MB

console.log(convertFileSize(1, 'MB', 'KB')); // 输出: 1024.00 KB

console.log(convertFileSize(1, 'KB', 'B'));  // 输出: 1024.00 B

console.log(convertFileSize(1, 'MB', 'GB', 5)); // 输出: 0.00098 GB

还能说什么，我只能说 NB！（经评论区提示，此段代码可能有问题，建议大家在使用AI工具时，重点是借鉴思路，直接使用代码需要谨慎~）

我现在每次写大段逻辑之后都习惯拿给 AI 看看，有什么更好的实现方式，或者用什么设计模式。AI 是非常低成本且高效提升代码质量的工具。

学会封装

一个功能用到了好多次，为什么不封装成组件？一个组件用到了好几个项目，为什么不单独写个npm包？差不多的项目创建了好几个，为什么不封装成脚手架？

你说，没时间，没必要，复制粘贴反而更快。

那你就完全没理解，这么做不一定是为了让工作更快完成，而是可以让你在年年终述职时更有话说（你就算写了一百个表单表格没有写一个脚手架更值得炫耀），如果不会写可以问问 AI。

而当你真正开始封装组件，开始写工具库了，你会发现你需要思考的确实比之前多了。

关注业务

对于前端业务重要吗？

相比于后端来说，前端一般不会太关注业务。就算出了问题大部分也是后端的问题。

但是就我找工作的经验，业务非常重要！

如果你做的工作很有技术含量，比如你在做低代码，你可以面试时讲一个小时的技术难点。但是你只是一个破写后台管理，你什么都没有的说。这个时候，了解业务就成为了你的亮点。

一场面试

还是拿真实的面试场景举例，当时前同事推我字节，也是我面试过N次的梦中情厂了，刚好那个组做的业务和我之前呆的组做的一模一样。

• 同事：“做的东西和咱们之前都是一样的，你随便走个过场就能过，我在前端组长面前都夸过你了！”


• 我：“好嘞！”

等到面试的时候：

• 前端ld：“你知道xxx吗？（业务名词）”


• 我：“我……”


• 前端ld：“那xxxx呢？（业务名词）”


• 我：“不……”


• 前端ld：“那xxxxx呢？？（业务名词）”


• 我：“造……”

然后我就挂了………………

如何了解业务

关注源码

说到源码， Vue，React 这些基本是每次必问，也有太多大佬们的总结我就不多说了。

除此之外，我想大家每次面试应该都会被问，你写了什么亮点的项目，困难的项目，你会说什么？哦，都是表单表格，都用 Element UI 实现的，没什么难度。那估计你面试也就到这里了。

那说什么，后台管理就这些啊？！

如果你用了 Element UI 你可以说写了什么自定义 Element UI 表单组件，Element UI 表单源码是什么原理，怎么通信的？用了 Axios 可以说 Axios 的原理，它的拦截器怎么实现的？用了编辑器 diff 那你知道 diff 算法是什么吗？用了 ECharts 那你知道他底层是用什么绘制的吗？用了 husky ？husky的原理是什么？用了Vite，它为什么快？是怎么打包的？写过插件吗？

可能有人觉得我离谱，事实上上面每一个问题都是我在面试中真实被问到的。当然，如果全部去了解，肯定不现实，每个人的精力有限，不可能每个用到的每个工具每个库都去了解原理，不过只要有一两个你去了解过，就可以在面试中引导面试官来问，要学会表现出你擅长的点。

至于怎么读源码？以前我不知道，现在嘛…… 为什么不问问神奇的 ChatGPT 呢？

讲一下 Axios 源码中，拦截器是怎么实现的？

Axios 的拦截器实现基于 Axios 的核心原理，即 Axios 实例是一个包含请求和响应拦截器堆栈的对象。当发出请求或接收响应时，Axios 会遍历这些拦截器，并按照添加的顺序执行请求拦截器，以及按照相反的顺序执行响应拦截器。

在 Axios 的源码中，拦截器是通过一个 AxiosInterceptorManager 实例来管理的，它维护了一个拦截器数组。每个拦截器都是一个包含 fulfilled 和 rejected 函数的对象。这两个函数分别对应于拦截器成功处理和拦截器处理出错的情况。

以下是 Axios 拦截器管理器的一个简化版本，展示了其核心实现思路：

class InterceptorManager {

  constructor() {

    this.handlers = []; // 存储拦截器的数组

  }



  use(fulfilled, rejected) {

    this.handlers.push({

      fulfilled: fulfilled,

      rejected: rejected

    });

    return this.handlers.length - 1; // 返回拦截器的ID

  }



  eject(id) {

    if (this.handlers[id]) {

      this.handlers[id] = null; // 移除拦截器

    }

  }



  forEach(fn) {

    this.handlers.forEach((h) => {

      if (h !== null) {

        fn(h);

      }

    });

  }

}

在发送请求或接收响应时，Axios 会创建一个 promise 链，并通过 forEach 方法将拦截器中的 fulfilled 和 rejected 函数添加到这个链中。这样，每个拦截器都可以对请求或响应进行处理，然后将结果传递到链的下一个拦截器，或者在出错时结束链的执行。

axios.interceptors.request.forEach(function unshiftRequestInterceptors(interceptor) {

  chain.unshift(interceptor.fulfilled, interceptor.rejected);

});



axios.interceptors.response.forEach(function pushResponseInterceptors(interceptor) {

  chain.push(interceptor.fulfilled, interceptor.rejected);

});

在 Axios 的完整实现中，这个拦截器机制被集成到了 Axios 的请求发送和响应处理流程中。通过这种方式，Axios 可以在发送请求之前和接收响应之后，但在用户定义的 .then 或 .catch 执行之前，插入自定义的逻辑。

请注意，这里提供的代码只是为了说明 Axios 拦截器的实现原理，并不是 Axios 源码的完整复制。如果你对 Axios 的拦截器实现细节感兴趣，建议查看 Axios 的官方 GitHub 仓库中的源码。

前端基建

当我们工作时间久了面试难免会遇到这些问题，前端工程化，前端监控，工作流，部署，性能等等。其实我们在工作中绝大部分时间都在写代码，对于这些不是所有人都有机会接触到，不过这些和所做的业务无关，是我们提升自己很好的一个思路。

技术选型

技术栈选 Vue 还是 React？Vue 选 Vue2 还是 Vue3？组件库选 ElementUI 还是 Ant Design？微前端有没有使用过？打包工具用 Vite 还是 Webpack？有那么多表单怎么实现的，有没有什么表单配置化方案，比如Formily？

对于我这种菜鸡，我这种只写简单的表单表格的人，这些都……无所谓……

不过为了应对面试我们还是需要了解下未选择技术栈的缺点，和已选择技术栈的优点（有点本末倒置…但是常规操作啦）

Vue 你可以说简单高效轻量级，面试必会问你为什么，你就开始说 Vue 的响应式系统，依赖收集等。

React 你可以说 JSX、Hooks 很灵活，那你必然要考虑 JSX 怎么编译， Hooks 实现方式等。

总体而言，对于技术选型，依赖于我们对所有可选项的理解，做选择可能很容易，给出合理的理由还是需要花费一些精力的。

开发规范

这个方面，在面试的时候我被问到的不多，我们可以在创建项目的时候，配置下 ESlint，stylelint， prettier， commitlint 等。

前端监控

干了这么多年前端，前端监控我是……一点没做过。

前端监控，简单来说就是我们在前端程序中记录一些信息并上报，一般是错误信息，来方便我们及时发现问题并解决问题。除此之外也会有性能监控，用户行为的监控（埋点）等。之前也听过有些团队分享前端监控，为了出现问题明确责任（方便甩锅）。

对于实现方案，无论使用第三方库还是自己实现，重要的都是理解实现原理。

对于错误监控，可以了解一下 Sentry，原理简单来说就是通过 window.onerror 和 window.addEventListener('unhandledrejection', ...) 去分别捕获同步和异步错误，然后通过错误信息和 sourceMap 来定位到源码。

对于性能监控，我们可以通过 window.performance、PerformanceObserver 等 API 收集页面性能相关的指标，除此之外，还需要关注接口的响应时间。

最后，收集到信息之后，还要考虑数据上报的方案，比如使用 navigator.sendBeacon 还是 Fetch、AJAX？是批量上报，实时上报，还是延迟上报？上报的数据格式等等。

CI/CD

持续集成（Continuous Integration, CI）和 持续部署（Continuous Deployment, CD），主要包括版本控制，代码合并，构建，单测，部署等一系列前端工作流。

场景的工作流有 Jenkins、 Gitlab CI 等。我们可以配置在合并代码时自动打包部署，在提交代码时自动构建并发布包等。

这块我了解不多，但感觉这些工具层面的东西，不太会涉及到原理，基本上就是使用的问题。还是需要自己亲自动手试一下，才能知道细节。比如在 Gitlab CI 中， Pipeline 、 Stage 和 Job 分别是什么，怎么配置，如何在不同环境配置不同工作流等。

了解技术动态

这个可能还是比较依赖信息收集能力，虽然我个人觉得很烦，但好像很多领导级别的面试很愿意问。

比如近几年很火的低代码，很多面试官都会问，你用过就问你细节，你没用过也会问你有什么设计思路。

还有最近的两年爆火的 AI，又或者 Vue React的最新功能，WebAssembly，还有一些新的打包工具 Vite Bun 什么的，还有鸿蒙开发……

虽然不可能学完每一项新技术，但是可以多去了解下。

总结

写了这么多，可能有人会问，如果能回到过去，你会怎么做。

啊，我只能说，说是一回事，做又是另一回事，事实上我并不希望回到过去去卷一遍，菜点没关系，快乐就好，一切都是最好的安排。

前言

如果你是一名前端开发，那么你多少有了解过requestAnimationFrame吧？如果没有也接着往下看，会有详细用法说明。

其实很多人会局限于把requestAnimationFrame应用于一些纯动画相关的需求上，但其实在前端很多业务场景下requestAnimationFrame都能用于性能优化，下面将细说一下requestAnimationFrame的具体用法和几种应用场景。

requestAnimationFrame作用与用法

requestAnimationFrame简述

MDN官方说法是这样的

基本示例

<script lang="ts" setup>

    function init() {

      console.log('您好，我是requestAnimationFrame');

    }

    requestAnimationFrame(init)

</script>

效果如下

但是例子上面是最基本的调用方式，并且只简单执行了一次，而对于动画是要一直执行的。

下面直接上图看看官方的文档对这个的说明，上面说具体用法应该要递归调用，而不是单次调用。

递归调用示例

<script lang="ts" setup>

    function init() {

      console.log('您好，递归调用requestAnimationFrame');

      requestAnimationFrame(init)

    }

    requestAnimationFrame(init)

</script>

执行动图效果如下

requestAnimationFrame会一直递归调用执行，并且调用的频率通常是与当前显示器的刷新率相匹配（这也是这个API核心优势），例如屏幕75hz就1秒执行75次。

而且如果使用的是定时器实现此功能是无法适应各种屏幕帧率的。

回调函数

requestAnimationFrame执行后的回调函数有且只会返回一个参数，并且返回的参数是一个毫秒数，这个参数所表示是的上一帧渲染的结束时间，直接看看下面代码示例与打印效果。

<script lang="ts" setup>

  function init(val) {

    console.log('您好，requestAnimationFrame回调:', val);

    requestAnimationFrame(init);

  }

  requestAnimationFrame(init);

</script>

注意： 如果我们同时调用了很多个requestAnimationFrame，那么他们会收到相同的时间戳，因为与屏幕的帧率相同所以并不会不一样。

终止执行

终止此API的执行，官方提供的方法是window.cancelAnimationFrame()，语法如下

ancelAnimationFrame(requestID)   

直接看示例更便于理解，用法非常类似定时器的clearTimeout()，直接把 requestAnimationFrame 返回值传给 cancelAnimationFrame() 即可终止执行。

<template>

  <div>

    <button @click="stop">停止</button>

  </div>

</template>

<script lang="ts" setup>

  let myReq;

  function init(val) {

    console.log('您好，requestAnimationFrame回调:', val);

    myReq = requestAnimationFrame(init);

  }

  requestAnimationFrame(init);



  function stop() {

    cancelAnimationFrame(myReq);

  }

</script>

requestAnimationFrame优势

1、动画更丝滑，不会出现卡顿

对比传统的setTimeout 和 setInterval动画会更流畅丝滑。

主要 原因 是由于运行的浏览器会监听显示器返回的VSync信号确保同步，收到信号后再开始新的渲染周期，因此做到了与浏览器绘制频率绝对一致。所以帧率会相当平稳，例如显示屏60hz，那么会固定1000/60ms刷新一次。

但如果使用的是setTimeout 和 setInterval来实现同样的动画效果，它们会受到事件队列宏任务、微任务影响会导致执行的优先级顺序有所差异，自然做不到与绘制同频。

所以使用setTimeout 和 setInterval不但无法自动匹配显示屏帧率，也无法做到完全固定的时间去刷新。

2、性能更好，切后台会暂停

当我们把使用了requestAnimationFrame的页面切换到后台运行时，requestAnimationFrame会暂停执行从而提高性能，切换回来后会马上提着执行。

效果如下动图，隐藏后停止运行，切换回来接着运行。

应用场景：常规动画

用一个很简单的示例：用requestAnimationFrame使一张图片动态也丝滑旋转，直接看示例代码和效果。

思路：首先在页面初始化时执行window.requestAnimationFrame(animate)使动画动起来，实现动画一直丝滑转运。在关闭页面时用window.cancelAnimationFrame(rafId)去终止执行。

<template>

  <div class="container">

    <div :style="imgStyle" class="earth"></div>

  </div>

</template>



<script setup>

  import { ref, onMounted, reactive, onUnmounted } from 'vue';



  const imgStyle = reactive({

    transform: 'rotate(0deg)',

  });



  let rafId = null;



  // 请求动画帧方法

  function animate(time) {

    const angle = (time % 10000) / 5; // 控制转的速度

    imgStyle.transform = `rotate(${angle}deg)`;



    rafId = window.requestAnimationFrame(animate);

  }



  // 开始动画

  onMounted(() => {

    rafId = window.requestAnimationFrame(animate);

  });



  // 卸载时生命周末停止动画

  onUnmounted(() => {

    if (rafId) {

      window.cancelAnimationFrame(rafId);

    }

  });

</script>



<style scoped>

  body {

    box-sizing: border-box;

    background-color: #ccc;

    height: 100vh;

    display: flex;

    justify-content: center;

    align-items: center;

  }



  .container {

    position: relative;

    height: 100%;

    width: 100%;

    display: flex;

    flex-direction: column;

    align-items: center;

    justify-content: center;

  }



  .earth {

    height: 100px;

    width: 100px;

    background-size: cover;

    border-radius: 50%;

    background-image: url('@/assets/images/about_advantage_3.png'); /* 替换为实际的路径 */

  }

</style>

看看动图效果

应用场景：滚动加载

在滚动事件中用requestAnimationFrame去加载渲染数据使混动效果更加丝滑。主要好久有几个

• 提高性能: 添加requestAnimationFrame之后会在下一帧渲染之前执行，而不是每次在滚动事件触发的时候就立即执行。这可以减少大量不必要的计算，提高性能。


• 用户体验更好：确保在绘制下一帧时再执行，使帧率与显示屏相同，视觉上会更丝滑。

代码示例和效果如下。

<template>

  <div class="container" ref="scrollRef">

    <div v-for="(item, index) in items" :key="index" class="item">

      {{ item }}

    </div>

    <div v-if="loading" class="loading">数据加载中...</div>

  </div>

</template>



<script setup lang="ts">

import { ref, onMounted, onUnmounted } from 'vue';



const loading = ref(false);

let rafId: number | null = null;

// 数据列表

const items = ref<string[]>(Array.from({ length: 50 }, (_, i) => `Test ${i + 1}`));



// 滚动容器

const scrollRef = ref<HTMLElement | null>(null);



// 模拟一个异步加载数据效果

const moreData = () => {

  return new Promise<void>((resolve) => {

    setTimeout(() => {

      const newItems = Array.from({ length: 50 }, (_, i) => `Test ${items.value.length + i + 1}`);

      items.value.push(...newItems);

      resolve();

    }, 1000);

  });

};



// 检查是否需要加载更多数据

const checkScrollPosition = () => {

  if (loading.value) return;



  const container = scrollRef.value;

  if (!container) return;



  const scrollTop = container.scrollTop;

  const clientHeight = container.clientHeight;

  const scrollHeight = container.scrollHeight;



  if (scrollHeight - scrollTop - clientHeight <= 100) {

    startLoading();

  }

};



// 加载数据

const startLoading = async () => {

  loading.value = true;

  await moreData();

  loading.value = false;

};



// 监听滚动事件

const handleScroll = () => {

  console.log('滚动事件触发啦');

  if (rafId !== null) {

    window.cancelAnimationFrame(rafId);

  }

  rafId = window.requestAnimationFrame(checkScrollPosition);

};



// 添加滚动事件监听器

onMounted(() => {

  if (scrollRef.value) {

    scrollRef.value.addEventListener('scroll', handleScroll);

  }

});



// 移除相关事件

onUnmounted(() => {

  if (rafId !== null) {

    window.cancelAnimationFrame(rafId);

  }

  if (scrollRef.value) {

    scrollRef.value.removeEventListener('scroll', handleScroll);

  }

});

</script>



<style scoped>

.container {

  padding: 20px;

  max-width: 800px;

  overflow-y: auto;

  margin: 0 auto;

  height: 600px; 

}



.item {

  border-bottom: 1px solid #ccc;

  padding: 10px;

}



.loading {

  padding: 10px;

  color: #999;

  text-align: center;

}

</style>

看看下面动图效果

小结

通过代码示例配合动图讲解后，再通过两个简单的事例可能大家会发现，只要在页面需要运动的地方其实都可以用到 requestAnimationFrame 使效果变的更加丝滑。

除了上面两个小示例其它非常多地方都可以用到requestAnimationFrame去优化性能，比较常见的例如游戏开发、各种动画效果和动态变化的布局等等。

文章就写到这啦，如果文章写的哪里不对或者有什么建议欢迎指出。

一次代码CR引发的困惑

const asyncErrorThrow = () => {

  return new Promise((resolve, reject) => {

    // 业务代码...

    // 假设这里抛出了错误

    throw new Error('抛出错误');

    // 业务代码...

  })

}

const testFun = async () => {

  await asyncErrorThrow();

  console.log("async 函数中的后续流程"); // 不会执行

}

testFun();

在 testFun 函数中，抛出错误后，await 函数中后续流程不会执行。

仔细回想一下，在我的前端日常开发中，对于错误捕获，还基本停留在使用 Promise时用 catch 捕获一下 Promise 中抛出的错误或者 reject，或者最基本的，在使用 JSON.parse、JSON.stringfy等容易出错的方法中，使用 try..catch... 方法捕获一下可能出现的错误。

后来，这个同学将代码改成了：

const asyncErrorThrow = () => {

  return new Promise((resolve, reject) => {

    // 业务代码...

    throw new Error('抛出错误');

    // 业务代码...

  })

}

const testFun = async () => {

  try {

    await asyncErrorThrow();

    console.log("async 函数中的后续流程"); // 不会执行

  } catch (error) {

    console.log("若错误发生 async 函数中的后续流程"); // 会执行

  } 

}

testFun();

而这次不同的是，这段修改后的代码中使用了 try...catch...来捕获 async...await... 函数中的错误，这着实让我有些困惑，让我来写的话，我可能会在 await 函数的后面增加一个 catch：await asyncErrorThrow().catch(error => {})。因为我之前已经对 try..catch 只能捕获发生在当前执行上下文的错误（或者简单理解成同步代码的错误）有了一定的认知，但是 async...await... 其实还是异步的代码，只不过用的是同步的写法，为啥用在这里就可以捕获到错误了呢？在查阅了相当多的资料之后，才清楚了其中的一些原理。

Promise 中的错误

• 待定（pending）：初始状态，既没有被兑现，也没有被拒绝。


• 已兑现（fulfilled）：意味着操作成功完成。


• 已拒绝（rejected）：意味着操作失败。

当一个 Promise 被 reject 时，该 Promise 会变为 rejected 状态，控制权将移交至最近的 rejection 处理程序。最常见的 rejection 处理程序就是 catch handler或者 then 函数的第二个回调函数。而如果在 Promise 中抛出了一个错误。这个 Promise 会直接变成 rejected 状态，控制权移交至最近的 error 处理程序。

const function myExecutorFunc = () => {

  // 同步代码

  throw new Error();

};

new Promise(myExecutorFunc);

Promise 的构造函数需要传入的 Executor 函数参数，实际上是一段同步代码。在我们 new 一个新的 Promise 时，这个 Executor 就会立即被塞入到当前的执行上下文栈中进行执行。但是，在 Executor 中 throw 出的错误，并不会被外层的 try...catch 捕获到。

const myExecutorFunc = () => {

  // 同步代码

  throw new Error();

};

try {

  new Promise(myExecutorFunc);

} catch (error) {

  console.log('不会执行: ', error);

}

console.log('会执行的'); // 打印

其原因是因为，在 Executor 函数执行的过程中，实际上有一个隐藏的机制，当同步抛出错误时，相当于执行了 reject 回调，让该 Promise 进入 rejected 状态。而错误不会影响到外层的代码执行。

const myExecutorFunc = () => {

  throw new Error();

  // 等同于

  reject(new Error());

};

new Promise(myExecutorFunc);

console.log('会执行的'); // 打印

同理 then 回调函数也是这样的，抛出的错误同样会变成 reject。

在一个普通脚本执行中，我们知道抛出一个错误，如果没有被捕获掉，会影响到后续代码的执行，而在 Promise 中，这个错误不会影响到外部代码的执行。对于 Promise 没有被捕获的错误，我们可以通过特定的事件处理函数来观察到。

new Promise(function() {

  throw new Error("");

}); // 没有用来处理 error 的 catch

// Web 标准实现

window.addEventListener('unhandledrejection', function(event) {

  console.log(event);

  // 可以在这里采取其他措施，如日志记录或应用程序关闭

});

// Node 下的实现

process.on('unhandledRejection', (event) => {

  console.log(event);

  // 可以在这里采取其他措施，如日志记录或应用程序关闭

});

Promise 是这样实现的，我们可以想一想为什么要这样实现。我看到一个比较好的回答是这个：

传送门。我也比较赞成他的说法，我觉得，Promise 的诞生是为了解决异步函数过多而形成的回调地狱，使用了微任务的底层机制来实现异步链式调用。理论上是可以将同步的错误向上冒泡抛出然后用 try...catch... 接住的，异步的一些错误用 catch handler 统一处理，但是这样做的话会使得 Promise 的错误捕获使用起来不够直观，如果同步的错误也进行 reject 的话，实际上我们处理错误的方式就可以统一成 Promise catch handler 了，这样其实更直观也更容易让开发者理解和编写代码。

async await 的问题

const asyncErrorThrow = () => {

  return new Promise((resolve, reject) => {

    // 业务代码...

    throw new Error('抛出错误');

    // 业务代码...

  })

}

const testFun = async () => {

  try {

    await asyncErrorThrow();

    console.log("async 函数中的后续流程"); // 不会执行

  } catch (error) {

    console.log("若错误发生 async 函数中的后续流程"); // 会执行

  } 

}

testFun();

我思考了很久，最后还是从黄玄大佬的知乎回答中窥见的一部分原理。

这...难道就是浏览器底层帮我们处理的事儿吗，不然也没法解释了。唯一能够解释的事就是，async await 原本就是为了让开发者使用同步的写法编写异步代码，目的是消除过多的 Promise 调用链，我们在使用 async await 时，最好就是不使用 .catch 来捕获错误了，而直接能使用同步的 try...catch... 语法来捕获错误。即使 .catch 也能做同样的事情。只是说，代码编写风格统一性的问题让我们原本能之间用同步语法捕获的错误，就不需要使用 .catch 链式调用了，否则代码风格看起来会有点“异类”。

这就是为什么 async MDN 中会有这样一句解释：

参考文档：

《使用Promise进行错误治理》- zh.javascript.info/promise-err…

《为什么try catch能捕捉 await 后 promise 错误？ 和执行栈有关系吗？》http://www.zhihu.com/question/52…

大家好，我是CodeQi！  一位热衷于技术分享的码仔。

在日常的开发中，很多人习惯于使用 if-else 语句来处理各种条件。但你有没有想过，层层嵌套的条件判断，可能会让代码变得难以维护且难以阅读？今天，我想分享一个让代码更清晰易读的技巧，那就是——return。✨

if-else 真的有必要吗？

初学编程时，我们都习惯通过 if-else 语句来处理分支逻辑。比如判断一个用户是否活跃，是否有折扣，代码通常会写成这样：

function getDiscountMessage(user) {

  if (user.isActive) {

    if (user.hasDiscount) {

      return `折扣已应用于 ${user.name}！`;

    } else {

      return `${user.name} 不符合折扣条件。`;

    }

  } else {

    return `用户 ${user.name} 已被停用。`;

  }

}

你看，这段代码嵌套了多个 if-else 语句。如果我们继续在这种风格的代码上添加更多条件判断，会变得更加难以阅读和维护。过多的嵌套让人一眼难以理清逻辑。更严重的是，随着代码量增多，容易导致出错。

return：清晰与高效的代码编写方式

所谓的提前return，就是在遇到异常情况或不符合条件时，立即返回并结束函数。通过提前处理错误情况或边界情况，我们可以把代码的“理想情况”留到最后处理。这种写法可以让代码更清晰，逻辑更加直接。🎯

示例：用return优化代码

来看一看如何用return来重写上面的代码：

function getDiscountMessage(user) {

  if (!user.isActive) {

    return `用户 ${user.name} 已被停用。`;

  }



  if (!user.hasDiscount) {

    return `${user.name} 不符合折扣条件。`;

  }



  // 理想情况：用户活跃且符合折扣条件

  return `折扣已应用于 ${user.name}！`;

}

🌟 优势

return vs if-else：一个真实场景

假设我们有一个需要检查多个条件的函数，validateOrder，要确保订单状态有效、用户有权限、库存足够等情况：

function validateOrder(order) {

  if (!order.isValid) {

    return `订单无效。`;

  }



  if (!order.userHasPermission) {

    return `用户无权限。`;

  }



  if (!order.hasStock) {

    return `库存不足。`;

  }



  // 理想情况：订单有效，用户有权限，库存足够

  return `订单已成功验证！`;

}

通过这种方式，我们将所有不符合条件的情况都提前处理掉，将主逻辑留到最后一行。这不仅让代码更易读，而且可以提高代码的运行效率，因为无须进入嵌套的条件分支。🎉

何时使用return

虽然提前return是优化代码的好方式，但并不是所有情况下都适用。以下是一些适用场景：

• 多条件判断：需要检查多个条件时，尤其是多个边界条件。


• 简单条件过滤：对于不符合条件的情况可以快速返回，避免执行复杂逻辑。


• 确保主要逻辑代码始终位于底部：这样可以减少逻辑处理的复杂性。

结语

当我们写代码时，保持代码简洁明了是一项重要的原则。通过采用提前return，我们可以减少嵌套层次，避免过度依赖 if-else，让代码更直观、易维护。如果你还没有使用return，不妨从现在开始尝试一下！😎

下次写代码时，记得问自己一句：“这个 if-else 可以用return替换吗？ ”

让我们一起追求清晰、优雅的代码！Happy Coding! 💻

前言

由于谷歌 flutter 团队裁员，导致维护更新满足不了需求，传闻 flutter 团队不足50人，很多跨端的支持以及现有的问题都无法解决，flutter 社区foundation不满足于现有的开发进度，fock flutter维护分支Flock, 貌似不少公司组织已经在这样做了，很多问题也不能怪flutter, 比如最近发的这个问题。

问题

flutter freeze卡死的问题相信很多开发者都遇到过, 最近遇到iOS侧滑返回的导致freeze的问题，很早就发现这个问题，当时的解决方案是在首页禁止侧滑，就是导航栈只有一个页面的时禁用手势

if (self.navigationController.viewControllers.count == 1) {

    self.navigationController.interactivePopGestureRecognizer.enabled = NO;

}

此方案可以将卡死问题很大概率的降低，但是仍然会出现卡死, 可以规避但没找到根本原因

分析

最开始以为是flutter手势和iOS 系统返回手势冲突导致，app 存在一些侧滑的轮播图，经过对比发现有没有轮播图或者flutter 手势都会出现卡死。

问题可能出现在iOS 原生侧,经过尝试发现问题所在，复现代码如下

首页实现手势比如PanGuesture

UIPanGestureRecognizer *panGesture = [[UIPanGestureRecognizer alloc] initWithTarget:**self** action: **@selector**(handlePan:)];

[redView addGestureRecognizer:panGesture];

push 跳转到二级页面，二级页面对重置了导航栏的返回手势的delegate

self.navigationController.interactivePopGestureRecognizer.delegate = nil;

原因：
重置了导航栏的PopGestureRecognizer的delegate，向当前全局的侧滑返回代理回调失效，导致策划返回出现问题，禁用手势不可以讲导航栏的返回手势的delete 置为nil

Flutter为何侧滑可出现卡死，通过分析flutter的源码就很容易知道原因

结论

flutterViewController也实现了手势操作，所以使用依赖原生的flutter出现了这个问题，跳转到其他页面，将PopGestureRecognizer 置为nil, 就出现这个问题

Flutter:这真不是我的锅

感想

从20年开始接触Flutter 也有三四年时间了，Flutter的应用范围也越来越广，但是大厂对flutter的接受度还是不高，要不要继续坚持搞Flutter,作为开发未来将何去何从

什么是灰度发布

在互联网领域，灰度发布是产品质量保障的重要一环，它可以让某次更新的产品，以一种平滑，逐步扩大的方式呈现给用户，在此过程中，产品和技术团队可以对功能进行验证，收集用户反馈，不断优化，从而减少线上问题的影响范围，完善产品功能。

在前端领域，APP和小程序天生就具有灰度的能力，一般基于发布平台来控制。但 H5 却缺少这种天生能力，而且 H5 一旦发布就会影响所有用户，更加需要一套灰度系统，来保证产品的稳定性。

灰度发布的本质

既然要让部分用户先使用新功能，就需要做好两件事情，这也是灰度的本质：

那么想要实现灰度发布有哪些方案呢？

可选的灰度方案

Nginx+lua+redis

通过使用 Nginx 的反向代理特性，我们可以根据请求的特定属性（例如ip、请求头、cookie）等有选择性的将请求路由到全量或灰度版本。

同时在 Nginx 中嵌入 Lua 脚本，负责根据预定义的灰度发布策略处理请求，Lua 脚本可以从 Redis 中获取灰度配置。从而确定哪些用户可以访问新版本，那些用户应该可以访问旧版本。

Redis 用于存储灰度发布的配置数据。

通过这种方式可以实现基于 Ngnix 的灰度发布，但这种方式并不适合我们，为什么呢？

因为我们的C端H5页面连同HTML文件都是直接投放在 CDN 上，这就意味着我们没有中转服务层，无法使用第一套 Nginx 的方案，而且使用 Nginx 也会响应降低页面加载速度，虽然可能很轻微，但却是对所有用户都会有影响。

采用 Nginx 进行中转：

不采用 Nginx 中转：

如上两张图，可以很明显的看到，如果采用 Nginx 来作为中转并进行分流控制，将导致我们的 CDN 优势失效，所有的流量都可能回到上海的机房，再流转到上海的 CDN，这显然不是我们想看到的。

这也是我们放弃 Nginx+lua+redis 方案的原因。

基于 SSR 做灰度

如果我们的前端页面是通过服务端来进行渲染，可以把灰度控制继承在服务端渲染中，基于不同的用户放回不同的HTML，这样也就可以做到灰度发布。

不过这需要有一套完善的 SSR系统，对于访问量大的产品，维持系统稳定性的难度远大于实现 SSR 本身的技术难度。由于我们是前后端分离，并且没有基于 Node 高可用的运维团队和经验，所以这个方案也就放弃了。

APP拦截灰度

基于APP的方案，是在用户点击H5资源位，创建webview时，拉取灰度配置，如果当前页面有灰度，则拉取灰度配置，判断是否命中灰度，如果命中，替换H5链接即可。

看过我其他文章的朋友，应该有了解到我们针对H5秒开有一套配置下发到APP，那么灰度配置，也可以集成到原有配置中，一并下发给APP，这套方案相对而言也比较简单，但是却有如下问题。

所以最后该方案也被排除。

纯前端方案

方案概览

基于如上的一些原因，于是我们采用了一套纯前端的方案，来解决灰度发布问题，虽然这套方案也有一点缺点。前面我们提到灰度发布的本质，其实包含两个方面，一是版本控制，二是分流控制。

版本控制比较好做，我们把全量的HTML代码发布到 index.html 文件，把灰度的HTML代码发布到 gray.html 文件，这样就做到了版本控制。

分流控制，可以被拆分为两部分，一部分只管获取配置、判定是否命中灰度并入在本地，另一部只管读取结果并执行跳转，这样整个系统就解耦了。

方案大体思路是：

流程图：

时序图如下：

灰度版本控制

对于版本控制，我们通过提供了一个 webpack 插件集成到构建流程中，在构建时生成不同文件名的 html 文件。

通过构建命令参数，来区分各种发布情况

npm run build your_project_name -- --gray=open  

# --gray 的值  

# --gray=close 不打开灰度，默认值  

# --gray=open 打开灰度  

# --gray=full 灰度全量  

# --gray=unpublish 撤销灰度

可以分为如下情况：

正式发布

构建时生成：

• index.html 全量页面


• index_backup.html 全量备份页面（用来做回归）

灰度发布

构建时生成：

• gray.html 灰度页面


• gray_backup.html 灰度备份页（用来在全量后替换 index_backup.html）

同时下载 index.html ，注入灰度重定向控制JS。

重定向控制代码如下：

// 标记是否打开灰度  

window.__GRAY_SWITCH__ = 1   

let graySwitchName = 'gray_switch_';  

// 获取去除html后的pathname  

const pathname = window.location.pathname.split('/').slice(0, -1).join('/');   

graySwitchName = graySwitchName + pathname  

const graySwitch = localStorage.getItem(graySwitchName)  

if (graySwitch === '1') {  

    const grayUrl = window.location.href.replace('index.html', '_gray.html')  

    if(window.history.replaceState){  

        // 安卓 app 使用 location.replace 无效  

        window.history.replaceState(null, document.title, grayUrl);  

    }else{  

        window.location.replace(grayUrl);  

    }  

} 

修改输出的 HTML 文件名，是通过编写 webpack 的自定义插件来完成。

原理是通过 compiler.hooks.afterEmit.tapAsync 钩子函数，再 “输出” 阶段，对文件名进行修改。

撤销灰度

从云端下载 index_backup.html 重命名为 index.html 放在打包目录，之后再由发布系统上传。

全量发布

从云端下载 gray.html 和 gray_backup.html，重命名为 index.html 和 index_backup.html，发布后就会替换原有的全量HTML。

灰度分流控制

分流的重点是如何判断哪些用户能命中灰度。每个项目划分人员的策略都可能不同，比如C端页面更倾向于按useID随机划分。而B端拣货、配送等业务线，更需要按门店来进行划分，这样可以做到同门店员工体验一致，便于管理。所以这块这块必须要足够的灵活性。

我们这里采取了两种方式：

第一种是基于接口来做分流控制：把用户信息传给服务端，接口通过配置的灰度规则，计算是否命中，并返回前端。前端只管把结果存入本地。

第二种是把计算逻辑都放在前端，比较适合C端项目，因为C端项目大部分场景都是随机划分灰度用户。

灰度分流计算的JS代码是在用户每次打开后，静默运行，所以需要引入到业务代码中。

引入的代码如下：

import grayManager from '@cherry/grayManager'  

import { getMemberId } from '../utils/index'  

  

// 伪代码，说明GrayOptions 的类型  

interface GrayOptions {  

    // 灰度比例控制 支持固定值和数组阶梯灰度，配置grayScale 后，grayComputeFn无效  

    grayScale: number | [number]  

    // 自定义灰度方法，在内可以请求接口等  

    grayCompute: () => (() => Promise<boolean>) | boolean  

    // 获取维护标识，比如以 shopId 为灰度标识，该函数就返回当前用户的 shopId  

    getGaryData: () => ()=> Promise<string>,  

    // 配置灰度白名单，白名单内的用户都会命中灰度  

    whiteData: string[]  

}  

  

// 初始化灰度计算逻辑  

grayManagerInit({  

    grayScale: 10,  

    whiteData: ['123', '456']  

})

前端计算分流

随机百分比

多数项目，我们一般使用的策略是随机，比如设置10%的用户命中灰度。

我们可以通过生成随机数来判断是否命中灰度，具体步骤如下：

这样可以得到一个近似 10% 比例的灰度用户数。

基于门店和城市分流

如果想基于门店或城市分流，我们只需要配置两个参数， 一是如何获取门店和城市ID

另一个是需要灰度的门店和城市ID

import grayManager from '@cherry/grayManager'  

import { getShopId } from '../utils/index'  

  

grayManagerInit({  

    getGaryData: () => {  

        return await getCityId()  

    },  

    whiteData: ['123', '456']  

})

可以通过 grayScale 配置数组来实现，起始时间为打灰度包构建的时间，我们会把构建时间注入到 HTML 中。

其他注意项

开头讲过，这套方案有一点缺点。可能大家也会发现，灰度时用户需要先进入打 HTML，执行 head 中注入的重定向控制JS，对命中灰度的用户再次跳转到 gray.html。

这样其实带来了两个问题：一是对灰度用户来说经过了两个HTML，白屏的时间会更长。二是灰度用户访问的URL变化了，如果此时用户把页面分享出去，被分享用户将直接打开灰度页面。

对于第一条，全量用户是不会被影响，只有灰度用户才会白屏更久，我们目前测试白屏的时长还能接受。

对于第二条，我们最初是系统通过 Object.defineProperty 来拦截 对 window.location.pathname 的获取，返回 index.html。但window.location.pathname 是一个只读属性不可拦截。

最后只能提供统一的方法，来获取 pathname。

结语

以上就是我们的灰度核心方案，整个方案会比较简单，几乎不依赖外部部门。无论是对于H5还是pcWeb，亦或是不同的容器，都无依赖，各个业务线都可以平滑使用。

二、处理风场数据

grib这个数据格式打不开，看不懂，需要转换成json，有位大牛A写了个java的grib处理工具（grib2json)，然而我用maven打包失败了，然后发现有另一位大牛B封装了大牛A的jar包成node脚本，正好给前端开发者使用。

pnpm add -D @weacast/grib2json

2. 执行脚本，将grib转换成json

使用说明

Usage: grib2json (or node bin.js) [options] 

  -V, --version                   输出版本号

  -d, --data                       输出GRIB记录数据

  -c, --compact                    压缩json

  -fc, --filter.category    选择类目值

  -fs, --filter.surface     选择表面类型

  -fp, --filter.parameter   选择参数值

  -fv, --filter.value       选择表面值

  -n, --names                      打印数字代码的名称

  -o, --output               输出文件名

  -p, --precision       使用小数点后几位数的精度（默认值：-1）

  -v, --verbose                    启用stdout日志记录

  -bs, --bufferSize         stdout或stderr上允许的最大数据量（以字节为单位）

  -h, --help                       使用帮助

pnpm exec  grib2json -c --names --data --fp 2 --fs 103 --fv 10.0 -o output.json D:/code/wind/pgbf2024103000.01.2024103000.grb2

注意：

• --fs 103表面类型103（地面以上指定高度）
• --fv 10.0 距离GRIB2文件10.0米的表面值
• --fp 2 将参数2（U-component_of_wind）的记录输出到stdout
• 需要转换的grib文件放在最后，文件路径要用完整的路径名称

3. 数据格式说明

{

       "header":{

              //数据更新时间

           "refTime":"2024-10-30T00:00:00.000Z",

           

           "parameterCategory":2,//类目号，2表示风力

           "parameterCategoryName":"Momentum",

           "parameterNumber":2,//2表示u,3表示v

           "parameterNumberName":"U-component_of_wind",            

           "numberPoints":65160,//点数量            

           "nx":360,//横向栅格数量

           "ny":181, //纵向栅格数量

           "lo1":0.0,//开始经度

           "la1":-90.0,//开始纬度

           "lo2":359.0,//结束经度

           "la2":90.0,//结束纬度

           "dx":1.0,//横向步长

           "dy":1.0//纵向补偿

       },

       "data":[//方向数据，u数据，要搭配另一个v的数据使用

           -7.8,

           -7.9,

           ]

        }

U表示横向风速，V表示纵向风速，UV的正负值表示风向

4. output.json有2.25MB大，数据里面除了uv方向的数据，还包含了其他的数据，我们只需要有用的一个header和uv数据即可，可以用node处理一下,得到一个header信息数据info.json和风向数据wind.json

const fs = require('fs');

const output = require('./output.json');

let uData = [];

let vData = [];

let header = {};

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

 if (output[i].header.parameterNumber === 2) {//u的数据集

   uData = output[i].data;

   header = output[i].header;

 } else if (output[i].header.parameterNumber === 3) {//v的数据集

   vData = output[i].data;

 }

}



const len = uData.length;

const list = [];

const info = {

 minU: Number.MAX_SAFE_INTEGER,

 maxU: Number.MIN_SAFE_INTEGER,

 minV: Number.MAX_SAFE_INTEGER,

 maxV: Number.MIN_SAFE_INTEGER,

 ...header

};

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

//uv数据组合

 list.push([uData[i], vData[i]]);

 //计算最大最小边界值

 info.minU = Math.min(uData[i], info.minU);

 info.maxU = Math.max(uData[i], info.maxU);

 info.minV = Math.min(vData[i], info.minV);

 info.maxV = Math.max(vData[i], info.maxV);

}



fs.writeFileSync('./wind.json', JSON.stringify(list));

fs.writeFileSync('./info.json', JSON.stringify(info));

三、绘制2D风场图

重头戏来了！瞪大你的眼睛（0 v 0），看好了！

1. 创建风场网格

nx和ny对应横向纵向网格数量，然后uv数据按照nx行，ny列组装添加到二维数组里面就是网格了。

 this.grid = [];

    let index = 0;

for (let j = 0; j < header.ny; j++) {

        const row = [];

        for (let i = 0; i < header.nx; i++) {

          const item = this.data[index++];

          row.push(item);

        }

        this.grid.push(row);

      }

2. 获取点xy对应的风向uv

根据风场网格获取该xy先在应的风向uv,点xy可能不是整数，那么这时候需要使用双线性插值(根据临近的周围四个点计算出插值)算出对应的风向uv。

• 根据xy获取风向uv

 getUV(x, y) {

    let x0 = Math.floor(x),

      y0 = Math.floor(y);

    //正好落在网格里

    if (x0 === x && y0 === y) return this.getGrid(x, y);



    let x1 = x0 + 1;

    let y1 = y0 + 1;



    //临近四周的点

    let g00 = this.getGrid(x0, y0),

      g10 = this.getGrid(x1, y0),

      g01 = this.getGrid(x0, y1),

      g11 = this.getGrid(x1, y1);

    return this.bilinearInterpolation(x - x0, y - y0, g00, g10, g01, g11);

  }

• 不落在整数网格里面的采用双线性插值计算出风向uv

  /**双线性插值

   * g00, g10, g01, g11对应临近可映射的四个点

   * x为当前点与最近点x坐标差

   * y为当前点与最近点y坐标差

   * ***/

 bilinearInterpolation(x, y, g00, g10, g01, g11) {

    let rx = 1 - x;

    let ry = 1 - y;

    let a = rx * ry,

      b = x * ry,

      c = rx * y,

      d = x * y;

    let u = g00[0] * a + g10[0] * b + g01[0] * c + g11[0] * d;

    let v = g00[1] * a + g10[1] * b + g01[1] * c + g11[1] * d;

    return [u, v];

  }

 

• 获取网格数值，需规整超出的边界值

getGrid(x, y) {

    const h = this.header;

    if (x < 0) {

      x = 0;

    } else if (x > h.nx - 1) {

      x = h.nx - 1;

    }



    if (y < 0) {

      y = 0;

    } else if (y > h.ny - 1) {

      y = h.ny - 1;

    }



    return this.grid[y][x];

  }

3. 创建随机点

 createRandParticle() {

 //必须在风场网格范围内才能获取到风向uv

    const x = Math.random() * this.header.nx;

    const y = Math.random() * this.header.ny;



    const uv = this.getUV(x, y);



    return {

      //起点位置

      x,

      y,

      //终点位置=当前位置加上风向偏移

      tx: x + this.speed * uv[0],

      ty: y + this.speed * uv[1],

      //生命周期，将生命周期归零的时候重新设置起点坐标

      age: Math.floor(Math.random() * this.maxAge)

    };

  }

  //重新设置随机点

    setParticleRand(p) {

    const newp = this.createRandParticle();

    for (let k in p) {

      p[k] = newp[k];

    }

  }

• 生成随机点

 

    this.particles = [];

    for (let i = 0; i < this.particlesCount; i++) {

      this.particles.push(this.createRandParticle());

    }

4. 绘制风场图

canvas绘制风场即用线段的起点和终点跟随着风向不断运动形成风场图。

• 设置canvas

//缓存canvas context之前的合成操作类型

      const pre = ctx.globalCompositeOperation;

      //'destination-in'仅保留现有画布内容和新形状重叠的部分。其他的都是透明的。

      ctx.globalCompositeOperation = 'destination-in';

      //之前绘制的保留重叠部分

      ctx.globalAlpha = 0.5;

      ctx.fillRect(0, 0, this.canvas.width, this.canvas.height);

      //还原合成操作类型

      ctx.globalCompositeOperation = pre;

      

      

      //设置线的全局透明度

      ctx.globalAlpha = 0.8;

注意：cxt.fillRect本来清空之前的画布内容，但采用了globalCompositeOperation='destination-in'和globalAlpha=0.5的透明度作为重叠标准，重叠部分以0.5的透明度重新绘制并保留下来，通过这种方式，可以形成很多连续点的感觉，如果设置为1的透明度则会全部保留，并且不停叠加，等价于没有清空画布的状态。

• 遍历随机点更新位置

      this.particles.forEach((p) => {

        if (p.age <= 0) {

          //生命周期耗尽重新设置随机点值

          this.setParticleRand(p);

        } else {

          if (!this.inBound(p.x, p.y)) {

            //画出范围外重新设置随机点值

            this.setParticleRand(p);

          } else {

            //根据下一个点的风向，计算出下一个点的位置

            const uv = this.getUV(p.tx, p.ty);

            const nextx = p.tx + this.speed * uv[0];

            const nexty = p.ty + this.speed * uv[1];

            //将起点换成之前的终点

            p.x = p.tx;

            p.y = p.ty;

            //终点设置成计算出的下一个点

            p.tx = nextx;

            p.ty = nexty;

            //生命周期递减

            p.age--;

          }

        }

        //起始点和终点转换成显示的画布大小

        const start = this.getCanvasPos(p.x, p.y);

        const end = this.getCanvasPos(p.tx, p.ty);

        //渐变跟随线段的方向

        const gradient = ctx.createLinearGradient(start[0], start[1], end[0], end[1]);

        for (let k in this.color) {

          gradient.addColorStop(+k, this.color[k]);

        }

        //绘制线段

        ctx.beginPath();

        ctx.strokeStyle = gradient;

        ctx.moveTo(start[0], start[1]);

        ctx.lineTo(end[0], end[1]);

        ctx.stroke();

      });

5. 使用封装类绘制

async function main() {

    //风场信息数据

        const header = await getData('./info.json');

        //风场uv方向数据

        const data = await getData('./wind.json');



        const canvas = document.getElementById('canvas');

        canvas.width = 1200;

        canvas.height = 600;         

        const cw = new Windy({

          header,

          data,

          canvas,

          //运动速度

          speed: 0.1,

          //随机点数量

          particlesCount: 1000,

          //生命周期

          maxAge: 120,

          //1秒更新次数

          frame: 10,

          //线渐变

          color: {

            0: 'rgba(255,255,0,0)',

            1: '#ffff00'

          },

          //线宽度

          lineWidth: 3 

        });

      }

效果非常好，线段顺着风向在运动！

• 上面的线段因为一段段渐变呈现出一个个小蝌蚪的样子，然而利用叠加保留的效果，可以自动将线段绘制渐变色。只需要改变一下绘制顺序就行

  

        //线段绘制开始

        ctx.beginPath();

        //设置纯颜色

        ctx.strokeStyle = this.color;

        //遍历随机点更新位置

        this.particles.forEach((p) => {

           //同上面更新随机点的位置

           //...

           

          //起始点和终点转换成显示的画布大小

          const start = this.getCanvasPos(p.x, p.y);

          const end = this.getCanvasPos(p.tx, p.ty);

          //通过moveTo和lineTo绘制多个线段

          ctx.moveTo(start[0], start[1]);

          ctx.lineTo(end[0], end[1]);

        });

        //最终统一绘制线段

        ctx.stroke();

这样看上去流动线段连续性更强，不那么零散了！

6. 利用图片信息存储数据的优化

wind.json风场uv方向数据有739KB接近1MB，这着实有点大，要是网络稍微有点卡都会很影响首屏加载时间！从webgl-wind中我看到了用Canvas的ImageData中颜色来存储与解析数值,这操作太优秀了！

实现逻辑：用nx*ny与风场网格同样大小的canvas，获取到ImageData,将像素颜色四个数值中red红色和green绿色分别赋值成uv转换后的颜色值，注意透明度一定要置为不透明，然后put回canvas里面绘制,再利用canvas.toDataURL导出图片。

async function createCanvas() {

        const data = await getData('./wind.json');

        const info = await getData('info.json');

        const canvas = document.getElementById('theCanvas');

        canvas.width = info.nx;

        canvas.height = info.ny;



        const minU = Math.abs(info.minU);

        const minV = Math.abs(info.minV);

        // uv风方向范围

        const uSize = info.maxU - info.minU;

        const vSize = info.maxV - info.minV;

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

        //获取imageData像素数据

        const imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);

        data.forEach((item, i) => {

          //值转换成正数

          const u = item[0] + minU;

          const v = item[1] + minV;

          //转换成颜色值

          const r = (u / uSize) * 255;

          const g = (v / vSize) * 255;

          imageData.data[i * 4] = r;

          imageData.data[i * 4 + 1] = g;

          //透明度默认255即不透明

          imageData.data[i * 4 + 3] = 255;

        });

        //用imageData像素颜色值绘制图片

        ctx.putImageData(imageData, 0, 0);

      }

这样一张360px*181px的图片存储了65,160个点,但仅仅只需要86.6KB,压缩成原来数据的十分之一了。

• 如果改用风场方向图片，那么对应需要添加加载和解析数据的流程

加载风场方向数据图片

  loadImageData() {

    return new Promise((resolve) => {

      const image = new Image();

      image.src = this.imageUrl;

      image.onload = () => {

        const c = document.createElement('canvas');

        c.width = image.naturalWidth;

        c.height = image.naturalHeight;

        const ctx = c.getContext('2d');

        //绘制图片

        ctx.drawImage(image, 0, 0, image.naturalWidth, image.naturalHeight);

        //获取ImageData像素数据

        const imageData = ctx.getImageData(0, 0, image.naturalWidth, image.naturalHeight);

        

        resolve(imageData.data);

      };

    });

  }

解析图片数据成uv,并组装成风场网格Grid

data = await this.loadImageData();



      const minU = Math.abs(header.minU);

      const minV = Math.abs(header.minV);

      //uv风方向范围

      const uSize = header.maxU - header.minU;

      const vSize = header.maxV - header.minV;



      let index = 0;

      for (let j = 0; j < header.ny; j++) {

        const row = [];

        for (let i = 0; i < header.nx; i++) {

          //将颜色数据转化成风向uv数据

          const u = (data[index] / 255) * uSize - minU;

          const v = (data[index + 1] / 255) * vSize - minV;

          row.push([u, v]);

          index = index + 4;

        }

        this.grid.push(row);

      }

后面的绘制风场逻辑跟上面一样，只不过多了个加载图片解析的过程。

加上一张世界地图底图可以更清晰得看到风流动的方向！

四、绘制3D风场图

1.利用Canvas风场贴图绘制3D风场图

• 常规的顶点着色器

varying vec2 vUv;

void main() {

    vUv = uv;

    gl_Position = projectionMatrix * modelViewMatrix * vec4(position, 1.);



}

• 片元着色器，要将世界底图与风场图合并成一张图

varying vec2 vUv;

uniform sampler2D windTex;

uniform sampler2D worldTex;

void main() {

    vec4 color = texture2D(windTex, vUv);

    float a = color.a;

    if(a < 0.01) {

        a = 0.;

    }



    vec4 w = texture2D(worldTex, vUv);

        //根据透明度合并世界贴图和风场贴图

    vec4 c = w * (1. - a) + color * a;



    gl_FragColor = c;

}

• 创建风场贴图

async createWindCanvas() {

          const header = await getData('./info.json');          

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

          //要足够大，否则会贴图模糊

          canvas.width = 4000;

          canvas.height = 2000;

          this.cw = new Windy({

            header,

            // data,

            canvas,

            //运动速度

            speed: 0.1,

            //随机点数量

            particlesCount: 1000,

            //生命周期

            maxAge: 120,

            //1秒更新次数

            frame: 10,

            //线渐变

            // color: {

            //   0: 'rgba(255,255,0,0)',

            //   1: '#ffff00'

            // },

            color: '#ffff00',

            //线宽度

            lineWidth: 3,

            imageUrl: 'wind.png'

            //autoAnimate: true

          });

          const texture = new THREE.CanvasTexture(canvas);

          //因为是动态canvas,所以要置为需要更新

          texture.needsUpdate = true;

          return texture;

        }

• 添加球体

async createChart(that) {

          this.windTex = await this.createWindCanvas();



          const worldTex = new THREE.TextureLoader().load('../assets/world.jpg');

          {

            const material = new THREE.ShaderMaterial({

              uniforms: {

                worldTex: { value: worldTex },



                windTex: { value: this.windTex }

              },

              vertexShader: document.getElementById('vertexShader').innerHTML,

              fragmentShader: document.getElementById('fragmentShader').innerHTML,

              side: THREE.DoubleSide,

              transparent: true

            });



            const geometry = new THREE.SphereGeometry(2, 32, 16);



            const sphere = new THREE.Mesh(geometry, material);

            this.scene.add(sphere);

          }

        }

• 让canvas动起来

animateAction() {

          if (this.windTex) {

            if (this.cw) {

              this.cw.render();

            }

            this.windTex.needsUpdate = true;

          }

        }

地球展开收起动画

• 将顶点着色器替换成下面的，根据uv计算出压平后球体表面点的位置，然后用mix来让原来球体表面的点过渡变化

注意球体半圆周长，对应球体压平后矩形的宽度，球体贴图正好是2:1，长度对应宽度的两倍。

uniform float time;

uniform float radius;

varying vec2 vUv;

float PI = acos(-1.0);

void main() {

    vUv = uv;

             //半圆周长

    float w = radius * PI;

            //随着时间压平或收起球体点位置

    vec3 newPosition = mix(position, vec3(0.0, (uv.y - 0.5) * w, -(uv.x - 0.5) * 2.0 * w), sin(time * PI * 0.5));

    gl_Position = projectionMatrix * modelViewMatrix * vec4(newPosition, 1.0);

}

• 展开或收起球体动画

openMap() {

          const tw = new TWEEN.Tween({ time: 0.0 })

            .to({ time: 1.0 }, 2000)

            .onUpdate((obj) => {

              if (this.mat) {

                this.mat.uniforms.time.value = obj.time;

              }

            })

            .start();

          TWEEN.add(tw);

        }

        closeMap() {

          const tw = new TWEEN.Tween({ time: 1.0 })

            .to({ time: 0.0 }, 2000)

            .onUpdate((obj) => {

              if (this.mat) {

                this.mat.uniforms.time.value = obj.time;

              }

            })

            .start();

          TWEEN.add(tw);

        }

除了用贴图来实现，还能用three.js的BufferGeometry+LineSegments实现动态线段，进而实现3D风场图。

2.使用LineSegments绘制风场图

• 顶点着色器

uniform vec2 uResolution;//nx与ny网格大小

uniform vec2 uSize;//显示的宽高

varying vec2 vUv;

void main() {

    vUv = vec2(position.z);

            // 转换为经纬度坐标

    vec2 p = vec2(position.x, -position.y) - vec2(180., 90.);



    gl_Position = projectionMatrix * modelViewMatrix * vec4((p / uResolution) * uSize + vec2(0., uSize.y), 0.0, 1.);

}

注意：地球的经纬度是从下往上变大的，而平面的坐标是从上往下变大的的，因此随机点的y坐标取反才是正确位置，因为取反的问题，位置会偏移，对应也要将整体位置加上偏移量归位。

• 片元着色器

varying vec2 vUv;

uniform vec3 startColor;

uniform vec3 endColor;

void main() {

//渐变色

    gl_FragColor = vec4(mix(startColor, endColor, vUv.y), 1.0);

}

• 绘制线段LineSegments 将随机点的开始结束两个点位置分别赋值到线段position里面，并添加索引。

//点索引

 const points = new Float32Array(num * 6);          

 let i = 0;

 

pointCallback: (p) => {

              // 线段开始位置

              points[i] = p.x;

              points[i + 1] = p.y;

              points[i + 2] = 0;//开始点z坐标标识是0

                // 线段结束位置

              points[i + 3] = p.tx;

              points[i + 4] = p.ty;

              points[i + 5] = 1;//结束点z坐标标识是1

               

              //递增索引             

              i += 6;

            }

添加LineSegments，一定要用LineSegments，因为LineSegments是绘制的线段是gl.LINES模式,就是每两个点一组，形成一个新线段，就是A，B，C，D四个点，就会变成AB一条线段，BC一条线段，就可以绘制多条线段了。

 const material = new THREE.ShaderMaterial({

            uniforms: {

              //nx和ny网格大小

              uResolution: { value: new THREE.Vector2(this.cw.header.nx, this.cw.header.ny) },

              //显示宽高大小

              uSize: { value: new THREE.Vector2(20, 10) },               

              //渐变开始颜色

              startColor: { value: new THREE.Color('#ffff00') },

              //渐变结束颜色

              endColor: { value: new THREE.Color('#ff0000') }

            },

            vertexShader: document.getElementById('vertexShader1').innerHTML,

            fragmentShader: document.getElementById('fragmentShader').innerHTML,

            side: THREE.DoubleSide,

            transparent: true

          });

            

          const geometry = new THREE.BufferGeometry();          

          geometry.setAttribute('position', new THREE.BufferAttribute(points, 3));         

          this.geometry = geometry;

          this.mat = material;

          //添加多个线段

          const lines = new THREE.LineSegments(geometry, material);

          this.scene.add(lines);

渲染的时候移动点的位置并给position属性赋值更新

if (this.frameCount % this.frame === 0 && this.cw && this.geometry) {

            let i = 0;

            const g = this.geometry;

            this.cw.movePoints((p) => {

              g.attributes.position.array[i] = p.x;

              g.attributes.position.array[i + 1] = p.y;

              g.attributes.position.array[i + 3] = p.tx;

              g.attributes.position.array[i + 4] = p.ty;

              i += 6;

            });

            //属性值改变一定要置true,通知更新

            g.attributes.position.needsUpdate = true;

          }

上面效果的风场图与canvas 2D风场图清空再绘制一样的效果，没有走destination-in叠加保留的过程，点的数量可能看起来偏少，因此为了保证风流向的连续性，最好增加随机点个数。

• 将平面的LineSegments变成球体 修改一下定点着色器，经纬度坐标转换成三维坐标

float PI = 3.1415926;

float rad = 3.1415926 / 180.;

uniform vec2 uResolution;

uniform vec2 uSize;

//半径

uniform float radius;

 //旋转翻过来

 uniform mat4 rotateX;



varying vec2 vUv;

      //经纬度坐标转为三维坐标

vec3 lnglat2pos(vec2 p) {

    float lng = p.x * rad;

    float lat = p.y * rad;

    float x = cos(lat) * cos(lng);

    float y = cos(lat) * sin(lng);

    float z = sin(lat);

    return vec3(x, z, y);

}

void main() {

    vUv = vec2(position.z);

            //转换成经纬度

    vec2 p = vec2(position.x, -position.y) - vec2(180., 90.);

           //经纬度转三维坐标

    vec3 newPosition = radius * lnglat2pos(p);

    gl_Position = projectionMatrix * modelViewMatrix *rotateX* vec4(newPosition, 1.);



}

注意

const worldTex = new THREE.TextureLoader().load('../assets/world.jpg');

          worldTex.offset.x = 0.5;

          worldTex.wrapS = THREE.RepeatWrapping;

4.因为y取反了，但在球体不能用位置偏移量解决归位问题，就会导致整个风流向路径反过来了，所以需要添加一个矩阵翻转量，让风流向路径回归正确的样子，

  const matrix = new THREE.Matrix4();

          matrix.makeRotationX(Math.PI);

终于解决风场位置对齐的问题了！这点小细节调了好久！唉~

五、Github地址

https://github.com/xiaolidan00/my-earth

参考

在前端js编程中，如果涉及到加密通信、加密算法，经常会用到密钥。

但密钥，很容易暴露。 暴露原因：js代码透明，在浏览器中可以查看源码，从中找到密钥。

例如，下面的代码中，变量key是密钥：

如何保护源码中的密钥呢？

很多时候，人们认为需要对密钥字符串进行加密。其实更重要的是对存储密钥的变量进行加密。

加密了密钥变量，使变量难以找到，才更能保护密钥本身。

顺着这个思路，下面给出一个不错的密钥的保护方法：

还是以上面的代码为例，

首先，用到jsfuck：

https://www.jshaman.com/tools/jsfuck.html

将代码中的密钥定义整体，用jsfuck加密：

var key = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ";

加密后得到一串奇怪的字符，这是将变量“key ”以及密钥字符“0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ”隐藏了起来。

注意：加密时需要选中“在父作用域中运行”，选中之后，key 变量的定义虽然不存在，但变量key是可用的！（这点很神奇）。也就是虽然代码中没有定义这个变量，但这个变量存在，且可用。而且它存储的就是密钥！

用加密后的代码替换掉原来的代码，变成如下形式：

运行效果：

即时他人拿走代码去调试，也会显示变量key未定义，如下图所示：

但，这时候还不足够安全，还能更安全。

将整体JS代码，再用JS加密工具：JShaman，进行混淆加密：

https://www.jshaman.com

然后得到更安全、更难调试分析的JS代码，这时密钥就变的更安全了：

注：用ajax等异步传递密钥时，也可以使用这个办法，也能很好的隐藏密钥。

用jsfuck+jshaman保护JS中的密钥，你学会了吗？

最近逛github的时候发现了一个非常好用的轻量工具库，Fuse.js，支持模糊搜索。感觉还是非常好用的，所以有了此篇博客，这篇文章主要是介绍Fuse的使用，同样，我对这个开源项目的实现也非常感兴趣。后续会出一篇Fuse源码解析的文章来分析其实现原理。

Fuse.js是什么？

强大、轻量级的模糊搜索库，没有任何依赖关系。

什么是模糊搜索？

一般来说，模糊搜索（更正式的名称是近似字符串匹配）是查找与给定模式近似相等（而不是完全相等）的字符串的技术。

通常我们项目中的的模糊搜索大多数情况下有几种方案可用：

• 前端工程通过正则表达式或者字符串匹配来实现


• 调用后端接口去匹配搜索


• 使用搜索引擎如：ElasticSearch或Algolia等

但是这些方案都有各自的缺陷，比如正则表达式和字符串匹配的效率较低，且无法处理复杂的搜索需求，而调用后端接口和搜索引擎虽然效率高，但是需要额外的服务器资源，且需要维护一套搜索引擎。

所以，Fuse.js的出现就是为了解决这些问题，它是一个轻量级的模糊搜索库，没有依赖关系，支持复杂的搜索需求，且效率高，当然Fuse并不适用于所有场景。

Fuse.js的使用场景

它可能不适用于所有情况，但根据您的搜索要求，它可能是最理想的。例如：

• 当您想要对小型到中等大型数据集进行客户端模糊搜索时


• 当您无法证明设置专用后端只是为了处理搜索时


• ElasticSearch 或 Algolia 虽然都是很棒的服务，但对于您的特定用例来说可能有些过度

Fuse.js的使用

安装

Fuse支持多种安装方式

NPM

npm install fuse.js

Yarn

yarn add fuse.js

CDN 引入

<script src="https://cdn.jsdelivr.net/npm/fuse.js@7.0.0"></script>

引入

ES6 模块语法

import Fuse from 'fuse.js'

CommonJS 语法

const Fuse = require('fuse.js')

Tips: 使用npm或者yarn引入，支持两种模块语法引入，如果是使用cdn引入，那么Fuse将被注册为全局变量。直接使用即可

使用

以下是官网一个最简单的例子，只要简单的构造new Fuse对象，就能模糊搜索匹配到你想要的结果

// 1. List of items to search in

const books = [

  {

    title: "Old Man's War",

    author: {

      firstName: 'John',

      lastName: 'Scalzi'

    }

  },

  {

    title: 'The Lock Artist',

    author: {

      firstName: 'Steve',

      lastName: 'Hamilton'

    }

  }

]



// 2. Set up the Fuse instance

const fuse = new Fuse(books, {

  keys: ['title', 'author.firstName']

})



// 3. Now search!

fuse.search('jon')



// Output:

// [

//   {

//     item: {

//       title: "Old Man's War",

//       author: {

//         firstName: 'John',

//         lastName: 'Scalzi'

//       }

//     },

//     refIndex: 0

//   }

// ]

从上述代码中可以看到我们要通过Fuse 对books的这个数组进行模糊搜索，构建的Fuse对象中，模糊搜索的key定义为['title', 'author.firstName']，支持对title及author.firstName这两个字段进行搜索。然后执行fuse的search API就能过滤出我们的期望结果。整体代码还是非常简单的。

高级配置

Demo示例只是提供了一个基础版本的模糊搜索。如果用户想获得更灵活的搜索能力，比如搜索结果排序、权重控制、搜索结果高亮等，那么就需要对Fuse进行一些高级配置。

Fuse的所有配置都是通过new Fuse时传入的参数来配置的，下面列举一些常用的配置项：

    const options = {

            keys: ['title', 'author'], // 指定搜索key值，可多选

            isCaseSensitive: false, //是否区分大小写 默认为false

            includeScore: false, //结果集中是否展示匹配项的分数字段， 分数越大代表匹配程度越低，区间值为0-1,注意：当此项为true时，会返回完整的结果集，只不过每一项中携带了score分数字段

            includeMatches: false, //匹配项是否应包含在结果中。当时true，结果的每条记录都包含匹配项的索引。这个通常我们用来对搜索内容做高亮处理

            threshold: 0.6, // 阈值控制匹配的敏感度,默认值为0.6，如果要完全匹配这里要设置为0

            shouldSort: true, // 是否对结果进行排序

            location: 0, // 匹配的位置，0 表示开头匹配

            distance: 100, // 搜索的最大距离

            minMatchCharLength: 2, // 最小匹配字符长度

    };

出了上述常用的一些配置项之外，Fuse还支持更高阶模糊搜索，如权重搜索，嵌套搜索，运算符拓展搜索，具体高阶用法可以参考官方文档。
Fuse的主要实现原理是通过改写Bitap 算法(近似字符串匹配)算法的内部实现来支撑其模糊搜索的算法依据，后续会出一篇文章看一下作者源码的算法实现。

总结

Fuse的文章到此就结束了，你没看错就这么一点介绍就基本能支撑我们在项目中的应用，谢谢阅读，如果哪里有不对的地方请评论博主，会及时进行改正。

欢迎访问我的博客地址