功能截图

特别说明：由于本项目是用于教学案例，并没有上线的二维码供大家体验。

开发版本

• 微信开发者工具版本：1.06

• 调试基础库：2.30

代码仓库

• gitee：gitee.com/guigu-fe/gu…

• github：github.com/xiumubai/gu…

建议全文参考源代码观看效果更佳，代码可直接在微信开发者工具当中打开预览，appid需要替换成自己的。

获取用户信息变化

用户头像昵称获取规则已调整，现在微信小程序已经获取不到用户昵称和头像了，只能已通过用户回填（提供给用户一个修改昵称和头像的表单页面）的方式来实现。不过还是可以获取到code跟后端换取token的方式来进行登录。

具体参考 *用户信息接口调整说明*、小程序用户头像昵称获取规则调整公告

vant weapp组件库的使用

1.需要使用npm构建的能力，用 npm 构建前，请先阅读微信官方的 npm 支持。初始化package.json

npm init

2.安装@vant/weapp

# 通过 npm 安装
npm i @vant/weapp -S --production

# 通过 yarn 安装
yarn add @vant/weapp --production

# 安装 0.x 版本
npm i vant-weapp -S --production

2.修改 app.json 将 app.json 中的 "style": "v2" 去除，小程序的新版基础组件强行加上了许多样式，难以覆盖，不关闭将造成部分组件样式混乱。 3.修改 project.config.json 开发者工具创建的项目，miniprogramRoot 默认为 miniprogram，package.json 在其外部，npm 构建无法正常工作。 需要手动在 project.config.json 内添加如下配置，使开发者工具可以正确索引到 npm 依赖的位置。

{
  ...
  "setting": {
    ...
    "packNpmManually": true,
    "packNpmRelationList": [
      {
        "packageJsonPath": "./package.json",
        "miniprogramNpmDistDir": "./miniprogram/"
      }
    ]
  }
}

注意： 由于目前新版开发者工具创建的小程序目录文件结构问题，npm构建的文件目录为miniprogram_npm，并且开发工具会默认在当前目录下创建miniprogram_npm的文件名，所以新版本的miniprogramNpmDistDir配置为'./'即可。 4.构建 npm 包 打开微信开发者工具，点击 工具 -> 构建 npm，并勾选 使用 npm 模块 选项，构建完成后，即可引入组件。

使用组件

引入组件

// 通过 npm 安装
// app.json
"usingComponents": {
  "van-button": "@vant/weapp/button/index"
}

使用组件

<van-button type="primary">按钮</van-button>

如果预览没有效果，从新构建一次npm，然后重新打开此项目。

自定义tabbar

这里我的购物车使用了徽标，所以需要自定义一个tabbar，这里自定义以后，会引发后面的一系列连锁反应（比如内容区域高度塌陷，导致tabbar遮挡内容区域），后面会讲如何计算。效果如下图：

1. 配置信息

• 在 app.json 中的 tabBar 项指定 custom 字段，同时其余 tabBar 相关配置也补充完整。

• 所有 tab 页的 json 里需声明 usingComponents 项，也可以在 app.json 全局开启。

示例：

{
  "tabBar": {
    "custom": true,
    "color": "#000000",
    "selectedColor": "#000000",
    "backgroundColor": "#000000",
    "list": [{
      "pagePath": "page/component/index",
      "text": "组件"
    }, {
      "pagePath": "page/API/index",
      "text": "接口"
    }]
  },
  "usingComponents": {}
}

2. 添加 tabBar 代码文件

需要跟pages目录同级，创建一个custom-tab-bar目录。 .wxml代码如下：

<!--miniprogram/custom-tab-bar/index.wxml-->
<cover-view class="tab-bar">
  <cover-view class="tab-bar-border"></cover-view>
  <cover-view wx:for="{{list}}" 
    wx:key="index" 
    class="tab-bar-item" 
    data-path="{{item.pagePath}}" 
    data-index="{{index}}" 
    bindtap="switchTab">
    <cover-view class="tab-img-wrap">
      <cover-image src="{{selected === index ? item.selectedIconPath : item.iconPath}}"></cover-image>
      <cover-view wx-if="{{item.info && cartCount > 0}}"class="tab-badge">{{cartCount}}</cover-view>
    </cover-view>
    <cover-view style="color: {{selected === index ? selectedColor : color}}">{{item.text}}</cover-view>
  </cover-view>
</cover-view>

注意这里的徽标控制我是通过info字段来控制的，然后数量cartCount单独第一个了一个字段，这个字段是通过store来管理的，后面会讲为什么通过stroe来控制的。

3. 编写 tabBar 代码

用自定义组件的方式编写即可，该自定义组件完全接管 tabBar 的渲染。另外，自定义组件新增 getTabBar 接口，可获取当前页面下的自定义 tabBar 组件实例。

import { storeBindingsBehavior } from 'mobx-miniprogram-bindings';
import { store } from '../store/index';

Component({
  behaviors: [storeBindingsBehavior],
  storeBindings: {
    store,
    fields: {
      count: 'count',
    },
    actions: [],
  },
  observers: {
    count: function (val) {
      // 更新购物车的数量
      this.setData({ cartCount: val });
    },
  },
  data: {
    selected: 0,
    color: '#252933',
    selectedColor: '#FF734C',
    cartCount: 0,
    list: [
      {
        pagePath: '/pages/index/index',
        text: '首页',
        iconPath: '/static/tabbar/home-icon1.png',
        selectedIconPath: '/static/tabbar/home-icon1-1.png',
      },
      {
        pagePath: '/pages/category/category',
        text: '分类',
        iconPath: '/static/tabbar/home-icon2.png',
        selectedIconPath: '/static/tabbar/home-icon2-2.png',
      },
      {
        pagePath: '/pages/cart/cart',
        text: '购物车',
        iconPath: '/static/tabbar/home-icon3.png',
        selectedIconPath: '/static/tabbar/home-icon3-3.png',
        info: true,
      },
      {
        pagePath: '/pages/info/info',
        text: '我的',
        iconPath: '/static/tabbar/home-icon4.png',
        selectedIconPath: '/static/tabbar/home-icon4-4.png',
      },
    ],
  },

  lifetimes: {},
  methods: {
      // 改变tab的时候，记录index值
    switchTab(e) {
      const { path, index } = e.currentTarget.dataset;
      wx.switchTab({ url: path });
      this.setData({
        selected: index,
      });
    },
  },
});

这里的store大家不用理会，只需要记住是设置徽标的值就可以了。

4.设置样式

.tab-bar {

  position: fixed;

  bottom: 0;

  left: 0;

  right: 0;

  height: 48px;

  background: white;

  display: flex;

  padding-bottom: env(safe-area-inset-bottom);

}

这里的样式单独贴出来说明一下：

padding-bottom: env(safe-area-inset-bottom);

可以让出底部安全区域，不然的话tabbar会直接沉到底部 别忘了在index.json中设置component=true

{

  "component": true

}

5.tabbar页面设置index

上面的代码添加完毕以后，我们的tabbar就出来了，但是有个问题，就是在点击tab的时候，样式不会改变，必须再点击一次，这是因为当你切换页面或者刷新页面的时候，index的值会重置，为了解决这个问题，我们需要在每个tabbar的页面添加下面的代码：

/**

 * 生命周期函数--监听页面显示

 */

onShow() {

  if (typeof this.getTabBar === 'function' && this.getTabBar()) {

    this.getTabBar().setData({

      selected: 0,

    });

  }

},

当页面每次show的时候，设置一下selected的值，也就是选中的index就可以了。其他的tabbar页面同样也是如此设置即可。

添加store状态管理

接下来我们来讲讲微信小程序如何用store来管理我们的数据。 上面我们说了我们需要实现一个tabbar的徽标，起初我想的是直接用个缓存来解决就完事了，后来发现我太天真了，忘记了这个字段是一个响应式的，它是需要渲染到页面上的，它变了，页面中的数据也得跟着一起变。后来我想通过globalData来实现，也不行。后来我又又想到了把这个数据响应式监听一下不就行了？于是通过proxy，跟vue3的处理方式一样，监听一下这个字段的改变就可以了。在购物车这个页面触发的时候是挺好，可当我切换到其他tabbar页面的时候它就不见了。我忽略了一个问题，它是全局响应的啊。于是最后才想到了使用store的方式来实现。 我找到了一个针对微信小程序的解决方法，就是使用mobx-miniprogram-bindings和mobx-miniprogram这两个库来解决。真是帮了我的大忙了。 下面我们直接来使用。 先安装两个插件：

npm install --save mobx-miniprogram mobx-miniprogram-bindings

方式跟安装vant weapp一样，npm安装完成以后，在微信开发者工具当中构建npm即可。 下面我们来通过如何实现一个tabbar徽标的场景来学习如何在微信小程序中使用store来管理全局数据。

tabbar徽标实现

1.定义store

import { observable, action, runInAction } from 'mobx-miniprogram';

import { getCartList } from './cart';

// 获取购物车数量



export const store = observable({

  /** 数据字段 */

  count: 0,



  /** 异步方法 */

  getCartListCount: async function () {

    const num = await getCartList();

    runInAction(() => {

      this.count = num;

    });

  },



  /** 更新购物车的数量 */

  updateCount: action(function (num) {

    this.count = num;

  }),

});

看起来是不是非常简单。这里我们定义了一个count，然后定义了两个方法，这两个方法有点区别：

• updateCount用来更新count

• getCartListCount用来异步更新count，因为这里我们在进入小程序的时候就需要获取count的初始值，这个值的计算又的依赖接口，所以需要使用异步的方式。

好了，现在我们字段有了，设置初始值的方法有了，更新字段的方法也有了。下面我们来看一下如何使用。

2.使用store

回到我们的tabbr组件，在custom-tab-bari/ndex.js中，我们贴一下主要的代码：

import { storeBindingsBehavior } from 'mobx-miniprogram-bindings';

import { store } from '../store/index';



Component({

  behaviors: [storeBindingsBehavior],

  storeBindings: {

    store,

    fields: {

      count: 'count',

    },

    actions: [],

  },

  observers: {

    count: function (val) {

      // 更新购物车的数量

      this.setData({ cartCount: val });

    },

  },

  data: {

    cartCount: 0,

  },

});

解释一下，这里我们只是获取了count的值，然后通过observers的方式监听了一下count，然后赋值给了cartCount,这里你直接使用count渲染到页面上也是没有问题的。我这里只是为了演示一下observers的使用方式才这么写的。这样设置以后，tabbar上面的徽标数字已经可以正常展示了。 现在当我们的购物车数字改变以后，就要更新count的值了。

