前端开发面试如何答题才能让面试官满意

浏览器的主要组成部分

• ⽤户界⾯ 包括地址栏、前进/后退按钮、书签菜单等。除了浏览器主窗⼝显示的您请求的⻚⾯外，其他显示的各个部分都属于⽤户界⾯。
• 浏览器引擎 在⽤户界⾯和呈现引擎之间传送指令。
• 呈现引擎 负责显示请求的内容。如果请求的内容是 HTML，它就负责解析 HTML 和 CSS 内容，并将解析后的内容显示在屏幕上。
• ⽹络 ⽤于⽹络调⽤，⽐如 HTTP 请求。其接⼝与平台⽆关，并为所有平台提供底层实现。
• ⽤户界⾯后端 ⽤于绘制基本的窗⼝⼩部件，⽐如组合框和窗⼝。其公开了与平台⽆关的通⽤接⼝，⽽在底层使⽤操作系统的⽤户界⾯⽅法。
• JavaScript 解释器。⽤于解析和执⾏ JavaScript 代码。
• 数据存储 这是持久层。浏览器需要在硬盘上保存各种数据，例如 Cookie。新的 HTML 规范 (HTML5) 定义了“⽹络数据库”，这是⼀个完整（但是轻便）的浏览器内数据库。

值得注意的是，和⼤多数浏览器不同，Chrome 浏览器的每个标签⻚都分别对应⼀个呈现引擎实例。每个标签⻚都是⼀个独⽴的进程。

webpack配置入口出口

module.exports={
    //入口文件的配置项
    entry:{},
    //出口文件的配置项
    output:{},
    //模块：例如解读CSS,图片如何转换，压缩
    module:{},
    //插件，用于生产模版和各项功能
    plugins:[],
    //配置webpack开发服务功能
    devServer:{}
}
简单描述了一下这几个属性是干什么的。
描述一下npm run dev / npm run build执行的是哪些文件
通过配置proxyTable来达到开发环境跨域的问题，然后又可以扩展和他聊聊跨域的产生，如何跨域
最后可以在聊聊webpack的优化，例如babel-loader的优化，gzip压缩等等

前端进阶面试题详细解答

img的srcset属性的作⽤？

响应式页面中经常用到根据屏幕密度设置不同的图片。这时就用到了 img 标签的srcset属性。srcset属性用于设置不同屏幕密度下，img 会自动加载不同的图片。用法如下：

<img src="image-128.png" srcset="image-256.png 2x" />

使用上面的代码，就能实现在屏幕密度为1x的情况下加载image-128.png, 屏幕密度为2x时加载image-256.png。

按照上面的实现，不同的屏幕密度都要设置图片地址，目前的屏幕密度有1x,2x,3x,4x四种，如果每一个图片都设置4张图片，加载就会很慢。所以就有了新的srcset标准。代码如下：

<img src="image-128.png"
     srcset="image-128.png 128w, image-256.png 256w, image-512.png 512w"
     sizes="(max-width: 360px) 340px, 128px" />

其中srcset指定图片的地址和对应的图片质量。sizes用来设置图片的尺寸零界点。对于 srcset 中的 w 单位，可以理解成图片质量。如果可视区域小于这个质量的值，就可以使用。浏览器会自动选择一个最小的可用图片。

sizes语法如下：

sizes="[media query] [length], [media query] [length] ... "

sizes就是指默认显示128px, 如果视区宽度大于360px, 则显示340px。

setState

在了解setState之前，我们先来简单了解下 React 一个包装结构: Transaction:

事务 (Transaction)

是 React 中的一个调用结构，用于包装一个方法，结构为: initialize - perform(method) - close。通过事务，可以统一管理一个方法的开始与结束；处于事务流中，表示进程正在执行一些操作

• setState: React 中用于修改状态，更新视图。它具有以下特点:

异步与同步: setState并不是单纯的异步或同步，这其实与调用时的环境相关:

• 在合成事件 和 生命周期钩子 (除 componentDidUpdate) 中，setState是"异步"的；
  • 原因: 因为在setState的实现中，有一个判断: 当更新策略正在事务流的执行中时，该组件更新会被推入dirtyComponents队列中等待执行；否则，开始执行batchedUpdates队列更新；
    • 在生命周期钩子调用中，更新策略都处于更新之前，组件仍处于事务流中，而componentDidUpdate是在更新之后，此时组件已经不在事务流中了，因此则会同步执行；
    • 在合成事件中，React 是基于 事务流完成的事件委托机制 实现，也是处于事务流中；
  • 问题: 无法在setState后马上从this.state上获取更新后的值。
  • 解决: 如果需要马上同步去获取新值，setState其实是可以传入第二个参数的。setState(updater, callback)，在回调中即可获取最新值；
• 在 原生事件 和 setTimeout 中，setState是同步的，可以马上获取更新后的值；
  • 原因: 原生事件是浏览器本身的实现，与事务流无关，自然是同步；而setTimeout是放置于定时器线程中延后执行，此时事务流已结束，因此也是同步；