3.使用action

找到我们的cart页面，下面是具体的逻辑：

import {

  findCartList,

  deleteCart,

  checkCart,

  addToCart,

  checkAllCart,

} from '../../utils/api';



import { createStoreBindings } from 'mobx-miniprogram-bindings';

import { store } from '../../store/index';

import { getCartTotalCount } from '../../store/cart';

const app = getApp();

Page({

  data: {

    list: [],

    totalCount: 0,

  },



  /**

   * 生命周期函数--监听页面加载

   */

  onLoad(options) {

    this.storeBindings = createStoreBindings(this, {

      store,

      fields: ['count'],

      actions: ['updateCount'],

    });

  },



  /**

   * 声明周期函数--监听页面卸载

   */

  onUnload() {

    this.storeBindings.destroyStoreBindings();

  },



  /**

   * 生命周期函数--监听页面显示

   */

  onShow() {

    if (typeof this.getTabBar === 'function' && this.getTabBar()) {

      this.getTabBar().setData({

        selected: 2,

      });

    }

    this.getCartList();

  },



  /**

   * 获取购物车列表

   */

  async getCartList() {

    const res = await findCartList();

    this.setData({

      list: res.data,

    });

    this.computedTotalCount(res.data);

  },



  /**

   * 修改购物车数量

   */

  async onChangeCount(event) {

    const newCount = event.detail;

    const goodsId = event.target.dataset.goodsid;

    const originCount = event.target.dataset.count;

    // 这里如果直接拿+以后的数量，接口的处理方式是直接在上次的基础累加的，

    // 所以传给接口的购物车数量的计算方式如下：

    // 购物车添加的数量=本次的数量-上次的数量

    const count = newCount - originCount;

    const res = await addToCart({

      goodsId,

      count,

    });

    if (res.code === 200) {

      this.getCartList();

    }

  },



  /**

   * 计算购物车总数量

   */

  computedTotalCount(list) {

    // 获取购物车选中数量

    const total = getCartTotalCount(list);

    // 设置购物车徽标数量

    this.updateCount(total);

  },



  

});

上面的代码有所删减。在page和component中使用action方法有所区别，需要在onUnload的时候销毁一下我们的storeBindings。当修改购物车数量的时候，我这里会重新请求一次接口，然后计算一下totalCount的数量，通过updateCount来修改count的值。到了这里，我们的徽标就可以正常的使用了。不管是切换到哪一个tabbar页面，徽标都会保持状态。

4.使用异步action

现在还剩最后一个问题，就是如何设置count的初始值，这个值还得从接口获取过来。下面是实现思路。 首先我们在store中定义了一个一步方法：

import { observable, action, runInAction } from 'mobx-miniprogram';

import { getCartList } from './cart';

// 获取购物车数量



export const store = observable({

  /** 数据字段 */

  count: 0,



  /** 异步方法 */

  getCartListCount: async function () {

    const num = await getCartList();

    runInAction(() => {

      this.count = num;

    });

  },



  /** 更新购物车的数量 */

  updateCount: action(function (num) {

    this.count = num;

  }),

});

可以看到，异步action的实现跟同步的区别很大，使用了runInAction这个方法，在它的回调函数中去修改count的值。很坑的是，这个方法在[mobx-miniprogram-bindings](https://www.npmjs.com/package/mobx-miniprogram-bindings)中的官方文档中没有做任何说明，我百度了好久才找到。 现在，我们有了这个方法，在哪里触发好合适呢？答案是app.js中的onShow生命周期函数中。也就是每次我们进入小程序，就会设置一下count的初始值了。下面是代码：

// app.js

import { createStoreBindings } from 'mobx-miniprogram-bindings';

import { store } from './store/index';

App({

  onShow() {

    this.storeBindings = createStoreBindings(this, {

      store,

      fields: [],

      actions: ['getCartListCount'],

    });

    // 在页面初始化的时候，更新购物车徽标的数量

    this.getCartListCount();

  },

});

到此为止，整个完整的徽标响应式改变和store的使用完美的融合了。 参考文章：blog.csdn.net/ice_stone_k…

如何获取tabbar的高度

当我们自定义tabbar以后，由于tabbar是使用的fixed定位，我们的内容区域如果不做任何限制，底部的内容就会被tabbar遮挡，所以我们需要给内容区域整体设置一个padding-bottom,那这个值是多少呢？有的人可能会说，直接把tabbar的高度固定，然后padding-bottom设置成这个高度的值不就可以了吗？你别忘了，现在五花八门的手机下面还有一个叫做安全区域的东西，如下图：

如果你没有把这个高度加上，那内容区域还是会被tabbar遮挡。下面我们就来看看这个高度具体如何计算呢？ 我们以通过wx.getSystemInfoSync()获取机型的各种信息。

其中screenHeight是屏幕高度，safeArea的bottom属性会自动计算安全区域也就是去除tabBar下面的空白区域后有用区域的纵坐标。如此我们就可以就算出来tabber的高度：

const res = wx.getSystemInfoSync()

const { screenHeight, safeArea: { bottom } } = res



if (screenHeight && bottom){

  let safeBottom = screenHeight - bottom

  const tabbarHeight = 48 + safeBottom

}

这里48是tabbar的高度，我们固定是48px。拿到tabbarHeight以后，把它设置成一个globalData，我们就可以给其他页面设置padding-bottom了。 我这里还使用了其他的一些属性，具体参考代码如下：

// app.js



App({

  onLaunch() {

    // 获取高度

    this.getHeight();

  },

  onShow() {

  },

  globalData: {

    // tabber+安全区域高度

    tabbarHeight: 0,

    // 安全区域的高度

    safeAreaHeight: 0,

    // 内容区域高度

    contentHeight: 0,

  },

  getHeight() {

    const res = wx.getSystemInfoSync();

    // 胶囊按钮位置信息

    const menuButtonInfo = wx.getMenuButtonBoundingClientRect();

    const {

      screenHeight,

      statusBarHeight,

      safeArea: { bottom },

    } = res;

    // console.log('resHeight', res);



    if (screenHeight && bottom) {

      // 安全区域高度

      const safeBottom = screenHeight - bottom;

      // 导航栏高度 = 状态栏到胶囊的间距（胶囊距上距离-状态栏高度） * 2 + 胶囊高度 + 状态栏高度

      const navBarHeight =

        (menuButtonInfo.top - statusBarHeight) * 2 +

        menuButtonInfo.height +

        statusBarHeight;

      // tabbar高度+安全区域高度

      this.globalData.tabbarHeight = 48 + safeBottom;

      this.globalData.safeAreaHeight = safeBottom;

      // 内容区域高度，用来设置内容区域最小高度

      this.globalData.contentHeight = screenHeight - navBarHeight;

    }

  },

});

假如我们需要给首页设置一个首页设置一个padding-bottom：

// components/layout/index.js

const app = getApp();

Component({

  /**

   * 组件的属性列表

   */

  properties: {

    bottom: {

      type: Number,

      value: 48,

    },

  },



  /**

   * 组件的方法列表

   */

  methods: {},

});

<view style="padding-bottom: {{bottom}}px">

  <slot></slot>

</view>

这里我简单粗暴的直接在外层套了一个组件，统一设置了padding-bottom。 除了自定义tabbar，还可以自定义navbar，这里我没这个功能，所以不展开讲了，这里放一个参考文章： 获取状态栏的高度。这个文章把如何自定义navbar，如何获取navbar的高度，讲的很通透，感兴趣的仔细拜读。

分页版上拉加载更多

为什么我称作是分页版本的上拉加载更多呢，因为就是上拉然后多加载一页，没有做那种虚拟加载，感兴趣的可以参考这篇文章（我觉得写的非常到位了）。下面我以商品列表为例，代码在pages/goods/list下，讲讲简单版本的实现：

<!--pages/goods/list/index.wxml-->



<view style="min-height: {{contentHeight}}px; padding-bottom: {{safeAreaHeight}}px">



  <view wx:if="{{list.length > 0}}">

    <goods-card wx:for="{{list}}" wx:key="index" item="{{item}}"></goods-card>

    <!-- 上拉加载更多 -->

    <load-more 

      list-is-empty="{{!list.length}}" 

      status="{{loadStatus}}" 

    />

  </view>



  <van-empty wx:else description="该分类下暂无商品，去看看其他的商品吧～">

    <van-button 

      round 

      type="danger" 

      

      bindtap="gotoBack">

      查看其他商品

    </van-button>

  </van-empty>



</view>

// pages/goods/list/index.js

import { findGoodsList } from '../../../utils/api';

const app = getApp();

Page({

  /**

   * 页面的初始数据

   */

  data: {

    page: 1,

    limit: 10,

    list: [],

    options: {},

    loadStatus: 0,

    contentHeight: app.globalData.contentHeight,

    safeAreaHeight: app.globalData.safeAreaHeight,

  },



  /**

   * 生命周期函数--监听页面加载

   */

  onLoad(options) {

    this.setData({ options });

    this.loadGoodsList(true);

  },



  /**

   * 页面上拉触底事件的处理函数

   */

  onReachBottom() {

    // 还有数据，继续请求接口

    if (this.data.loadStatus === 0) {

      this.loadGoodsList();

    }

  },



  /**

   * 商品列表

   */

  async loadGoodsList(fresh = false) {

    // wx.stopPullDownRefresh();

    this.setData({ loadStatus: 1 });

    let page = fresh ? 1 : this.data.page + 1;

    // 组装查询参数

    const params = {

      page,

      limit: this.data.limit,

      ...this.data.options,

    };

    try {

      // loadstatus说明： 0-加载完毕，隐藏加载状态 1-正在加载 2-全部加载 3-加载失败

      const res = await findGoodsList(params);

      const data = res.data.records;

      if (data.length > 0) {

        this.setData({

          list: fresh ? data : this.data.list.concat(data),

          loadStatus: data.length === this.data.limit ? 0 : 2,

          page,

        });

      } else {

        // 数据全部加载完毕

        this.setData({

          loadStatus: 2,

        });

      }

    } catch {

      // 错误请求

      this.setData({

        loadStatus: 3,

      });

    }

  },

});

代码已经很详细了，我再展开说明一下。

• onLoad的时候第一次请求商品列表数据loadGoodsList，这里我加了一个fresh字段，用来区分是不是第一次加载，从而且控制page是不是等于1

• 触发onReachBottom的时候，先判断loadStatus === 0，表示接口数据还没加载完，继续请求loadGoodsList

• 在loadGoodsList里面，先设置loadStatus = 1，表示状态为加载中。如果fresh为false，则表示要请求下一页的数据了，page+1。

• 接口请求成功，给了list添加数据的时候要注意了，这里需要再上次list的基础上拼接数据，所以得用concat。同时修改loadStatus状态，如果当前请求回来的数据条数小与limit（每页数据大小），则表示没有更对的数据了，loadStatus = 2，反之为0。

• 最后为了防止特殊情况出现，还有个loadStatus = 3，表示加载失败的情况。

这里我封装了一个load-more组件，里面就是对loadStatus各种不同状态的处理。具体详情看看源码。 思考：如果加上个下拉刷新，跟上拉加载放在一起，如何实现呢？

如何分包

为什么要做小程序分包？先来看看小程序对文件包的大小限制 在不使用分包的时候，代码总包的大小限制为2M，如果使用了分包，总包大小可以达到20M，也就是我们能分10个包。 那么如何分包？非常的简单。代码如下：

{

	"pages": [

    "pages/index/index",

    "pages/category/category",

    "pages/cart/cart",

    "pages/info/info",

    "pages/login/index"

  ],

  "subpackages": [

    {

      "root": "pages/goods",

      "pages": [

        "list/index",

        "detail/index"

      ]

    },

    {

      "root": "pages/address",

      "pages": [

        "list/index",

        "add/index"

      ]

    },

    {

      "root": "pages/order",

      "pages": [

        "pay/index",

        "list/index",

        "result/index",

        "detail/index"

      ]

    }

  ],

}

目录结构如下： 解释一下： 我们subpackages下面的就是分包的内容，里面的每一个root就是一个包，pages里面的内容只能是这样的字符串路径，添加别的内容会报错。分包的逻辑：业务相关的页面放在一个包下，也就是一个目录下即可。 ⚠️注意：tabbar的页面不能放在分包里面。 下面是分包以后的代码依赖分析截图：

后续更新计划

• 小程序如何自定义navbar

• 小程序如何添加typescript

• 在小程序中如何做表单校验的小技巧

• 微信支付流程

• 如何在小程序中mock数据

• 如何优化小程序

本文章可以随意转载。转给更多需要帮助的人。看了源码觉得有帮助的可以点个star。我会持续更新更多系列教程。

作者：白哥学前端
来源：https://juejin.cn/post/7202495679397511227

引言

现在的前端真可谓是百花齐放，百家争鸣，各种框架层出不穷，但是主要目前用的最多的还是要数Vue、React、以及Angular,这三种，当然不乏近期新出的一些其他框架，但是她们都有一个显著的特点，那就是使用了MVVM的架构。

首先我们要搞清楚什么是MVVM？

MVVM就是Model-View-ViewModel的缩写，MVVM最早由微软提出来，它借鉴了桌面应用程序的MVC思想，在前端页面中，把Model用纯JavaScript对象表示，View负责显示，两者做到了最大限度的分离。把Model和View关联起来的就是ViewModel。ViewModel负责把Model的数据同步到View显示出来，还负责把View的修改同步回Model。

改变JavaScript对象的状态，会导致DOM结构作出对应的变化！这让我们的关注点从如何操作DOM变成了如何更新JavaScript对象的状态，而操作JavaScript对象比DOM简单多了。

这就是MVVM的设计思想：关注Model的变化，让MVVM框架去自动更新DOM的状态，从而把开发者从操作DOM的繁琐步骤中解脱出来！

接下来我会带着你们如何去实现一个简易的MVVM架构。

一、构建MVVM构造函数

创建一个MVVM构造函数，用于接收参数，如：data、methods、computed等:

function MVVM(options) { 
    this.$options = options; 
    let data = this._data = this.$options.data; 
    observe(data); 
    for (let key in data) { 
        Object.defineProperty(this, key, { 
            enumerable: true, 
            get() { 
                return this._data[key]; 
            }, 
            set(newVal) { 
                this._data[key] = newVal; 
            } 
        }); 
    }; 
    initComputed.call(this); 
    new Compile(options.el, this); 
    options.mounted.call(this); 
}

二、构建Observe构造函数

创建一个Observe构造函数，用于监听数据变化:

function Observe(data) { 
    let dep = new Dep(); 
    for (let key in data) { 
        let val = data[key]; 
        observe(val); 
        Object.defineProperty(data, key, { 
            enumerable: true, 
            get() { 
                Dep.target && dep.addSub(Dep.target); 
                return val; 
            }, 
            set(newVal) { 
                if (val === newVal) { 
                    return; 
                } 
                val = newVal; 
                observe(newVal); 
                dep.notify(); 
            } 
        }); 
    };
};

三、构建Compile构造函数

创建一个Compile构造函数，用于解析模板指令:

function Compile(el, vm) { 
    vm.$el = document.querySelector(el); 
    let fragment = document.createDocumentFragment(); 
    while (child = vm.$el.firstChild) { 
        fragment.appendChild(child); 
    } 
    replace(fragment);
    function replace(frag) {
        Array.from(frag.childNodes).forEach(node => { 
            let txt = node.textContent; 
            let reg = /\{\{(.*?)\}\}/g; 
            if (node.nodeType === 3 && reg.test(txt)) { 
                let arr = RegExp.$1.split('.'); 
                let val = vm; 
                arr.forEach(key => { val = val[key]; }); 
                node.textContent = txt.replace(reg, val).trim(); 
                new Watcher(vm, RegExp.$1, newVal => { 
                    node.textContent = txt.replace(reg, newVal).trim(); 
                }); 
            }
        if (node.nodeType === 1) { 
            let nodeAttr = node.attributes; 
            Array.from(nodeAttr).forEach(attr => { 
                let name = attr.name; 
                let exp = attr.value; 
                if (name.includes('')) { 
                    node.value = vm[exp]; 
                } 
                new Watcher(vm, exp, newVal => { 
                    node.value = newVal; 
                }); 
                node.addEventListener('input', e => { 
                    let newVal = e.target.value; 
                    vm[exp] = newVal; 
                }); 
             }); 
         };
         if (node.childNodes && node.childNodes.length) { 
             replace(node); 
         } 
       }); 
     }
     vm.$el.appendChild(fragment); 
}

四、构建Watcher构造函数

创建一个Watcher构造函数，用于更新视图:

function Watcher(vm, exp, fn) { 
    this.fn = fn; 
    this.vm = vm; 
    this.exp = exp; 
    Dep.target = this; 
    let arr = exp.split('.'); 
    let val = vm; 
    arr.forEach(key => { 
        val = val[key]; 
    }); 
    Dep.target = null; 
} 

Watcher.prototype.update = function() { 
        let arr = this.exp.split('.'); 
        let val = this.vm; 
        arr.forEach(key => { 
            val = val[key]; 
        }); 
        this.fn(val); 
}

五、构建Dep构造函数

创建一个Dep构造函数，用于管理Watcher:

function Dep() { 
    this.subs = []; 
} 

Dep.prototype.addSub = function(sub) { 
    this.subs.push(sub); 
} 

Dep.prototype.notify = function() { 
    this.subs.forEach(sub => { 
        sub.update(); 
    }); 
}

六、构建initComputed构造函数

创建一个initComputed构造函数，用于初始化计算属性:

function initComputed() { 
    let vm = this; 
    let computed = this.$options.computed; 
    Object.keys(computed).forEach(key => { 
        Object.defineProperty(vm, key, { 
            get: typeof computed[key] === 'function' ? computed[key] : computed[key].get, 
            set() {} 
        }); 
    }); 
}

总结：

至此我们就完成了一个简易的MVVM框架，虽然简易，但是基本的核心思想差不多都已经表达出来了，最后还是希望大家不要丢在收藏文件夹里吃灰，还是要多多动手练习一下，所谓眼过千遍，不如手过一遍。

作者：前端第一深情阿斌
来源：juejin.cn/post/7202431872968851517

前言

从输入 URL 到页面显示的发生过程，这是一个在面试中经常会被问到的问题，此问题能比较全面地考察应聘者知识的掌握程度。其中涉及到了网络、操作系统、Web 等一系列的知识。

以 Chrome 浏览器为例，目前的 Chrome 浏览器有以下几个进程：

浏览器进程。主要负责界面显示、用户交互、子进程管理，同时提供存储等功能。

渲染进程。主要职责是把从网络下载的 HTML、JavaScript、CSS、图片等资源解析为可以显示和交互的页面。

GPU 进程。其实，Chrome 刚开始发布的时候是没有 GPU 进程的。而 GPU 的使用初衷是为了实现 3D CSS 的效果，只是随后网页、Chrome 的 UI 界面都选择采用 GPU 来绘制，这使得 GPU 成为浏览器普遍的需求。

网络进程。主要负责页面的网络资源加载，之前是作为一个模块运行在浏览器进程里面的，后面才独立出来，成为一个单独的进程。

插件进程。主要是负责插件的运行，因插件易崩溃，所以需要通过插件进程来隔离，以保证插件进程崩溃不会对浏览器和页面造成影响。

1. 用户输入

如果输入的是内容，地址栏会使用浏览器默认的搜索引擎，来合成新的带搜索关键字的 URL。

如果输入的是 URL，那么地址栏会根据规则，把这段内容加上协议，合成为完整的 URL。

2. URL 请求过程

浏览器进程会通过进程间通信（IPC）把 URL 请求发送至网络进程，网络进程接收到 URL 请求后，会在这里发起真正的 URL 请求流程。那具体流程是怎样的呢？

网络进程会查找本地缓存是否缓存了该资源。如果有缓存资源，那么直接返回资源给浏览器进程；如果在缓存中没有查找到资源，那么直接进入网络请求流程。这请求前的第一步是要进行 DNS 解析，以获取请求域名的服务器 IP 地址。如果请求协议是 HTTPS，那么还需要建立 TLS 连接。

接下来就是利用 IP 地址和服务器建立 TCP 连接 (三次握手)。连接建立之后，浏览器端会构建请求行、请求头等信息，并把和该域名相关的 cookie 等数据附加到请求头中，然后向服务器发送构建的请求信息。

服务器接收到请求信息后，会根据请求信息生成响应数据（包括响应行、响应头和响应体等信息），并发给网络进程。等网络进程接收了响应行和响应头之后，就开始解析响应头的内容了。

Content-Type 是 HTTP 头中一个非常重要的字段， 它告诉浏览器服务器返回的响应体数据是什么类型，然后浏览器会根据 Content-Type 的值来决定如何显示响应体的内容。

如果 Content-Type 字段的值被浏览器判断为下载类型，那么该请求会被提交给浏览器的下载管理器，同时该 URL 请求的导航流程就此结束。但如果是 HTML，那么浏览器则会继续进行导航流程。

3. 准备渲染进程

如果协议和根域名相同，则属于同一站点。

但如果从一个页面打开了另一个新页面，而新页面和当前页面属于同一站点的话，那么新页面会复用父页面的渲染进程。

渲染进程准备好之后，还不能立即进入文档解析状态，因为此时的文档数据还在网络进程中，并没有提交给渲染进程，所以下一步就进入了提交文档阶段。

4. 提交文档

所谓提交文档，就是指浏览器进程将网络进程接收到的 HTML 数据提交给渲染进程，具体流程是这样的：

首先当浏览器进程接收到网络进程的响应头数据之后，便向渲染进程发起“提交文档”的消息。

渲染进程接收到“提交文档”的消息后，会和网络进程建立传输数据的“管道”。

等文档数据传输完成之后，渲染进程会返回“确认提交”的消息给浏览器进程。

浏览器进程在收到“确认提交”的消息后，会更新浏览器界面状态，包括了安全状态、地址栏的 URL、前进后退的历史状态，并更新 Web 页面。

5. 渲染阶段

一旦文档被提交，渲染进程便开始页面解析和子资源加载。

渲染进程将 HTML 内容转换为能够读懂的 DOM 树结构。

渲染引擎将 CSS 样式表转化为浏览器可以理解的 styleSheets，计算出 DOM 节点的样式。

创建布局树，并计算元素的布局信息。

对布局树进行分层，并生成分层树。

为每个图层生成绘制列表，并将其提交到合成线程。

合成线程将图层分成图块，并在光栅化线程池中将图块转换成位图。

合成线程发送绘制图块命令 DrawQuad 给浏览器进程。

浏览器进程根据 DrawQuad 消息生成页面，并显示到显示器上。

最后

以上就是笔者对这一常考面试题的一些总结，对于其中的一些具体过程并没有详细地列举出来。如有不足欢迎大家在评论区指出......

作者：codinglin
来源：juejin.cn/post/7202602022355779644

历史总会重演。一切刚过去的，又会被重新提起。开源项目Codename One的联合创始人Shai，曾是Sun Microsystems开源LWUIT项目的共同作者，参与了无数开源项目。作为最早一批Java开发者，最近感慨道：单体，又回来了！

Shai说道：我已经在这个圈子里很久时间了，看到了一次次被抛弃、被重新发现的想法，超越“时髦词汇”，并凯旋而归。

他进一步举例，“近年来，SQL也挣扎过后，死而复生。我们再次热爱关系数据库。我认为单体架构将再次迎来奇幻之旅。微服务和无服务器是云供应商推动的趋势，目的当然是在向我们兜售更多的云计算资源。然而对于大多数用例来说，微服务在财务上意义不大。是的，供应商当然也可以降低成本。但当他们扩大规模时，他们会以股息来覆盖掉成本。单是可观测性成本的增加，就让‘大型云’供应商的腰包鼓起来了！”

作为从业近30年的资深技术大神，为何做此感叹？本文通过一场“利用模块降低架构成本”的探讨，帮助大家梳理现在的架构设计难题，希望对诸君有所启发。

问题背景

我最近领导了一个会议小组，讨论了微服务与单体服务的主题。组内认为，单块的规模不如微服务。这对于亚马逊、eBay等所取代的那些庞然大物来说可能是正确的。这些确实是巨大的代码库，其中的每一次修改都是痛苦的，而且它们的扩展都是具有挑战性的。但这不是一个公平的比较。较新的方法通常优于旧的方法。但如果我们用更新的工具构建一个整体，我们会得到更好的可扩展性吗？它的局限性是什么？现代的单体（也称巨石）到底该是什么样子？

单体回归范例：Modulith

Spring Modulith是一个模块化的单体结构，可以让我们使用动态隔离件构建单体结构。通过这种方法，我们可以分离测试、开发、文档和依赖项。这有助于微服务开发的独立方面，而所涉及的开销很少。它消除了远程调用和功能复制（存储、身份验证等）的开销。

Spring Modulith不是基于Java平台模块化（Jigsaw）。他们在测试期间和运行时强制分离，这是一个常规的Spring Boot项目。它有一些额外的运行时功能，可以实现模块化的可观测性，但它主要是“最佳实践”的执行者。这种分离的价值超出了我们通常使用微服务的价值，但也有一些权衡。

举个例子，传统的Spring monolith将采用分层架构，其包如下：

com.debugagent.myapp
com.debugagent.myapp.services
com.debugagent.myapp.db
com.debugagent.myapp.rest

这很有价值，因为它可以帮助我们避免层之间的依赖关系；例如，DB层不应依赖于服务层。我们可以使用这样的模块，并有效地将依赖关系图推向一个方向：向下。但随着我们的成长，这没有多大意义。每一层都将充满业务逻辑类和数据库复杂性。

有了Modulith，我们的架构看起来更像这样：

com.debugagent.myapp.customers
com.debugagent.myapp.customers.services
com.debugagent.myapp.customers.db
com.debugagent.myapp.customers.rest

com.debugagent.myapp.invoicing
com.debugagent.myapp.invoicing.services
com.debugagent.myapp.invoicing.db
com.debugagent.myapp.invoicing.rest

com.debugagent.myapp.hr
com.debugagent.myapp.hr.services
com.debugagent.myapp.hr.db
com.debugagent.myapp.hr.rest

这看起来非常接近一个合适的微服务架构。我们根据业务逻辑分离了所有部分。在这里，可以更好地控制交叉依赖关系，团队可以专注于自己的孤立区域，而不必互相踩脚。这是微服务的价值之一，且没有开销。

我们可以使用注释进一步深入地和声明性地实现分离。我们可以定义哪个模块使用哪个并强制单向依赖关系，因此人力资源模块将与发票无关。客户模块也不会。我们可以在客户和发票之间建立单向关系，并使用事件进行反馈。Modulith中的事件是简单、快速和事务性的。它们消除了模块之间的依赖关系，无需麻烦。这可以用微服务实现，但很难实现。比如，开票需要向不同的模块公开接口。如何防止客户使用该界面？

有了模块，我们就可以做到。对用户可以更改代码并提供访问权限，但这需要经过代码审查，这会带来自己的问题。请注意，对于模块，我们仍然可以依赖常见的微服务，如功能标志、消息传递系统等。您可以在文档和Nicolas Fränkel的博客中阅读有关Spring Modulith的更多信息。

模块系统中的每个依赖项都被映射并记录在代码中。Spring实现包括使用方便的最新图表自动记录所有内容的能力。你可能会认为，依赖性是Terraform的原因。对于这样的“高级”设计来说，这是正确的地方吗？

对于Modulith部署，像Terraform这样的基础设施即代码（IaC）解决方案仍然存在，但它们会简单得多。问题是责任的划分。正如下图所展示，微服务并没有消除整体结构的复杂性。我们只把“难啃的骨头”踢给了DevOps团队。更糟糕的是，我们没有给他们正确的工具来理解这种复杂性，所以他们不得不从外部管理。

图源：Twitter

这就是为什么我们行业的基础设施成本在上升，而传统行业的基础设施价格却在下降。当DevOps团队遇到问题时，他们会投入资源。这显然不是正确的做法。

其他模块

我们可以使用标准Java平台模块（Jigsaw）来构建Spring Boot应用程序。这样做的好处是可以分解应用程序和标准Java语法，但有时可能会很尴尬。当使用外部库或将一些工作拆分为通用工具时，可能会更有效。

另一个选项是Maven中的模块系统。这个系统允许我们将构建分解为多个单独的项目。这是一个非常方便的过程，可以让我们省去大量项目的麻烦。每个项目都是独立的，易于使用。它可以使用自己的构建过程。然后，当我们构建主项目时，这些全部都变成了一个单体。在某种程度上，这才是我们真正想要的。

单体架构：扩展，有解吗

可以使用大多数微服务扩展工具来扩展我们的单体们。许多与扩展和集群相关的开发都是在单体架构的情况下进行的。这是一个更简单的过程，因为只有一个移动部分：应用程序。我们复制其他实例并观察它们。没有哪项服务是失败的。我们有细粒度的性能工具，所有的功能都可以作为一个统一的版本。

我认为扩展单体为微服务比直接构建微服务更简单——

• 我们可以使用分析工具，并获得瓶颈的合理近似值。

• 我们的团队可以轻松地（并且经济实惠地）设置运行测试的登台环境。

• 我们拥有整个系统及其依赖关系的单一视图。

• 我们可以单独测试单个模块并验证性能假设。

跟踪和可观测性工具非常棒。但它们也会影响生产，有时还会产生噪音。当我们试图解决伸缩瓶颈或性能问题时，这些工具可能会让设计者踩一些坑。

我们可以将Kubernetes与monolits一起使用，就像将其与微服务一起使用一样有效。镜像尺寸会更大（如果我们使用GraalVM这样的工具，则可能不会太大）。有了这一点，我们可以跨区域复制monolith ，并提供与微服务相同的故障转移行为。相当多的开发人员将monolics部署到Lambdas。笔者不太喜欢这种方法，因为非常昂贵。

单体的瓶颈问题：有解

但仍有一点是巨大的障碍：数据库。由于微服务固有地具有多个独立的数据库，因此它们实现了巨大的规模。单体架构通常与单个数据存储一起工作。这通常是应用程序的真正瓶颈。有多种方法可以扩展现代数据库。集群和分布式缓存是强大的工具，可以让我们达到在微服务架构中很难达到的性能水平。

在一个单体结构中，也并不需要单个数据库。例如：在使用Redis进行缓存时，选择使用SQL数据库也是很常见的事情。但我们也可以为时间序列或空间数据使用单独的数据库。我们也可以使用单独的数据库来提高性能，尽管根据笔者经验，这种情况从未发生过。将数据保存在同一数据库中的好处是巨大的。

回归单体的好处

事实上，这样做有一个惊人的好处，我们可以在不依赖“最终一致性”的情况下完成交易。当我们尝试调试和复制分布式系统时，可能会遇到一个很难在本地复制的过渡状态，甚至很难通过查看可观测性数据来完全理解。

原始性能消除了大量网络开销。通过适当调整的二级缓存，我们可以进一步删除80-90%的读IO。在微服务中，要实现这一点要困难得多，而且可能不会删除网络调用的开销。

正如我之前提到的，应用程序的复杂性在微服务架构中不会消失。我们只是把它搬到了另一个地方。所以从这个层面讲，微服务并不算真正的进步，因为在此过程中平白添加了许多移动部件，增加了整体复杂性。因此，回归更智能、更简单的统一架构更有意义。

再看微服务的卖点

编程语言的选择是微服务亲和力的首要指标之一。微服务的兴起与Python和JavaScript的兴起相关。这两种语言非常适合小型应用程序，对于较大型的应用就不太适用了。

Kubernetes使得扩展此类部署相对容易，因此为已经增长的趋势增添了动力。微服务也有一些相对快速的升降能力。这可以以更细粒度的方式控制成本。在这方面，微服务被出售给组织，作为降低成本的一种方式。

这并非完全没有优点。如果以前的服务器部署需要强大（昂贵）的服务器，那么这一论点可能有一定道理。这可能适用于极端使用的情况，比如：突然面临非常高的负载，但随后没有堵塞。在这些情况下，可以从托管的Kubernetes提供商动态（廉价）获取资源。

微服务的主要卖点之一是组织调度方面。这使得各个敏捷团队能够在不完全了解“大局”的情况下解决小问题。问题也在于此，这就会创造一种“单干”文化，让每个团队都“自己做自己的事情”。在缩减规模的过程中，尤其是在代码“腐烂”的情况下，问题更甚。系统可能仍能工作数年，但实际上无法维护。

互联网建立在单体之上为什么要离开呢

笔者组内中的一个共识是，我们应该始终从单体开始。它更容易构建，如果我们选择使用微服务，我们可以稍后将单体分解。

提及具体某个软件相关的复杂性,我们讨论单个模块而不是单个应用程序要更有意义些。二者在资源使用和财务浪费上的差异是巨大的。在这个追求“降本”的时代，为什么人们还要不知变通地默认构建微服务，而不是动态的模块化单体架构呢？

我们可以从这两大“架构阵营”学到很多东西。诚然，微服务为亚马逊创造了奇迹。但公平地说，他们的云成本已包含在这个奇迹之中。所以，一位的搞微服务教条肯定是有问题的。

另一方面，互联网是建立在单体之上的。它们中的大多数都不是模块化的。两者都有普遍适用的技术。因此，笔者看来，正确的选择是构建一个模块化的单体结构，先搭建好合适的身份验证基础设施，如果我们想在未来转向微服务，我们可以利用这些基础设施来进行解构拆分。

后记

在设计应用时，我们目前更多是面临“二选一”的架构选择：单体和微服务。它们二者通常被视为相反的方法。

在小型系统演进过程中，有这样一个不争的事实：单体应用程序往往会随着时间的推移而在架构上降级，即使在其生命周期开始阶段就定义其为架构。随着时间的推移，各种架构的禁止事项会不知不觉地进入项目，久而久之，系统变得更难改变，进化性受到影响。

另一方面，微服务提供了更强的分离手段，但同时也带来了许多复杂性，因为即使对于小型应用程序，团队也必须应对分布式系统的挑战。

单体回归，也是具体的有条件的回归。我们看到，趋势的改变，代表着某段时期具体任务或者目标正在变化。出于目标的变化，我们对于微服务和单体架构的二选一的选择问题，也不能再教条式的看待。

事物往往都在螺旋式的演进，对于架构而言，亦如是。

来源：mp.weixin.qq.com/s/2peN_MezvkR9UwtalhG6kA

原文链接：dzone.com/articles/is-it-time-to-go-back-to-the-monolith

vue中Axios添加拦截器刷新token的实现方法

Axios是一款网络前端请求框架，本文主要介绍了vue中Axios添加拦截器刷新token的实现方法，

1. Axios基本用法：

        const response = await Axios.create({
            baseURL: "https://test.api.com",
            headers: {
                'Content-Type': 'application/json',
            },
          }).post<RequestResponse>('/signin', {
            user_id: "test_user",
            password: "xxx",
        });

其中，RequestResponse是返回的数据要解析为的数据类型，如下：

export interface RequestResponse {
    data: any;
    message: string;
    resultCode: number;
}

这样，得到的response就是网络请求的结果，可以进行判断处理。

2. Axios基本封装用法：

对Axios进行简单的封装，使得多个网络请求可以使用统一的header等配置。

新建一个工具类，进行封装：

import Axios, { AxiosRequestConfig, AxiosError, AxiosInstance, AxiosResponse } from 'axios';
 
export const BASE_URL = "https://test.api.com";
 
export const axiosApi = (): AxiosInstance => {
  const instance = Axios.create({
    baseURL: BASE_URL,
    headers: {
       'Content-Type': 'application/json',
       Authorization: `${getAccessToken()}`,
    },
  });
    
  return instance;
}
 
const getAccessToken = () => {
    // 这里获取本地保存的token
    return xxxxx
}

然后使用的地方是这样：

const response = await axiosApi().post<RequestResponse>('/signin', {
     user_id: "test_user",
     password: "xxx",
});

3. 添加拦截器的用法

现在我们想再增加个功能，就是调接口时，header里传了token，但是有时候token过期了接口就会返回失败，我们想在封装的地方添加统一处理，如果token过期就刷新token，然后再调接口。

其中token的数据格式及解析方法已知如下：

import * as crypto from 'crypto';
import * as jwt from "jsonwebtoken";
 
export interface TokenData {
  userid: string;
  exp: number;
  iat: number;
}
 
export const decodeJWT = function (token: string): TokenData {
  if (!token) {
    return null;
  }
  const decoded = jwt.decode(token, { complete: true });
  return decoded?.payload;
};

如何统一刷新token呢？可以添加拦截器进行处理。把对Axios的封装再改下，添加拦截器：

export const axiosApi = (): AxiosInstance => {
  const instance = Axios.create({
    baseURL: BASE_URL,
    headers: {
       'Content-Type': 'application/json',
       Authorization: `${getAccessToken()}`,
    },
  });
  
  // 添加拦截器
  instance.interceptors.request.use(
    config => {
      return refreshToken(config);
    },
    err => {
      return Promise.reject(err)
    }
  )
  return instance;
}
 
// 刷新token的方法
const refreshToken = async (config: AxiosRequestConfig) => {
  const oldToken = getAccessToken();
  if (!oldToken) { //如果本地没有token，也就是没登录，那就不用刷新token
    return config;
  }
 
  const tokenData = decodeJWT(oldToken);//解析token，得到token里包含的过期时间信息
  const currentTimeSeconds = new Date().getTime()/1000;
 
  if (tokenData && tokenData.exp > currentTimeSeconds) {
    return config; // token数据里的时间比当前时间大，也就是没到过期时间，那也不用刷新
  }
 
  // 下面是刷新token的逻辑，这里是调API获取新的token
  const response = await signInRefreshToken(tokenData?.userid);
  if (response && response.status == 200) {
    const { token, refresh_token } = response.data?.data;
    // 保存刷新后的token
    storeAccessToken(token);
    // 给API的header设置新的token
    config.headers.Authorization = token;
  }
  return config;
}

经过这样添加了拦截器，如果token没过期，就直接进行网络请求；如果token过期了，那就会调接口刷新token，然后给header设置新的token再进行网络请求。

4. 注意事项：

要注意的一点是，实际应用时，要注意：

1.刷新token时如果调接口，所使用的网络请求工具不能也使用这个封装的工具，否则就会陷入无限循环，可以使用简单未封装的方式请求。

2.本例使用的方法，是进行请求前刷新token。也可以使用先调网络请求，如果接口返回错误码表示token过期，则刷新token，再重新请求的方式。

作者：程序员小徐同学
来源：juejin.cn/post/7159727466439770119

在日常提交 PR 的过程中，我们提交的文件不应该有例如 console、debugger、test.only 等调试语句，这会影响到线上代码。那每次提交之前都检查似乎又像是一个繁琐的工作，如果有个工作能代替我们检查我们提交的代码，让不能提交到线上的代码在 commit 阶段停止下来，对 code reviewer 的工作会减少不少。 这里就来跟大家探讨一下我的一个实现方式。

前言

在提交代码的时候不知道大家有没有注意命令行中会打印一些日志：

像这里的

husky > pre-commit
🔍 Finding changed files since ...
🎯 Found 3 changed files.
✅ Everything is awesome!
husky > commit-msg

这个出处大家应该都知道，来自 pretty-quick ，然后通过 packge.json 中的：

  "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS",
      "pre-commit": "pretty-quick --staged"
    }
  }