• 批量更新 : 在 合成事件 和 生命周期钩子 中，setState更新队列时，存储的是 合并状态(Object.assign)。因此前面设置的 key 值会被后面所覆盖，最终只会执行一次更新；
• 函数式 : 由于 Fiber 及 合并 的问题，官方推荐可以传入 函数 的形式。setState(fn)，在fn中返回新的state对象即可，例如this.setState((state, props) => newState)；
  • 使用函数式，可以用于避免setState的批量更新的逻辑，传入的函数将会被 顺序调用；

注意事项:

• setState 合并，在 合成事件 和 生命周期钩子 中多次连续调用会被优化为一次；
• 当组件已被销毁，如果再次调用setState，React 会报错警告，通常有两种解决办法
  • 将数据挂载到外部，通过 props 传入，如放到 Redux 或 父级中；
  • 在组件内部维护一个状态量 (isUnmounted)，componentWillUnmount中标记为 true，在setState前进行判断；

总结

setState 并非真异步，只是看上去像异步。在源码中，通过 isBatchingUpdates 来判断

• setState 是先存进 state 队列还是直接更新，如果值为 true 则执行异步操作，为 false 则直接更新。
• 那么什么情况下 isBatchingUpdates 会为 true 呢？在 React 可以控制的地方，就为 true，比如在 React 生命周期事件和合成事件中，都会走合并操作，延迟更新的策略。
• 但在 React 无法控制的地方，比如原生事件，具体就是在 addEventListener 、setTimeout、setInterval 等事件中，就只能同步更新。

一般认为，做异步设计是为了性能优化、减少渲染次数，React 团队还补充了两点。

• 保持内部一致性。如果将 state 改为同步更新，那尽管 state 的更新是同步的，但是 props不是。
• 启用并发更新，完成异步渲染。

1. setState 只有在 React 自身的合成事件和钩子函数中是异步的，在原生事件和 setTimeout 中都是同步的
2. setState 的异步并不是说内部由异步代码实现，其实本身执行的过程和代码都是同步的，只是合成事件和钩子函数中没法立马拿到更新后的值，形成了所谓的异步。当然可以通过 setState 的第二个参数中的 callback 拿到更新后的结果
3. setState 的批量更新优化也是建立在异步（合成事件、钩子函数）之上的，在原生事件和 setTimeout 中不会批量更新，在异步中如果对同一个值进行多次 setState，setState 的批量更新策略会对其进行覆盖，去最后一次的执行，如果是同时 setState 多个不同的值，在更新时会对其进行合并批量更新

• 合成事件中是异步
• 钩子函数中的是异步
• 原生事件中是同步
• setTimeout中是同步

这是一道经常会出现的 React setState 笔试题：下面的代码输出什么呢？

class Test extends React.Component {
   
  state  = {
   
      count: 0
  };

    componentDidMount() {
   
    this.setState({
   count: this.state.count + 1});
    console.log(this.state.count);

    this.setState({
   count: this.state.count + 1});
    console.log(this.state.count);

    setTimeout(() => {
   
      this.setState({
   count: this.state.count + 1});
      console.log(this.state.count);

      this.setState({
   count: this.state.count + 1});
      console.log(this.state.count);
    }, 0);
  }

  render() {
   
    return null;
  }
};

我们可以进行如下的分析：

• 首先第一次和第二次的 console.log，都在 React 的生命周期事件中，所以是异步的处理方式，则输出都为 0；
• 而在 setTimeout 中的 console.log 处于原生事件中，所以会同步的处理再输出结果，但需要注意，虽然 count 在前面经过了两次的 this.state.count + 1，但是每次获取的 this.state.count 都是初始化时的值，也就是 0；
• 所以此时 count 是 1，那么后续在 setTimeout中的输出则是 2 和 3。

所以完整答案是 0,0,2,3

同步场景

异步场景中的案例使我们建立了这样一个认知：setState 是异步的，但下面这个案例又会颠覆你的认知。如果我们将 setState 放在 setTimeout 事件中，那情况就完全不同了。

class Test extends Component {
   
    state = {
   
        count: 0
    }

    componentDidMount(){
   
        this.setState({
    count: this.state.count + 1 });
        console.log(this.state.count);
        setTimeout(() => {
   
          this.setState({
    count: this.state.count + 1 });
          console.log("setTimeout: " + this.state.count);
        }, 0);
    }

    render(){
   
        ...
    }
}

那这时输出的应该是什么呢？如果你认为是 0,0，那么又错了。

正确的结果是 0,2。因为 setState 并不是真正的异步函数，它实际上是通过队列延迟执行操作实现的，通过 isBatchingUpdates 来判断 setState 是先存进 state 队列还是直接更新。值为 true 则执行异步操作，false 则直接同步更新

接下来这个案例的答案是什么呢

class Test extends Component {
   
    state = {
   
        count: 0
    }

    componentDidMount(){
   
        this.setState({
   
           count: this.state.count + 1
         },