这段代码在我们 commit 的时候对代码进行相关处理。

这里是 husky 调用了相关的 Git hooks ，在合适的时机处理我们提交的代码文件，从而使我们的代码达到提交的要求（如上面的是格式化相关代码）。

看到这里肯定大家就会想到，那这个是不是可以做的还有更多？

没错，下面就直接上配置，来实现我们不想让某些代码提交到线上这样的需求。

第一版

知道这个原理，那就很简单了，我们在 pre-commit 这个事件触发的时候对我们要提交代码检查一下，看其中有没有那几个关键字就可以了。

那就直接动手：

我们在项目根目录找到 .git/hooks :

可以看到，这里提供了各种触发时机，我们找到我们想要的 pre-commit （如果后缀有 .sample，需要去除掉才能让此文件生效）。打开此文件，前端的话应该看到的是（不需要阅读）：

#!/bin/sh
# husky

# Hook created by Husky
#   Version: 2.7.0
#   At: 2023/2/2 13:14:26
#   See: https://github.com/typicode/husky#readme

# From
#   Directory: /Users/frank/Documents/work/worktile/wt-cronus/projects/pc-flow-sky/node_modules/husky
#   Homepage: undefined

scriptPath="node_modules/husky/run.js"
hookName=`basename "$0"`
gitParams="$*"

debug() {
  if [ "${HUSKY_DEBUG}" = "true" ] || [ "${HUSKY_DEBUG}" = "1" ]; then
    echo "husky:debug $1"
  fi
}

debug "$hookName hook started"

if [ "${HUSKY_SKIP_HOOKS}" = "true" ] || [ "${HUSKY_SKIP_HOOKS}" = "1" ]; then
  debug "HUSKY_SKIP_HOOKS is set to ${HUSKY_SKIP_HOOKS}, skipping hook"
  exit 0
fi


if ! command -v node >/dev/null 2>&1; then
  echo "Info: can't find node in PATH, trying to find a node binary on your system"
fi

if [ -f "$scriptPath" ]; then
  # if [ -t 1 ]; then
  #   exec < /dev/tty
  # fi
  if [ -f ~/.huskyrc ]; then
    debug "source ~/.huskyrc"
    . ~/.huskyrc
  fi
  node_modules/run-node/run-node "$scriptPath" $hookName "$gitParams"
else
  echo "Can't find Husky, skipping $hookName hook"
  echo "You can reinstall it using 'npm install husky --save-dev' or delete this hook"
fi

看了下，感觉没啥用，就是一个检测 husky 有没有安装的脚本。我们这里直接使用下面的替换掉：

#!/bin/sh

errorForOnly() {
  result=""
  for FILE in `git diff --name-only --cached`; do
      # 忽略检查的文件
      if [[ $FILE == *".html"* ]] ; then
          continue
      fi
      # 匹配不能上传的关键字
      grep 'serial.only\|console.log(\|alert(' $FILE 2>&1 >/dev/null
      if [ $? -eq 0 ]; then
          # 将错误输出
          echo '❌' $FILE '此文件中包含 [only]、[console]、[alert] 中的关键字, 删除后再次提交'
          # exit 1
          result=0
        else
          result=1
        fi
  done

  if [[ ${result} == 0 ]];then
        exit 1
  fi
  echo "✅ All files is OK!"

}

errorForOnly

然后我们在一些文件中添加我们不想要的关键字，然后 git commit :

可以看到错误日志以及文件已经在命令行中打印出来了，同时文件也没有进入本地仓库（Repository），让然在我们的暂存区（Index）。

使用这个方式，在一定程度上我们避免了提交一些不想要的代码到线上这种情况了发生。同时也是在本地提交代码之前就做了这个事情，也避免了使用服务端 hooks 造成提交历史混乱的问题。

这时候你肯定会产生这样的疑问：

【欸，欸，欸，不对啊】

问题

这种方式有个显而易见的问题，那就是不同团队协同方面。由于 hooks 本身不跟随克隆的项目副本分发，所以必须通过其他途径把这些 hooks 分发到团队其他成员的 .git/hooks 目录并设为可执行文件。

另外一个问题是我们使用了 husky，在每次 npm i 之后都会重置 hooks 文件。也就是 .git/hooks/pre-commit 文件恢复到了最初（只有 husky 检测的代码）的样子，没有了我们写的逻辑。

这种情况是不能允许的。那就寻找解决途径。查了下相关文档，发现可以使用新版的 husky 来解决这个问题。（其他相关的工具应该也可以，这里使用 husky 来进行展示）。

最新实现

husky 在 v4 版本之后进行了大的重构，一些配置方式不一样了，至于为什么重构，大家可以去

安装

安装 npm install husky --save-dev

安装最新版本为 8.0.3 ，安装完成后启用 Git hooks: npx husky install

在团队协作的情景下，得让本团队的其他人也能自动的启用相关 hooks ，所以添加下面这个命令，在每次 npm install 之后执行：

npm pkg set scripts.prepare="husky install"

我们就在 package.json 得到了这样的命令：

yarn2+ 不支持 prepare 生命周期脚本命令， 安装方式在此处

使用

先按照官方文档测试一下，执行 npx husky add .husky/pre-commit "npm test" 在相关目录我们就看到：

相应的文件以及内容已经准备就绪。这里就不运行了。

那如何将之前的流程使用新的版本配置好呢？

这里直接提供相关文件内容：

# .husky/commit-msg
# 用于 commit 信息的验证
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npx --no -- commitlint --edit $1

使用下面的语句生成；

npx husky add .husky/commit-msg 'npx --no -- commitlint --edit `echo "\$1"`'

另外还有 pre-commit:

# .husky/pre-commit
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

# pretty-quick 相关
npx pretty-quick --staged

# 验证是否有调试关键字的脚本：
node bin/debugger-keywords.js

脚本内容：

// bin/debugger-keywords.js

const { execSync } = require('child_process');

const fs = require('fs');

const gitLog = execSync('git diff --name-only --cached').toString();

const fileList = gitLog.split('\n').slice(1);

const keyWordsRegex = /(console\.(log|error|info|warn))|(serial\.only)|(debugger)/g;

const result = [];



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

    const filePath = fileList[i].trim();



    if (filePath.length === 0 || filePath.includes('.husky') || filePath.includes('bin/')) {

        continue;

    }

    const fileContent = fs.readFileSync(`${filePath}`, 'utf8');

    const containerKeyWords = Array.from(new Set(Array.from(fileContent.matchAll(keyWordsRegex), m => m[0])));



    if (containerKeyWords.length > 0) {

        const log = `❌  ${filePath} 中包含 \x1B[31m${containerKeyWords.join('、')}\x1B[0m 关键字`;

        result.push(log);

        console.log(log);

    }

}



if (result.length >= 1) {

    console.log(`💡  修改以上问题后再次提交  💡`);

    process.exit(1);

} else {

    console.log('✅  All files is OK! \n');

    process.exit(0);

}

为几个文件添加 console 、测试 only 等，提交 commit 后效果展示：

会提示文件中不合规的关键字是哪些。

更多

有了以上的使用示例，我们可以在随意添加脚本，比如，为 19:00 之后或周末提交代码的你来上一杯奶茶🧋和一个甜甜圈🍩：

// bin/check-time.js
const now = new Date()
const week = now.getDay()
const hour = now.getHours()
const validWeek = week >= 1 && week <= 5
const validHour = hour >= 9 && hour < 19
if (validHour && validWeek) return

console.log(`🌃  来点 🧋   🍩`);

这次为了方便也在 pre-commit hook 中执行：

# .husky/pre-commit
#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

# pretty-quick 相关
npx pretty-quick --staged

# 验证是否有调试关键字的脚本：
node bin/debugger-keywords.js

# 来杯奶茶
node bin/check-time.js

来看下结果：

结论

目前单纯使用 pre-commit hook 针对常见的 console、debugger 还有测试 only 这种。但是我们也可以看到只要我们写不同的脚本，可以实现不同的需求。

之后如果有更多的需求也能继续添加脚本，也可以产生我们 PingCode 自己的 lint 插件。

ps. 如果使用可视化工具提交可能会报错，大家可以自行查阅解决。

作者：阿朋
来源：juejin.cn/post/7202392792726011959

前言

先介绍一下个人情况，方便给正在求职的朋友一个参考。

本人是19年非计算机专业某末端二本毕业，去年8月31日从一线的一家国企离职，回去家里休息了一个多月，在国庆结束之后落地到了新的城市，开始了我的前端自救之旅。

10月17日开始投递简历，到10月27日决定停止面试。一共面试了6家公司，最终拿到了2家公司的offer。

我简历主要写到了vue、微信公众号、微信小程序、node.js（主要是egg.js和koa.js）、webpack和团队管理的经验。

我对react的使用比较少，所以react问的比较深的岗位我都没有投递。

经过了半个多月的面试经历，我主要从市场环境、作为面试官的体验、面试题目三部分聊一下我的心得。

为了对前东家和现东家表示尊重，我分别用A市代替上一个城市，C市代替现在的城市，并且把关键信息隐藏。

市场环境

还在A市的时候，只是听同事说了一下外面的情况很糟糕，如果考虑换工作的话建议三思后行，一定要想清楚了再决定是不是要行动。

我这人有点不信邪，因为这样的话我好像都听腻了。

小时候老师这样劝诫我，长大了父母这样叮嘱我，工作了老板这样劝说我。

周围的声音都劝你，要走最安全的路，不要冒险。

直到我打开了脉脉。

为了保护截图楼主的隐私，特意打了马赛克。

从脉脉上面反馈的话题都很让人绝望，仿佛每个人在脉脉上过的都很惨。

每天刷出来的话题都跟职场末日一样。

但是我自己的路还是要自己走的，别人的世界和经历只能作为参考，无法影响我的决定。

于是，我选择性的忽视了脉脉话题的讨论。

专注于自己当下的问题，直面最现实的问题，并解决这些问题。

这里有一点建议需要给到仍在空窗期的朋友：如果此时正处于职场求职的阶段，应该尽可能的忽略会给你产生自我怀疑或者负能量的东西，这些东西的一点点腐蚀你的心智，磨灭你的念想，进而影响你对当下正确的判断。

面试官的体验

我在上一家公司担任的是技术负责人的身份，所以在去年8月初跟上级领导提出离职的申请之后，就开始帮公司招人了。

所以我也能从面试官的视角给求职者提供一些有利的信息，进而促成面试的成功。

主要从下面3点展开来说一下吧。

1、投递有可能没有回应

给大家分享一个简历投递的小故事。

8月12日，公司人事上午刚把前端的岗位发布出去，仅仅经过了2个小时，我就收到了人事发给我的50份简历。

然后我从这50份简历里面选出了12份作为候选人，接着人事给候选人打电话，7位候选人接通了电话，并预约了面试时间。

下午人事又筛选了60份简历给我，我从这些简历里面筛选出了8位候选人，人事打电话，6位接通了电话。

这样下周就有了14位候选人进行面试，我也跟人事说暂时先不接收简历了，当前的面试结束之后，再开放招聘岗位吧。

同时说一下我的心理状态吧。

上午我刚拿到简历的时候看的很仔细，每一份简历都很认真的去看，甚至会看一下他的项目介绍。

但是当我上午看完了50份简历，我觉得很多简历很雷同，长得都差不多，千篇一律的感觉。

下午又收到了60份简历，这个时候我基本看麻了，如果技术栈方面不匹配（比如我们项目要求的是vue，但是以前的项目都是react，这样的简历我就直接跳过了），基本就不会预约面试了。

所以说，招聘的时机是有很大的偶然性的。

如果你的投递时间正好是8月12号的上午，并且是在我看简历的前1个小时，只要能满足干活的能力，大概率都有面试邀约。

但如果投递时间是在8月12号的下午，必须要技术栈强匹配，项目相对复杂，简历写精炼简洁，能一眼抓住我的眼球，才能获得邀约。

另一方面来看，

如果投递时间不是8月12号这一天的话，我其实是看不到你投递的简历的。

因为在我说下周之内都不需要给我推简历之后，人事很大概率会把这个职位挂着。

但是面试者是不了解我这边的情况，看到岗位还在招聘，就会继续投递简历。但真实的情况是：我已经触达不到他们了，简历投进来基本石沉大海。

这样有一些朋友在投递过程中遇到的很多公司人事没有回馈，很大可能是遇到了上述我说的情况：简历都在排着队，触达不到面试官。

所以正在求职的朋友也不要灰心，把时间线拉长来看这个事情。公司跟个人之间是双向选择的，好事多磨，最终都能获得自己想要的。

2、简历是门面

简历是作为公司能够在没有见到真人情况下，对你能力最直接的预判，然后决定是否需要把你列入候选人名单的重要条件。

所以这个门面特别重要。

首先是基本信息一定要清晰。

姓名、年龄、性别、工作年限、手机号、邮箱、学历跟求职地点一定要写清楚，这些算是必填项了。

然后技术栈尽量简短概括，陈述你大概能做哪些事情。

我在招聘求职者的时候首要看这一项，技术栈不精练的可能就直接跳过了。

像jquery、bootstrap这些比较老的库，或者说类似elementui等ui库尽量都不要写上去，看上去显得重复累赘，没有突出重点。

还有学历方面，上家公司的招聘学历是硬性要求的。

我也看到有技术能力完全能胜任的的两个面试者，就因为学历问题被卡了。问了人事学历能不能放宽一点，她说是硬性规定，不能放开。

我想人事大概也是不想徒增麻烦吧，直接按照流程走总不会出错，也能理解。

但是站在专科的求职者角度，技能到了但是因为学历原因，也就缺少了一个机会，还是有点遗憾的。

但是对于卡学历的求职者，我也显得有心无力，帮不上忙。

3、自我介绍很重要

面试的第一步首先是自我介绍，我认为这个是非常重要的一步。

其实面试官在拿到求职者简历的时候，可能也没有很认真的阅读。

所以面试官让你进行自我介绍，一方面是留给自己时间让面试官有的一个看你简历重点的缓冲时间，另一方面也希望你说点跟简历上不一样的东西，然后从自我介绍中找到话题，向求职者提问。

在我的面试体验下来，我觉得会让我比较舒服的自我介绍时间是2分钟左右。

一方面过于简短的自我介绍会让我感觉到面试者对项目或者对自己的认识不够深入，或者自我介绍就是简历中已经写过问题的重述，都让我感觉准备不充分，有青涩感。

还有过短的自我介绍会让面试官在认真看简历的过程有有一种突然被打断，或者没太想好根据简历中哪一个具体的点进行发问而错失了首次接触的好感度。

当然我其实在面试时已经会建立一个准备提问的题库。

即使面试者没有项目亮点，我也能就根据我在开发中遇到的问题或者一些基本面试题进行发问。

面试本身两个人就像聊天一样，本质上还是人之间情感的交互。

只要有人的地方，就会掺杂个人的情感偏好，相互之间有情绪感情的传递。

提供正向的情绪，尽可能的体现自己的加分项、专业度能让面试官觉得你很靠谱、值得推荐。

同时也能增加面试官对你的好感度。

举个栗子：我在面试中遇到一个女生在自我介绍的时候，她先简要介绍了一下自己常用的技术栈以及对应技术栈的熟悉程度，然后介绍了她上家公司做的项目，分模块的介绍一下自己在这些模块中做的事情以及两个业务线之间的关系。

她的介绍大概在3分钟左右，整个介绍说的比较有条理、有逻辑性，在她做完自我介绍的之后，我基本已经知道从她项目中挖掘哪些问题进行提问了。

全程没有一句废话，这让我对她的专业度的好感就增加了；即使她后面vue的一些原理说的很磕磕巴巴，但最后因为第一印象，我还是推荐了她。

在我面试的所有女生中，提炼中心思想，能有条理且有主次的把自己的擅长的技术和业务说明白的，她是最好的一个。因为我所在的业务生产线需要做一些跨部门沟通，所以能一句话说清楚自己的需要，情商在线的话，能提高整个工作的效率。

面试中整理的面试题

接下来就是在这6家公司面试中遇到的问题了。

一、公司一

1、机试

1、把一个url拆解成origin、文件名、hash拆解成示例的格式。
2、两个数组合并成一个数组，并进行算法优化。
3、设置值的时候是数字，输出的时候变成百分号的格式。
4、首屏优化的方案，分别从代码、网络和缓存说一下。
5、如果一次性增加100万个用户访问项目，前端角度你会怎么优化。
6、分别用es5和es6的方式解决一个继承问题

2、现场面试

第一轮的机试过了，约了下周进行面试。

双休在知乎上搜了一下这家公司，网上风评不太好，技术栈也不是我熟悉的，就拒绝了接下来的面试。

二、公司二

1、一面

1、简单的介绍一下你自己
2、你们这项项目中有微信公众号、后台管理端、医生app端和小程序端，有没有提炼出一些公共的工具js，怎么提炼的？
3、你们的git分支管理是怎么样的？
4、你在做完前端项目之后，一般都会写哪些文档，readme里面写一些什么？
5、你做完一个项目之后写一些什么内容，让接手你的人能够看懂你的项目架构，并且迅速上手？
6、你基于你的脚手架做了哪些优化？
7、你们的项目文档一般都要记录哪些基本的东西？
8、有在项目中遇到过xss攻击吗？
9、你这个错误数据上报了哪些数据，怎么实现的？
10、成功抵御过多次攻击能具体说一说吗？
11、说一下你在项目中遇到印象深刻的项目场景，并且怎么解决的？
12、能说一下session跟jwt的优缺点吗？
13、你说用户登录之后要在session中加入user_name，为什么要增加？
14、jwt的整个流程怎么实现的？
15、实现jwt的实现遇到什么困难了吗？
16、如果同一部手机用户A登录了，更换了B登录，此时使用jwt会出现什么问题？
  - 我觉得这里他给挖坑了，B登录了之后就会返回B用户的token，然后请求头带着的就是B的token，验证到的用户也就是B，我认为没有问题啊。我不太清楚他说的可能会有什么问题值啥情况，可能是我考虑不周全，如果有网友知道可以提醒一下我他想问的答案，让我学习一下。
17、当线上出了紧急bug的时候，你们是怎么处理的？
18、你们团队成员是怎么配合完成任务的？
19、你近2年的职业规划？
20、还有什么想问我的吗？

问的一些问题偏向于后端，面试官大概是java工程师吧。然后从团队管理、怎么让新来的成员快速接手项目、文档方便的管理等等；前端技术问题整个面试过程中占比不大。

看得出来至少要在团队管理方面有比较深的总结，并且对于团队管理积累上，自己有独有的见解，一面才能面试通过。

一面就败了的原因，主要偏向于管理方面的经验，这部分我总结比较少。

另一方面，我觉得有可能招聘单位也没太想清楚要招聘怎样的人吧，时间过去了半年，我今天刷了一下boss直聘，发现这家公司的招聘信息还挂着，人事活跃时间也是几分钟前。

三、公司三

1、一面

1、事件循环的机制了解吗？宏任务和微任务的执行顺序是怎样的？
2、怎么理解闭包这个定义的，在平时工作中有用到闭包的使用吗，举个例子。
3、vue组件间的哪些通信方式？
4、一个父组件潜嵌套了子组件，他的生命周期函数顺序是怎么执行的？
5、vue的权限管理应该怎么做？路由级和按钮级分别怎么处理？
6、说一下你对虚拟DOM的理解
7、了解diff算法吗？vue的diff算法是怎样的一个过程
8、能说一下v-for中key的作用吗？
9、做过vue项目哪些性能方面的优化？
10、vue组件为什么只能有一个根元素？
11、如何实现路由懒加载呢？
12、客户端渲染和服务端渲染有什么区别呢？在之前的工作中有做过服务端渲染吗？
13、Vue长列表的优化方式怎么做？
14、Vue3相比Vue2有哪些优化？
15、为什么在模板中绑定事件的时候要加.native?
16、能说一下响应式原理的过程吗？
17、数组的响应式怎么实现的？
18、Vue是数据改变后页面也会重新改变嘛；this.a = 1; this.a = 2; 他是怎么实现异步更新优化整个渲染过程的？
19、render函数封装有什么特别的，或者用到比较巧妙的东西吗？
20、浏览器缓存的方式有哪些？
21、正向代理和反向代理的区别？
22、域名解析过程是怎样的？
23、TCP协议三次握手、四次挥手的过程，为什么挥手要4次？

2、二面

1、nextTick, setTimeout 以及 setImmediate 三者有什么区别?
2、说一下你在项目的安全性做了哪些工作？
3、当一张表数据量比较多的时候，为了提高查询速度，你们一般会使用哪些方式做优化？
4、webSocket与传统的http相比有什么优势？
5、用过koa吗？简要阐述一下koa的洋葱模型。
6、用过promise吗？它的使用是为了解决一个什么问题？promise底层是怎么设计的？
7、你们现在整个登录鉴权是怎么设计的？如果要考虑单点登录呢，会如何设计？
8、如何用同一套代码部署到服务器中，怎么区分当前本地开发环境还是线上环境？是测试环境还是生产环境呢，怎么去区分？
9、待支付的订单，到期后主动取消这个功能你会怎么设计去做？
10、如果要做音视频的安全性，你能想到哪些方案？
11、多台服务器部署定时任务怎么保证一个任务只会做一遍呢？
12、你觉得程序员除了提升技术能力之外，其他什么能力你比较看重？

3、人事面

人事面遇到的问题都比较类似，我在下面会专门拿一个部分汇总人事面的问题。

该公司最后也拿到了offer。

四、公司四

1、你在项目中用到mongodb吗？
2、在项目中用到mongodb存储哪些数据？
3、mongodb的管道有了解吗？聚合管道怎么用的？
4、mongodb和的mysql优缺点？
5、你对事务性的了解是怎样的？
6、node怎么开启子进程？
7、在一台机器上开启负载均衡的时候，如果这个项目有用到定时任务，你怎么去控制这个定时任务只会执行一次？
8、你在egg中怎么开启子进程，怎么编写一个定时任务？
9、react用的多吗？
10、react组件间通信的方式有哪些？
11、vuex跟redux的区别有哪些？
12、computed和watch的区别？
13、watch和computed哪一个可以实现异步？
14、vue的通信方式有哪些？
15、vue的history模式和hash模式的区别是什么？
16、history模式下会出现404，怎么处理？
17、你能说一下闭包的优缺点吗？
18、内存泄漏和内存溢出有什么区别？
19、还有什么想问我的吗？

该岗位是node全栈工程师的岗位，对后端的知识点问题的比较深，一层一层的往下问，我后端的知识点稍微薄弱一些，很多很细的问题答不上来；他那边技术栈用的是react，我复习的知识也比较少。

扑街了理所当然。

五、公司五

1.1、自我介绍？
1.2、常用的选择器有哪些，优先级怎么样？（除了这些还有其他的嘛）
1.3、垂直居中的实现方案有哪些？
2.1、你说的网格布局grid垂直居中有哪些属性值？
2.2、width:100%和width:auto有什么区别？
3、说一下cookie的作用是什么？
4、cookie有哪些属性？
5、设置cookie的domain用来实现什么功能？
6、懒加载的实现原理是怎样的？（除了你说的那一种还有其他的嘛）
7、vue中路由懒加载怎么实现？（除了你说的这一种还有其他的嘛）
8、说一下原型链的理解？
9、原型链__proto__这个隐式属性的实现原理是怎样的？
10、说一下vue中双向数据绑定？
11、vue中computed和watch的区别是什么？
12、说一下你们的前端登录流程是怎样的？
13、jwt是什么？
14、jwt由哪些部分组成？
15、你在项目中怎么实现打包优化的？
16、你说的这些优化方式是webpack哪个版本的？
17、你说一下项目中比较困难的事情有哪些（BFF处理模式）？
18、你们部署上线是怎么做的？
19、在项目中有使用jekenis和docker这些吗？
20、有什么想问我的吗？

我记得网格布局是有justify-content和align-items属性，并且面试之后专门写了一个文件测试，测试通过。面试官说我属性记错了。

width:100%和width:auto有什么区别?这个问题我没回答出来，最后我问面试官他们的区别是什么。面试结束之后我按照他说的那种方式，也没测试出来区别，很纳闷。

原型链__proto__这个隐式属性的实现原理是怎样的？，我以为这个问题就是让我说一下实例.__proto__指向构造函数的原型，抓住这个点然后扩展一下原型链的知识就好了。他说不是要你回答这个，而是让我说一下proto的底层实现，这个问题我不知道，有知道的朋友可以在评论区帮我回复一下，我学习一下这个知识点。

整个面试从面试官的表达上可以看得出来他有一些紧张，导致有一些问题我也听的不是特别清楚。结束之后我测试的几个知识点也没达到他说的效果，遗憾。

最后应该是挂了。

六、公司六

拿到offer，出于公司隐私考虑，不方便透露具体过程。

人事面问题汇总

1、对自己的评价？
2、你有哪些兴趣爱好？
3、描述一下你自己的优缺点?或者用三个词语描述你自己？
4、你在公司主要做一些什么工作？
5、离职原因是什么？
6、在工作之外有哪些学习技术的方式？
7、公司的整个开发流程是怎样的,你跟团队成员如何配合完成任务？
8、你有女(男)朋友了吗(稳定性)？
9、你有其他offer吗(稳定性)？
10、如何提高工作效率? 
11、与领导意见不统一时应该怎么办?
12、你觉得目前自己的技术在什么位置，觉得自己哪一块能力需要加强？
13、您还有什么问题想问我的嘛? 
15、你的职业规划是怎样的? 
16、入职之后如何开展工作? 
17、是否愿意接受加班?
18、你能为公司带来什么?你希望公司给你什么?
19、在项目中遇到了什么难点问题，最后怎么解决的？
20、谈一下你在上一家公司整个技术开发流程，你负责哪些工作？
21、你希望自己以后的发展方向是什么？

知己知彼，从容不迫。

接下来的计划

在这次的面试中，也发现了自己能力的不足。比如我之前通过node写了一些提升团队的工具，用于提升自己在团队中的kpi。但是在纯前端中可能只能作为一家加分项来看，因为如果问到很具体的node的内存问题、mongodb细节的问题，可能就会被问住了，整个面试体验确实会比较糟糕。

C市很多大公司都是用的react，我之前在项目中用react比较少，所以空余时间要把react用起来，不用起来就会忘。

然后vue3的源码和优化的方面也要继续看看了。

还有这一次没有投递大厂的原因是我没有刷算法，这一点在之前的求职过程中都没有重视起来。现在年限到这了，必须要刷起来，才能更进一步提升自己。

给大家的一个建议

我在面试的过程中有一个体会，就是：当面试官问你一个很大的问题的时候，你要怎么回答？

比如面试官问题，简单的跟我说一下继承是什么吧？

很多朋友遇到这样的一个问题，马上就大脑蒙圈了，脑袋里很紊乱，知道很多，但是无法把他们串起来，不知道从何说起，导致回答的结果不是很好。

所以像这些技能题，我们在记笔记的时候也应该用这样的方式去记忆和背诵。遵循下面的几个步骤就行了，套公式的方式，一点也不会慌乱。

1、解释是什么的问题。
2、解释这个技术的应用点、应用场景在哪里。
3、整理一下这个问题的优缺点是什么。

我举一个例子来回答一下。比如面试官问：你给我讲一下闭包吧？

我就可以按照上面的归纳，分3步走的原则。

1. 闭包是：能够访问其他函数内部变量的函数。
2. 闭包一般会在：封装模块的时候，通过函数自执行函数的方式进行实现；或者在模仿块级作用域的时候实现；如：我们常用的库jQuery本身就是一个大的闭包。
3. 闭包的优点是：
    a、能够在离开函数之后继续访问该函数的变量，变量一直保存在内存中。
    b、闭包中的变量是私有的，只有闭包函数才有权限访问它。不会被外面的变量和方法给污染。
闭包的缺点是：
    a、会增加对内存的使用量，影响性能。
    b、不正确的使用闭包会造成内存泄漏。

针对上面闭包的回答，可能面试官又会继续问你：内存泄漏是什么啊，你能给我讲一下吗？垃圾回收机制说一下吧？内存泄漏和内存溢出的区别是什么？等等。

就是你回答完了这个问题之后，你可以先假设性的想一下面试官看到你的这个回答可能会问你什么。然后给自己提问深挖技术深度问题。

当然那不光是面试，自己平时学习深挖知识的时候，也可以用这种办法。

以上这3点，就是我在去年的面试，从自己的真实经历中的总结。

我觉得在求职的时候我遇到的问题，相信很多朋友有类似经历的朋友也会遇到。我就本着造轮子的这个心态，给大家输出一些流程化的经验，希望大家能在本次经济下行，行业萧条的情况下拿到好的结果。

另外，如果你想要更多关于前端方面的成长干货和学习方法与资料，欢迎你关注我这个账号「程序员摩根」，并且私信我。

里面有我最宝贵的私人学习经验，全都毫无保留分享给你，比如优质的前端编程类电子书，前端学习地图，前端入门到精通的学习路径、面试题等。

我的总结

去年10月份之后，整个面试下来，能明显感觉到整个市场的供需关系发生了变化。经过这一轮的洗刷之后，对整个前端求职者的深度、专业度一定会更上一个台阶。

所以在没找到更好的收入方式之前，刷题刷经验，技术上做精做深，这些事情还是需要重复做，认真做。

当然，即使在比较惨烈的市场环境下，我依然认为每个个体都有很大机会的。

我是个乐观主义者，积小胜为大胜。打能胜的仗，才能打胜仗。与各位共勉。

当然，这是我去年10月份的求职情况，今年的情况是否比去年年底还要更惨烈。我没有进入到实际的市场环境中体会。

希望还在求职的朋友们能在底部@我一下，跟大家分享一下目前你所在城市的前端求职现状，大家群策群力，一起商量下应对方法。

欢迎大家在评论区讨论一下。

如果这篇文档对你有帮助，欢迎点赞、关注或者在评论区留言，我会第一时间对你的认可进行回应。精彩内容在后面，防止跑丢，友友们可以先关注我，每一篇文章都能及时通知不会遗失。

作者：程序员摩根
来源：https://juejin.cn/post/7201491839815139389

现状

我记得去年脉脉的论调还都是 客户端已死，前后端还都是一片祥和，有秀工资的，有咨询客户端转前端的，怎么最近打开脉脉一看，风向变了？

随便刷几下，出来的信息都是 前端已死，这种悲观信息，还有失业找不到工作的。

思考

我有时候会想，开源是个好东西，拉低了技术的门槛，好像再难的需求，只要善用搜索引擎，都能找到前人喂到嘴边的答案，如果没有开源文化，甚至自己能不能进入互联网开发行业都不好说。

记得那一年：

我第一次接触技术领域，开始在百度输入前端开发相关的问题，发现出来的结果都是 csdn、博客园、简书等网站的内容，打开了新天地，我开始吸取前辈们的经验和心得，他们分享的各种书上学不到的知识让我解决了工作中遇到的各种问题，让我感叹 开源真好；

我发现程序员们都推崇谷歌搜索和谷歌浏览器，于是自己也开始使用，发现 真香；

我日夜沉迷在技术研究上，为自己找到了一份兴趣爱好和职业相结合的工作而庆幸和兴奋；

大佬们都说要追求 高复用、高内聚、低耦合、易拓展，于是我忙不停蹄的学习这些概念和应用实践；

后来社区开始讨论 低代码，自动化，人工智能，大家好像都蛮兴奋的；

后来听说 客户端开发 不行了，小程序、h5 分走了大量的市场需求，我很庆幸，当初选择了前端，但我隐隐有些不安，因为我发现自己达到了 瓶颈，从业务开发中已经难有太多的技术提升了；

我开始学习 Java, springboot + mysql + mybatisPlus 做了一些简单的 crud，貌似并不是很难，我又有了些自信，以后前端干不了了，还可以搞后端；

我相信 如果一种思想不能拿出来给公众思辨，那么它和不存在没什么两样，所以我开始写博客，我认为这是最好的学习方式，但是我还不太擅长，22年一年才写了20+篇；

然后 chatGPT 出来了，我注册体验了一番，它真的可以在很多场景下协助我提升效率，这点资本也看得到，所以直接后果就是市场可能不需要那么多 开发者了, 这不局限在前端，甚至 chatGPT 更擅长写后端代码；

最后，互联网市场已进入红海之争了，存量市场下，开源节流是正常的操作，去年就经常看到外国各大大厂裁员的消息，国内就更不可能独善其身了；

总结

若没有开源文化，会不会互联网开发，也是一个越老越吃香的职业呢 [微笑]？我不知道，我是开源的受益者，我也愿意为开源做贡献，但是我不会期待它能给我带来多大的商业收益了，开源和商业付费之间，是两种文化之争；

最近core-js 作者对开源社区的“控诉”更是印证了我的看法： core-js 作者快被缺钱“拖垮”了：全职做开源维护 9 年，月均收入从 2500 美元锐减到 400 美元

前端已死 更多的是一种焦虑情绪的表达，市场确实不太好，但这并不是针对前端，整个互联网行业衰败的表现而已，对此持不同意见的怕是只剩培训机构了吧；

前端老鸟，市场还是需要和欠缺的，只是对于初中级前端太卷了，我建议应届生不要继续入门前端了，搞搞嵌入式开发，或者芯片之类的，门槛高一些。

总之，不用过于悲观，互联网风口过去了，还会有下一个风口，比如 web3, 人工智能，都可能带来新的市场机会，作为时代前沿的参与者，程序员因该更容易抓住这样的机会吧。

作者：Ethan_Zhou
来源：juejin.cn/post/7201047960826052667