浏览器内核

说明一：

  • IE 浏览器：Trident（IE 内核）
  • 火狐浏览器：Gecko，特点是代码完全公开
  • Opera 浏览器：前期采用 Presto 内核，现已改用 Google Chrome 的 Blink 内核
  • Safari 浏览器：Webkit 内核，Webkit 内核是 Chrome 内核的原型
  • Chrome 浏览器：采用 Blink 内核，是 Google 和 Opera Software 开发的浏览器排版引擎

说明二：

  • Trident 内核：IE，MaxThon，TT，The World，360，搜狗浏览器等 [又称 MSHTML]
  • Gecko 内核：Netscape6 及以上版本，FF，MozillaSuite / SeaMonkey 等
  • Presto 内核：Opera7 及以上 [Opera 内核原为：Presto，现为：Blink]
  • Webkit 内核：Safari，Chrome等 [Chrome 的：Blink（WebKit 的分支）]

详细文章：传送门

介绍一下你对浏览器内核的理解？

主要分成两部分：渲染引擎（layout engineer 或 Rendering Engine）和 JS 引擎

渲染引擎：负责取得网页的内容（HTML、XML、图像等等）、整理讯息（例如加入 CSS 等），以及计算网页的显示方式，然后会输出至显示器或打印机。浏览器的内核的不同对于网页的语法解释会有不同，所以渲染的效果也不相同。所有网页浏览器、电子邮件客户端以及其它需要编辑、显示网络内容的应用程序都需要内核

JS 引擎则：解析和执行 javascript 来实现网页的动态效果

最开始渲染引擎和 JS 引擎并没有区分的很明确，后来 JS 引擎越来越独立，内核就倾向于只指渲染引擎

IE6 BUG 的解决方法

  • 由 float 引起的双边距 BUG，使用 display 解决
  • 由 float 引起的 3 像素问题，使用 display: inline -3px
  • 超链接 hover 点击后失效，使用正确的书写顺序 link visited hover active
  • IE z-index 问题，给父级添加 position: relative
  • png 透明，使用 js 代码进行修改
  • min-height 最小高度，使用 !important 解决
  • select 在 IE6 下遮盖，使用 iframe 嵌套
  • 为什么没有办法定义 1px 左右的宽度容器，是由 IE6 默认的行高造成的，使用样式 overflow: hidden, zoom: 0.08; line-height: 1px; 解决

React 的特点

  • 声明式设计
  • 高效：通过对 DOM 的模拟，最大限度的减少与 DOM 的交互
  • 灵活：可以与已知的框架或库很好的配合
  • JSX：是 js 语法的扩展，不一定使用，但建议用
  • 组件：构建组件，使代码更容易得到复用，能够很好地应用在大项目的开发中
  • 单向响应的数据流：React 实现了单向响应的数据流，从而减少了重复代码，这也是解释了它为什么比传统数据绑定更简单

Vue 的特性

  • 轻量级框架
  • MVVM 框架
  • 数据驱动
  • 组件化
  • 双向数据绑定
  • 指令
  • 插件化
  • 轻量、简洁、高效、快速、模块友好

Bootstrap 的特点

  • 跨设备、跨浏览器，可以兼容所有现在浏览器，包括比较诟病的 IE7、8
  • 响应式布局，不但支持 PC 端的各种分辨率，还支持移动端 pad，手机等屏幕的响应式切换显示
  • 提供全面的组件，Bootstrap 提供了实用性很强的组件，包括：导航、标签、工具条、按钮等
  • 内置 jquery 插件
  • 支持 HTML5、CSS3
  • 支持 less 动态样式

Node

Node 的使用场景：高并发、聊天、实时消息推送

性能优化的方法

  • 减少 http 请求次数：CSS、JS 等源码压缩，图片大小控制合适，data 缓存，图片服务器
  • 前端模版 JS + 数据，较少由于 HTML 标签导致的带宽浪费，前端用变量保存 ajax 请求结果，每次操作本地变量，不用请求，减少请求次数
  • 用 innerHTML 代替 DOM 操作，减少 DOM 操作次数，优化 JS 性能
  • 当需要设置的样式很多时设置 className，而不是直接操作 style
  • 少用全局变量、缓存 DOM 节点查找的结果，减少 IO 读取操作
  • 避免使用 CSS Expression（css 表达式），又称动态属性
  • 图片预加载，将样式表放在顶部，将脚本放在底部，加上时间戳
  • 避免在页面的主体布局中使用 table，table 要等其中的内容完全下载之后才会显示出来，显示效率慢

前端优化

在不影响功能和体验的情况下

能在浏览器执行的不要在服务器执行

能在缓存服务器上直接返回的不要到应用服务器

程序能直接取得结果的不要到外部取得

本机内能取得的数据不要到远程取

内存能取到的不要到磁盘取

缓存中有的数据不要去数据库查询

一个页面从输入 URL 到页面加载显示完成，这个过程中都发生了什么

  • 查找浏览器缓存
  • DNS 解析、查找该域名对应的 IP 地址、重定向（301）、发出第二个 GET 请求
  • 进行 HTTP 协议会话
  • 客户端发送报头（请求报头）
  • 文档开始下载
  • 文档树建立，根据标记请求所需指定 MIME 类型的文件
  • 文件显示

浏览器这边做的工作大致分为以下几步

  • 加载：根据请求的 URL 进行域名解析，向服务器发起请求，接收文件（HTML、JS、CSS、图象等）
  • 解析：对加载到的资源（HTML、JS、CSS 等）进行语法解析，建议相应的内部数据结构（比如 HTML 的 DOM 树，JS 的（对象）属性表，CSS 的样式规则等等）

Vue 和 AngularJS 的异同

相同点

  • 都支持指令：内置指令和自定义指令
  • 都支持过滤器：内置过滤器和自定义过滤器
  • 都支持双向数据绑定
  • 都不支持低端浏览器

不同点

  • AngularJS 的学习成本高
  • 在性能上，AngularJS 依赖对数据做脏检查，所以 Watcher 越多越慢

Vue 和 React 的异同

相同点

  • React 采用特殊的 JSX 语法，Vue 在组件开发中也推崇编写 .vue 特殊文件格式，对文件内容有一定的约定，两者都需要编译后使用
  • 二者的中心思想都是一切都是组件，组件实例之间可以嵌套
  • 都提供合理的钩子函数，可以让开发者定制化地去处理需求
  • 都不内置 Ajax、Route 等功能到核心包，而是以插件的方式加载
  • 组件开发中都支持 mixins 的特性

不同点

  • React 依赖 virtual DOM，而 Vue 使用的是 DOM 模版，React 采用的 virtual DOM 会对渲染出来的结果做脏检查
  • Vue 在模板中提供了指令，过滤器等，可以非常方便、快捷的操作 DOM

Vue 生命周期

如下图所示

Vue 生命周期

React 生命周期

实例化

首次实例化

  • getDefaultProps
  • getInitialState
  • componentWillMount
  • render
  • componentDidMount

实例化完成后的更新

  • getInitialState
  • componentWillMount
  • render
  • componentDidMount
存在期

组件已存在时的状态改变

  • componentWillReceiveProps
  • shouldComponentUpdate
  • componentWillUpdate
  • render
  • componentDidUpdate

销毁 & 清理期

  • componentWillUnmount
说明

生命周期共提供了 10 个不同的 API

  • getDefaultProps

作用于组件类，只调用一次，返回对象用于设置默认的 props，对于引用值，会在实例中共享

  • getInitialState

作用于组件的实例，在实例创建时调用一次，用于初始化每个实例的 state，此时可以访问 this.props

  • componentWillMount

在完成首次渲染之前调用，此时仍可以修改组件的 state

  • render

必选的方法，创建虚拟 DOM，该方法具有特殊的规则

  • 只能通过 this.props 和 this.state 访问数据
  • 可以返回 null、false 或任何 React 组件
  • 只能出现一个顶级组件（不能返回数组）
  • 不能改变组件的状态

  • 不能修改 DOM 的输出

  • componentDidMount

真实的 DOM 被渲染出来后调用，在该方法中可通过 this.getDOMNode() 访问到真实的 DOM 元素。此时已可以使用其他类库来操作这个 DOM

在服务端中，该方法不会被调用

  • componentWillReceiveProps

组件接收到新的 props 时调用，并将其作为参数 nextProps 使用，此时可以更改组件 props 及 state

componentWillReceiveProps: function(nextProps) {
  if (nextProps.bool) {
    this.setState({
      bool: true
    });
  }
}
  • shouldComponentUpdate

组件是否应当渲染新的 props 或 state，返回 false 表示跳过后续的生命周期方法，通常不需要使用以避免出现 bug。在出现应用的瓶颈时，可通过该方法进行适当的优化

在首次渲染期间或者调用了 forceUpdate 方法后，该方法不会被调用

  • componentWillUpdate

接收到新的 props 或者 state 后，进行渲染之前调用，此时不允许更新 props 或 state

  • componentDidUpdate

完成渲染新的 props 或者 state 后调用，此时可以访问到新的 DOM 元素

  • componentWillUnmount

组件被移除之前被调用，可以用于做一些清理工作，在 componentDidMount 方法中添加的所有任务都需要在该方法中撤销，比如创建的定时器或添加的事件监听器

请描述一下 cookies，sessionStorage 和 localStorage 的区别？

cookie 是网站为了标示用户身份而储存在用户本地终端（Client Side）上的数据（通常经过加密）

cookie 数据始终在同源的 http 请求中携带（即使不需要），记会在浏览器和服务器间来回传递

sessionStorage 和 localStorage 不会自动把数据发给服务器，仅在本地保存

存储大小：

  • cookie 数据大小不能超过 4k
  • sessionStorage 和 localStorage 虽然也有存储大小的限制，但比 cookie 大得多，可以达到 5M 或更大

有期时间：

  • localStorage 存储持久数据，浏览器关闭后数据不丢失除非主动删除数据
  • sessionStorage 数据在当前浏览器窗口关闭后自动删除
  • cookie 设置的 cookie 过期时间之前一直有效，即使窗口或浏览器关闭

什么是 Quirks 模式

简单来说，Quirks Mode 就是浏览器为了兼容很早之前针对旧版本浏览器设计、并未严格遵循 W3C 标准的网页而产生的一种页面渲染模式

Quirks Mode 是一种浏览器（像 IE，Firefox，Opera）操作模式。 从根本上说，怪异模式（也称之为兼容模式）意味着一个相对新的浏览器故意模拟许多在旧浏览器中存在的 bug，特别是在 IE4 和 IE5 中

更多可以查看 传送门

如何实现浏览器内多个标签页之间的通信?（阿里）

WebSocket、SharedWorker

也可以调用 localstorge、cookies 等本地存储方式

localstorge 另一个浏览上下文里被添加、修改或删除时，它都会触发一个事件

我们通过监听事件，控制它的值来进行页面信息通信

注意 Quirks（怪癖模式，诡异模式，怪异模式）：Safari 在无痕模式下设置 localstorge 值时会抛出 QuotaExceededError 的异常

webSocket 如何兼容低浏览器？（阿里）

  • Adobe Flash Socket
  • ActiveX HTMLFile（IE）
  • 基于 multipart 编码发送 XHR
  • 基于长轮询的 XHR

如何在页面上实现一个圆形的可点击区域？

  • map + area 或者 svg
  • border-radius
  • 纯 js 实现 需要求一个点在不在圆上简单算法、获取鼠标坐标等等

网页验证码是干嘛的，是为了解决什么安全问题

区分用户是计算机还是人的公共全自动程序。可以防止恶意破解密码、刷票、论坛灌水

有效防止黑客对某一个特定注册用户用特定程序暴力破解方式进行不断的登陆尝试

前端框架

React 使用场景？

逻辑复杂单页应用，偏中后台管理系统，纯展示性的 UI 页面不合适的时候使用 React

描述一下 React 生命周期

渲染过程调用到的生命周期函数，主要几个要知道

  • constructor
  • getInitialState
  • getDefaultProps
  • componentWillMount
  • render
  • componentDidMount

更新过程

  • componentWillReceiveProps
  • shouldComponentUpdate
  • componentWillUpdate
  • render
  • componentDidUpdate

卸载过程

  • componentWillUnmount

实现组件有哪些方式？

  • React.createClass 使用 API 来定义组件
  • React ES6 class component 用 ES6 的 class 来定义组件
  • Functional stateless component 通过函数定义无状态组件

应该在 React 生命周期的什么阶段发出 Ajax 请求，为什么？

Ajax 请求应在 componentDidMount 函数中进行请求

shouldComponentUpdate 函数有什么作用？

shouldComponentUpdate 是一个允许我们自行决定某些组件（以及他们的子组件）是否进行更新的生命周期函数，reconciliation 的最终目的是尽可能以最有效的方式去根据新的 state 更新 UI

如果你已经知道 UI 的哪些状态无需进行改变，就没必要去让 React 去判断它是否该改变。让 shouldComponentUpdate 返回 false, React 就会让当前的组件和其子组件保持不变

当组件的 setState 函数被调用之后，发生了什么？

React 会做的第一件事就是把你传递给 setState 的参数对象合并到组件原先的 state。这个事件会导致一个 reconciliation（调和）的过程。reconciliation 的最终目标就是，尽可能以最高效的方法，去基于新的 state 来更新 UI。为了达到这个目的，React 会构建一个 React 元素树（你可以把这个想象成一个表示 UI 的一个对象）。一旦这个树构建完毕，React 为了根据新的 state 去决定 UI 要怎么进行改变，它会找出这棵新树和旧树的不同之处。React 能够相对精确地找出哪些位置发生了改变以及如何发生了什么变化，并且知道如何只通过必要的更新来最小化重渲染

为什么循环产生的组件中要利用上 key 这个特殊的 prop？

keys 负责帮助 React 跟踪列表中哪些元素被改变 / 添加 / 移除。React 利用子元素的 key 在比较两棵树的时候，快速得知一个元素是新的还是刚刚被移除。没有 keys，React 也就不知道当前哪一个的 item 被移除了

refs 是什么？

Refs 是能访问 DOM 元素或组件实例的一个函数

什么时候应该选择用 class 实现一个组件，什么时候用一个函数实现一个组件？

组件用到了 state 或者用了生命周期函数，那么就该使用 Class component。其他情况下，应使用 Functional component

并不是父子关系的组件，如何实现相互的数据通信？

使用父组件，通过 props 将变量传入子组件（如通过 refs，父组件获取一个子组件的方法，简单包装后，将包装后的方法通过 props 传入另一个子组件）

用过 React 技术栈中哪些数据流管理库？

Redux、Dva、mobx 等

页面重构怎么操作？

网站重构：在不改变外部行为的前提下，简化结构、添加可读性，而在网站前端保持一致的行为

也就是说是在不改变 UI 的情况下，对网站进行优化，在扩展的同时保持一致的 UI

对于传统的网站来说重构通常是：

  • 表格（table）布局改为 DIV + CSS
  • 使网站前端兼容于现代浏览器（针对于不合规范的 CSS、如对 IE6 有效的兼容）
  • 对于移动平台的优化
  • 针对于 SEO 进行优化
  • 深层次的网站重构应该考虑的方面
  • 减少代码间的耦合
  • 让代码保持弹性
  • 严格按规范编写代码
  • 设计可扩展的 API
  • 代替旧有的框架、语言（如 VB）
  • 增强用户体验
  • 通常来说对于速度的优化也包含在重构中
  • 压缩 JS、CSS、image 等前端资源（通常是由服务器来解决）
  • 程序的性能优化（如数据读写）
  • 采用 CDN 来加速资源加载
  • 对于 JS DOM 的优化
  • HTTP 服务器的文件缓存

什么叫优雅降级和渐进增强？

优雅降级：Web 站点在所有新式浏览器中都能正常工作，如果用户使用的是老式浏览器，则代码会针对旧版本的 IE 进行降级处理了，使之在旧式浏览器上以某种形式降级体验却不至于完全不能用，如：border-shadow

渐进增强：从被所有浏览器支持的基本功能开始，逐步地添加那些只有新版本浏览器才支持的功能，向页面增加不影响基础浏览器的额外样式和功能的。当浏览器支持时，它们会自动地呈现出来并发挥作用。如：默认使用 flash 上传，但如果浏览器支持 HTML5 的文件上传功能，则使用 HTML5 实现更好的体验

是否了解公钥加密和私钥加密

一般情况下是指私钥用于对数据进行签名，公钥用于对签名进行验证

HTTP 网站在浏览器端用公钥加密敏感数据，然后在服务器端再用私钥解密

WEB 应用从服务器主动推送 Data 到客户端有那些方式？

  • HTML5 提供的 Websocket
  • 不可见的 iframe
  • WebSocket 通过 Flash
  • XHR 长时间连接
  • XHR Multipart Streaming
  • <script>标签的长时间连接（可跨域）

对 Node 的优点和缺点提出了自己的看法？

  • 优点：因为 Node 是基于事件驱动和无阻塞的，所以非常适合处理并发请求，因此构建在 Node 上的代理服务器相比其他技术实现（如 Ruby）的服务器表现要好得多。此外，与 Node 代理服务器交互的客户端代码是由 Javascript 语言编写的，因此客户端和服务器端都用同一种语言编写，这是非常美妙的事情

  • 缺点：Node 是一个相对新的开源项目，所以不太稳定，它总是一直在变，而且缺少足够多的第三方库支持。看起来，就像是 Ruby/Rails 当年的样子

你有用过哪些前端性能优化的方法？

  • 减少 http 请求次数：CSS Sprites，JS、CSS 源码压缩、图片大小控制合适；网页 Gzip，CDN 托管，data 缓存，图片服务器
  • 前端模板 + JS + 数据，减少由于 HTML 标签导致的带宽浪费，前端用变量保存 AJAX 请求结果，每次操作本地变量，不用请求，减少请求次数
  • 用 innerHTML 代替 DOM 操作，减少 DOM 操作次数，优化 Javascript 性能
  • 当需要设置的样式很多时设置 className 而不是直接操作 style
  • 少用全局变量、缓存 DOM 节点查找的结果。减少 IO 读取操作
  • 避免使用 CSS Expression（css 表达式)，又称 Dynamic properties（动态属性）
  • 图片预加载，将样式表放在顶部，将脚本放在底部，加上时间戳
  • 避免在页面的主体布局中使用 table，table 要等其中的内容完全下载之后才会显示出来，显示比 div + css 布局慢

对普通的网站有一个统一的思路，就是尽量向前端优化、减少数据库操作、减少磁盘 IO。向前端优化指的是，在不影响功能和体验的情况下，能在浏览器执行的不要在服务端执行，能在缓存服务器上直接返回的不要到应用服务器，程序能直接取得的结果不要到外部取得，本机内能取得的数据不要到远程取，内存能取到的不要到磁盘取，缓存中有的不要去数据库查询。减少数据库操作指减少更新次数、缓存结果减少查询次数、将数据库执行的操作尽可能的让你的程序完成（例如 join 查询），减少磁盘 IO 指尽量不使用文件系统作为缓存、减少读写文件次数等。程序优化永远要优化慢的部分，换语言是无法 “优化” 的

对前端工程师这个职位是怎么样理解的？它的前景会怎么样？

前端是最贴近用户的程序员，比后端、数据库、产品经理、运营、安全都近

  • 实现界面交互
  • 提升用户体验
  • 有了 Node.js，前端可以实现服务端的一些事情

前端是最贴近用户的程序员，前端的能力就是能让产品从 90 分进化到 100 分，甚至更好

  • 参与项目，快速高质量完成实现效果图，精确到 1px
  • 与团队成员，UI 设计，产品经理的沟通
  • 做好的页面结构，页面重构和用户体验
  • 处理 hack，兼容、写出优美的代码格式
  • 针对服务器的优化、拥抱最新前端技术

平时如何管理你的项目？

大致遵循以下几点

  • 先期团队必须确定好全局样式（global.css），编码模式（utf-8）等
  • 编写习惯必须一致（例如都是采用继承式的写法，单样式都写成一行）
  • 标注样式编写人，各模块都及时标注（标注关键样式调用的地方）
  • 页面进行标注（例如 页面 模块 开始和结束）
  • CSS 跟 HTML 分文件夹并行存放，命名都得统一（例如 style.css）
  • JS 分文件夹存放 命名以该 JS 功能为准的英文翻译
  • 图片采用整合的 images.png png8 格式文件使用 尽量整合在一起使用方便将来的管理

移动端（Android IOS）怎么做好用户体验？

  • 清晰的视觉纵线
  • 信息的分组、极致的减法
  • 利用选择代替输入
  • 标签及文字的排布方式
  • 依靠明文确认密码
  • 合理的键盘利用

其他

一些问题，持续更新答案

React-router 路由的实现原理？

React Router 是一个基于 React 之上的强大路由库，它可以让你向应用中快速地添加视图和数据流，同时保持页面与 URL 间的同步。本文从两个方便来解析 react-router 实现原理。一：介绍 react-router 的依赖库 history；二：使用 history 库，实现一个简单的 react-router 路由

history 介绍

history 是一个 JavaScript 库，可让您在 JavaScript 运行的任何地方轻松管理会话历史记录。history 抽象出各种环境中的差异，并提供最小的 API ，使您可以管理历史堆栈，导航，确认导航以及在会话之间保持状态

history 有三种实现方式：

  • BrowserHistory：用于支持 HTML5 历史记录 API 的现代 Web 浏览器（请参阅跨浏览器兼容性）
  • HashHistory：用于旧版 Web 浏览器
  • MemoryHistory：用作参考实现，也可用于非 DOM 环境，如 React Native 或测试

通过 history 实现简单 react-router

看下面的🌰

import { Component } from 'react';
import createHistory from 'history/createHashHistory';
const history = createHistory(); // 创建 history 对象
/**
 * 配置路由表
 * @type {{"/": string}}
 */
const router = {
  '/': 'page/home/index',
  '/my': 'page/my/index'
}
export default class Router extends Component {
  state = { page: null }

  async route(location) {
    let pathname = location.pathname;
    let pagePath = router[pathname];
    // 加 ./的原因 https://webpack.docschina.org/api/module-methods#import-
    const Page = await import(`./${pagePath}`); //获取路由对应的ui
    // 设置 ui
    this.setState({
      Page: Page.default
    });
  }

  initListener() {
    //监听路由切换
    history.listen((location, action) => {
      //切换路由后，更新ui
      this.route(location);
    });
  }

  componentDidMount() {
    this.route(history.location);
    this.initListener();
  }

  render() {
    const { Page } = this.state;
    return Page && <Page {...this.props} />;
  }
}

说说 React Native，Weex 框架的实现原理？

React

  • React 是由 Facebook 推出的一个 JavaScript 框架，主要用于前端开发

  • React 采用组件化方式简化 Web 开发

    • DOM：每个 HTML 界面可以看做一个 DOM
    • 原生的 Web 开发方式，HTML 一个文件，javaScript 一个文件，文件分开，就会导致修改起来比较麻烦
    • 可以把一组相关的 HTML 标签和 JavaScript 单独封装到一个组件类中，便于复用，方便开发

  • React 可以高效的绘制界面

    • 原生的 Web，刷新界面（DOM），需要把整个界面刷新
    • React 只会刷新部分界面，不会整个界面刷新
    • 因为 React 独创了 Virtual DOM 机制。Virtual DOM 是一个存在于内存中的 JavaScript 对象，它与 DOM 是一一对应的关系，当界面发送变化时，React 会利用 DOM Diff 算法，把有变化的 DOM 进行刷新

  • React 是采用 JSX 语法，一种 JS 语法糖，方便快速开发

常见的五种 App 开发模式

常见的开发模式有 5 种（Native App，Web App，Hybrid App，Weex，React Native）

  • Native App

Native App：指使用原生 API 开发 App，比如 iOS 用 OC 语言开发

优点：性能高

缺点：开发维护成本高，养一个原生开发工程师需要很多钱，最重要 iOS 版本更新也成问题

  • Web App

Web App：指使用 HTML 开发的移动端网页 App，类似微信小程序，整个 App 都是网页

优点：用户不需要安装，不会占用手机内存

缺点：用户体验不好，不能离线，必须联网

  • Hybrid App

Hybrid App：混合开发模式，原生 Api + Html 共同开发，比如 iOS，用 html 写好界面，用 UIWebView 展示

优点：界面复用性强，一个界面，iOS 和安卓都可以使用

缺点：相对于原生，性能相对有所损害

  • Weex

Weex：基于 Vue（JS 框架）的语法开发的 App，底层会自动把 JS 代码解析成对应平台（iOS，安卓）的原生 API，本质还是原生 API 开发，只不过表面是用 Vue 开发

优点：可以做到一套代码，跨平台执行，底层会自动判断当前是哪个平台，转换为对应平台的原生 API 代码 缺点：开源较晚，互联网上相关资料还比较少，社区规模较小

  • React Native

React Native：基于 React 开发的 App

优点：

  • 跨平台开发
  • 跳过 App Store 审核，远程更新代码，提高迭代频率和效率，既有 Native 的体验，又保留 React 的开发效率

缺点：对于不熟悉前端开发的人员上手比较慢，不能真正意义上做到跨平台，使用后，对 App 体积增加

相信大多数人了解完 React Native，越来越困惑了，那不是跟 Native 冲突了吗，Native 是用原生 Api 开发，但是 React Native 又是用 React 开发

要想彻底搞明白，需要了解 React Native 底层实现原理

React Native 原理

React Native 原理其实跟 Weex 差不多，底层也会把 React 转换为原生 API

React Native 和 Weex 区别在于跨平台上面，Weex 只要写一套代码，React Native 需要 iOS，安卓都写，说明 React Native 底层解析原生 API 是分开实现的，iOS 一套，安卓一套

具体可以查看 跳转

受控组件（Controlled Component）与非受控组件（Uncontrolled Component）的区别

React 的核心组成之一就是能够维持内部状态的自治组件，不过当我们引入原生的 HTML 表单元素时（input, select, textarea 等），我们是否应该将所有的数据托管到 React 组件中还是将其仍然保留在 DOM 元素中呢？这个问题的答案就是受控组件与非受控组件的定义分割。受控组件（Controlled Component）代指那些交由 React 控制并且所有的表单数据统一存放的组件。譬如下面这段代码中 username 变量值并没有存放到 DOM 元素中，而是存放在组件状态数据中。任何时候我们需要改变 username 变量值时，应当调用 setState 函数进行修改

看下面的🌰

class ControlledForm extends Component {
  state = {
    username: ''
  }
  updateUsername = (e) => {
    this.setState({
      username: e.target.value,
    })
  }
  handleSubmit = () => {}
  render () {
    return (
      <form onSubmit={this.handleSubmit}>
        <input
          type='text'
          value={this.state.username}
          onChange={this.updateUsername} />
        <button type='submit'>Submit</button>
      </form>
    )
  }
}

而非受控组件（Uncontrolled Component）则是由 DOM 存放表单数据，并非存放在 React 组件中。可以使用 refs 来操控 DOM 元素

看下面的🌰

class UnControlledForm extends Component {
  handleSubmit = () => {
    console.log('Input Value: ', this.input.value)
  }
  render () {
    return (
      <form onSubmit={this.handleSubmit}>
        <input
          type='text'
          ref={(input) => this.input = input} />
        <button type='submit'>Submit</button>
      </form>
    )
  }
}

非受控组件看上去更好实现，我们可以直接从 DOM 中抓取数据，而不需要添加额外的代码。不过实际开发中我们并不提倡使用非受控组件，因为实际情况下我们需要更多的考虑表单验证、选择性的开启或者关闭按钮点击、强制输入格式等功能支持，而此时我们将数据托管到 React 中有助于我们更好地以声明式的方式完成这些功能。引入 React 或者其他 MVVM 框架最初的原因就是为了将我们从繁重的直接操作 DOM 中解放出来

具体可以查看 传送门

React 为什么自己定义一套事件体系呢，与浏览器原生事件体系有什么关系？

React Event 的主要四个文件是 ReactBrowerEventEmitter.js（负责节点绑定的回调函数，该回调函数执行过程中构建合成事件对象，获取组件实例的绑定回调并执行，若有 state 变更，则重绘组件），ReactEventListener.js（负责事件注册和事件分发），ReactEventEmitter（负责事件的执行），EventPluginHub.js（负责事件的存储）和 ReactEventEmitterMixin.js

React 的事件机制有 2 个特点

  • 使用事件委托机制，以队列的方式，从触发事件的组件向父组件回溯直到 document 节点，因此 React 组件上声明的事件最终绑定到了 document 上。由此减少了 DOM 操作，优化性能
  • 基于虚拟 DOM 实现 SyntheticEvent 合成事件

具体可以查看 传送门

什么是 HoC（Higher-Order Component）？适用于什么场景？

高阶组件就是一个 React 组件包裹着另外一个 React 组件

简而言之，高阶组件就是一个函数，且该函数接受一个组件作为参数，并返回一个新的组件，即给你一个组件，返回我一个新的组件

const EnhancedComponent = higherOrderComponent(WrappedComponent);

高阶组件的概念非常的简单，使用起来也不是特别难，当然 HOC 可以传入多个参数，当我们有类似的组件，但是数据不同的时候我们就可以使用 HOC 这种形式复用组件

具体可以查看 传送门

Redux 是如何做到可预测呢？

可预测性

Redux 以多种方式提高了 Web 应用程序的可预测性。数据被合并到一个集中的位置：store。 组件不能直接修改 store 中的数据；相反，他们必须请求访问这些数据。此外，store 如何更新也有严格的规定

因此，总是知道状态来自哪里（store），以及允许哪一个唯一实体触发更新（action）到该状态

另一种看待 Redux 的方式是它提供了一个严格的 单向数据流

单向数据流概述

回顾 React 的核心功能之一，单向数据流，如下图所示

React 单向数据流

在上图中，数据存储在父组件中。如果子组件也需要使用该数据，该数据可以向下传递给子组件。任何更新都向上发送给父组件，由父组件做出更新，更新后的数据再向下发送给子组件

React 的单向数据流功能很强大，但是当处理深度嵌套的组件结构时，就会出现问题，对于深度嵌套的组件结构，数据必须途经所有中间组件才能向下传递到目标对象

Redux 以多种方式提高可预测性

  • 它将大多数数据整合到一个位置
  • 组件必须请求访问数据
  • store 中的数据流向一个方向
  • store 更新有着严格的规则

具体可以查看 传送门

Redux 将 React 组件划分为哪两种？

React-Redux 将所有组件分成两大类：UI 组件（presentational component）和容器组件（container component）

UI 组件有以下几个特征

  • 只负责 UI 的呈现，不带有任何业务逻辑
  • 没有状态（即不使用 this.state 这个变量）
  • 所有数据都由参数（this.props）提供
  • 不使用任何 Redux 的 API

容器组件的特征恰恰相反

  • 负责管理数据和业务逻辑，不负责 UI 的呈现
  • 带有内部状态
  • 使用 Redux 的 API

总之，只要记住一句话就可以了：UI 组件负责 UI 的呈现，容器组件负责管理数据和逻辑

React-Redux 规定，所有的 UI 组件都由用户提供，容器组件则是由 React-Redux 自动生成。也就是说，用户负责视觉层，状态管理则是全部交给它

具体可以参考 传送门

Redux 是如何将 state 注入到 React 组件上的？

具体可以参考 传送门

请描述一次完整的 Redux 数据流

  • 添加 Action，注意参数类型
  • saga 处理异步请求，分别产生请求成功和失败的 Action
  • reducer 根据事件名称，返回不同值
  • 具体页面，调用 Action

具体可以参考 传送门 1 传送门 2

React 的批量更新机制 BatchUpdates？

具体可以参考 传送门

React 与 Vue，各自的组件更新进行对比，它们有哪些区别？

React 组件的属性

React 是一个单纯的 view 层框架，官方推荐使用 JSX 预发来维护组件的状态。通过 Props 和 state 来共同决定组件的表现

  • Props，正如 prop 的英文意思[属性]一样，Props 中的数据主要用来定义和描述组件的属性，该数据是由父组件在声明 React 组件的时候设置，就好比我们给一个 img 标签设置一个 src 属性一样，我们可以给自定义的 React 组件设置许多属性。这些属性定义了 React 组件的表现形式，父组件可以通过修改 Props 中的属性来控制子组件的表现
  • state，同样的，state 表示[状态]，那么 state 中的数据主要用来控制组件内部的状态。也就是说组件内部的变化，不需要同外部有交互的数据，都可以由组件自己通过 state 来控制

React 虚拟树更新原则

React 中应用虚拟 DOM 来更新快速更新 DOM，那么更新虚拟 DOM 的原则主要是以下几种：

  • 不同元素，如果更新前后是两种不同类型的 DOM 元素，那就没什么说的，直接销毁原来的节点，创建新的节点。（比如原来是 div，更新为 span）在这个过程中，原来节点的 componentWillUnmount 函数被触犯，新节点的 componentWillMount 和 componentDidMount 依次被触发。需要特别指出的是，当前更新节点的所有子节点都会被销毁重建，而不管子节点是否有更新。简单的来说，就是根变了，那么这个根上的所有叶子都要更新了
  • 相同元素，不同属性，当节点类型没有发生变化，而只是熟悉变化的话，React 就智能多了，只会更新变化的部分。好比是一个元素有多个 CSS 样式，如果只变化了一个样式，那么 React 也只更新一个。当元素不是叶子节点的时候，也就是一个组件元素的时候，会继续深入的去比较子元素来更新子元素
  • 子元素变动，当子元素有变动的时候，React 会更新子元素。子元素的变动指的是资源的类型 / 属性 / 位置等的变动。类型和属性的变动会触发更新，这个比较好理解。子元素的位置变动，指的是如果一个资源原来在第一位，更新后到第二位了，React 会认为这是一种变动，从而触发更新
  • key 属性的重要作用 这样看起来 React 也没有那么智能。那么这个时候就要引入一个很重要的 key 属性，React 通过给子组件一个 key 属性。来唯一标识一个子组件，如果更新前后的组件 key 值一样，并且除了位置之外其他属性没有变化，那么就不会触发更新

Vue 的数据

Vue 是一个传统意义上的 mvc 模型。通过实例化一个 vue 对象来绑定 dom 和 data 的关系，也就是绑定 view 和 model。通过对 model 中每个属性添加[反射]来完成监视器的注册。当 model 中的数据模型变化时，watcher 会重新计算，从而引发 view 层的更新

这也就是理解了为什么 Vue 是单向数据流了

Vue 的更新

上面提到，vue 的更新是 model 中数据的变化引发在初始化时注入的 watcher 的变化，从而引起 view 层的更新。只要观察到数据变化，Vue 将开启一个队列，并缓冲在同一事件循环中发生的所有数据改变。如果同一个 watcher 被多次触发，只会一次推入到队列中

根据以上特点，我们知道 vue 中的组件更新是有 model 数据的更新引起的，因为 view 和 model 在初始化时已经完成绑定，所以当 model 发生变化时，哪些 view 需要变化已经很明确了，所以就不需要像 React 那般去判断比对了

具体可以参考

传送门 1

传送门 2

传送门 3

设计模式 知道什么是 singleton, factory, strategy, decrator 么？

设计模式主要分三个类型：创建型、结构型和行为型

其中创建型有

  • Singleton，单例模式：保证一个类只有一个实例，并提供一个访问它的全局访问点
  • Abstract Factory，抽象工厂：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们的具体类
  • Factory Method，工厂方法：定义一个用于创建对象的接口，让子类决定实例化哪一个类，Factory Method 使一个类的实例化延迟到了子类
  • Builder，建造模式：将一个复杂对象的构建与他的表示相分离，使得同样的构建过程可以创建不同的表示
  • Prototype，原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型来创建新的对象

行为型有

  • Iterator，迭代器模式：提供一个方法顺序访问一个聚合对象的各个元素，而又不需要暴露该对象的内部表示
  • Observer，观察者模式：定义对象间一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知自动更新
  • Template Method，模板方法：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中，TemplateMethod 使得子类可以不改变一个算法的结构即可以重定义该算法得某些特定步骤
  • Command，命令模式：将一个请求封装为一个对象，从而使你可以用不同的请求对客户进行参数化，对请求排队和记录请求日志，以及支持可撤销的操作
  • State，状态模式：允许对象在其内部状态改变时改变他的行为。对象看起来似乎改变了他的类
  • Strategy，策略模式：定义一系列的算法，把他们一个个封装起来，并使他们可以互相替换，本模式使得算法可以独立于使用它们的客户
  • Chain of Responsibility，职责链模式：使多个对象都有机会处理请求，从而避免请求的送发者和接收者之间的耦合关系
  • Mediator，中介者模式：用一个中介对象封装一些列的对象交互
  • Visitor，访问者模式：表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素类的前提下定义作用于这个元素的新操作
  • Interpreter，解释器模式：给定一个语言，定义他的文法的一个表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子
  • Memento，备忘录模式：在不破坏对象的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态

结构型有

  • Composite，组合模式：将对象组合成树形结构以表示部分整体的关系，Composite 使得用户对单个对象和组合对象的使用具有一致性
  • Facade，外观模式：为子系统中的一组接口提供一致的界面，facade 提供了一高层接口，这个接口使得子系统更容易使用
  • Proxy，代理模式：为其他对象提供一种代理以控制对这个对象的访问
  • Adapter，适配器模式：将一类的接口转换成客户希望的另外一个接口，Adapter 模式使得原本由于接口不兼容而不能一起工作那些类可以一起工作
  • Decrator，装饰模式：动态地给一个对象增加一些额外的职责，就增加的功能来说，Decorator 模式相比生成子类更加灵活
  • Bridge，桥模式：将抽象部分与它的实现部分相分离，使他们可以独立的变化
  • Flyweight，享元模式

列举 IE 与其他浏览器不一样的特性？

事件不同之处：

触发事件的元素被认为是目标（target）。而在 IE 中，目标包含在 event 对象的 srcElement 属性

获取字符代码、如果按键代表一个字符（shift、ctrl、alt 除外），IE 的 keyCode 会返回字符代码（Unicode），DOM 中按键的代码和字符是分离的，要获取字符代码，需要使用 charCode 属性

阻止某个事件的默认行为，IE 中阻止某个事件的默认行为，必须将 returnValue 属性设置为 false，Mozilla 中，需要调用 preventDefault(); 方法

停止事件冒泡，IE 中阻止事件进一步冒泡，需要设置 cancelBubble 为 true，Mozzilla 中，需要调用 stopPropagation();

99% 的网站都需要被重构是那本书上写的？

网站重构：应用 web 标准进行设计（第 2 版）

BTW：这都是什么神仙问题

部分地区用户反应网站很卡，请问有哪些可能性的原因，以及解决方法？

TODO

从打开 app 到刷新出内容，整个过程中都发生了什么，如果感觉慢，怎么定位问题，怎么解决？

TODO

第一次访问页面中时弹出引导，用户关闭引导，之后再次进入页面时不希望出现引导，如何实现？

使用 localStorage 处理实现逻辑

你怎么看待 Web App 、hybrid App、Native App？

app 的分类

大致可以分为这 3 种

  • native app（原生 app）
  • web app
  • hybrid app（混合 app）

如下图所示

3 种 app

三类 app 的定义

  • native app

中文名称为 “原生 app”

来看一下百度百科的定义：基于智能手机本地操作系统如 iOS、Android、WP 并使用原生程式编写运行的第三方应用程序，一般开发的语言为 Java、C++ 等。在使用上的具体表现就是，手机桌面上的图标点进去基本就是 native app 了

  • web app

仍然看一下百度百科的定义：基于 web 的系统和应用，运行于网络和浏览器之上，目前多采用 h5 标准开发。在使用上的具体表现是，手机浏览器点击进入，会有一些应用的小图标，这些小图标在点击后，在浏览器里加载的页面跟你直接下载一个 app 后打开的页面是相同的，这些小图标代表的就是 web app

  • hybrid app

中文名称是 “混合app”

顾名思义，就是 native app 与 web app 的混合。在 native app 里内置浏览器，合适的功能页面采用网页的形式呈现。比如京东的某些营销页面，今日头条的某些新闻页面、微信的腾讯新闻的内容页面等

各类 app 的优缺点

  • native app

优点：

  • 提供最佳用户体验，最优质的用户界面，流畅的交互
  • 可以访问本地资源
  • 可以调用移动硬件设备，比如摄像头、麦克风等

缺点：

  • 开发成本高。每种移动操作系统都需要独立的开发项目，针对不同平台提供不同体验
  • 发布新版本慢。下载是用户控制的，很多用户不愿意下载更新（比如说，版本发布到了 3.0，但还是有很多 1.0 的用户，你可能就得继续维护 1.0 版本的 API）

  • 应用商店发布审核周期长。安卓平台大概要 1 - 3 天，而 iOS 平台需要的时间更长

  • web app

优点：

  • 不需要安装包，节约手机空间
  • 整体量级轻，开发成本低
  • 不需要用户进行手动更新，由应用开发者直接在后台更新，推送到用户面前的都是全新版本，更便于业务的开展
  • 基于浏览器，可以跨平台使用

缺点：

  • 页面跳转费力，不稳定感更强。在网速受到限制时，很多时候出现卡顿或者卡死现象，交互效果受到限制

  • 安全性相对较低，数据容易泄露或者被劫持

  • Hybrid app

这类 app 集合了上面两种 app 各自的优势

  • 在实现更多功能的前提下，使得 app 安装包不至于过大
  • 在应用内部打开 web 网页，省去了跳转浏览器的麻烦
  • 主要功能区相对稳定下，增加的功能区采用 web 形式，使得迭代更加方便
  • web 页面在用户设置不同的网络制式时会以不同的形式呈现（以微信朋友圈为例，在数据流量下，设置 APNS 为 WAP 时，微信订阅号内容将屏蔽图片和视频。这样就能为用户省去一部分流量，整个页面阅读就不那么友好了）

另外，为什么有些原生 app 还会做 web app 呢？

有这么几点原因

  • 数据可以被搜索引擎的爬虫抓到，并进行索引。如果产品只有一个 app，那么它的入口独立，但同时数据也是封闭的。如果用户从搜索引擎查找的话，是找不到相关信息的。所以做成 web app，可以被搜索引擎找到
  • 用户碎片时间使用，例如一些黏性不高的应用，比如移动搜索、网址导航等

不同的页面情况选择不同的开发方式

  • 如果 app 中出现了大段文字（如新闻、攻略等），并且格式比较丰富（如加粗、字体多样等），采用 H5 较好。原因：原生开发对解析 json 字符串格式不是很友好
  • 如果讲究 app 反应速度（含页面切换流畅性），采用原生开发。原因：H5 本质上是网页，换网页的时候，基本要加载整个页面，就像一个浏览器打开一个新的网页一样，比较慢，而原生系统只需要加载变化的部分
  • 如果 app 对有无网络、网络优劣敏感（譬如有离线操作、在线操作），则采用原生开发。虽然 H5 可以做到，但是比较敏感
  • 如果 app 要频繁地调用硬件设备（比如摄像头、麦克风等），则采用原生开发，这样支持硬件更多，调用速度更快，H5 望尘莫及
  • 如果 app 用户常见页面频换（如淘宝首页的各种营销活动），采用 H5，维护起来更容易
  • 如果预算有限（H5 开发一套可在安卓、iOS、黑莓等跨平台使用）、不在乎用户体验、不在乎加载速度，肯定是 H5

另外：

  • 短期活动，专题营销类的页面居多的，可以选择原生 app 搭建框架，详细页面采用 H5，便于活动的随时修改和管理
  • 主要业务流程方面，选择原生 app 开发，有更好的用户体验，也可以更方便的拓展其他功能

具体可以参考 传送门

你移动端前端开发的理解？（和 Web 前端开发的主要区别是什么？）

前端是个很大的概念，我的理解是用户能够看到，直接接触到的层面都算是前端，比如 IOS 客户端界面，安卓客户端界面，网页界面，甚至 PC/MAC 桌面端软件界面；现在最常见的说法一般是指 Web 前端，也就是针对于网页端开发的工作

也有个说法就是前端就是大前端嘛，如果你的工作真的那么赞的话，那就包括了 web，安卓，ios，甚至 pc mac 客户端的界面。但我觉得现在一般大家都还是有专攻的

Web App 指的是 Web application，也就是以浏览器作为客户端的软件。比如你要写文档，一般会打开 Office 2012 之类的本地软件；但是你也可以选择在浏览器里输入一个网址，然后直接在里面写东西直接发布到 gist上；再比如用桌面客户端来收发邮件，但你也可以直接用浏览器登陆 gmail 亦或者 QQ 邮箱，直接把这个当客户端用。总之就是使用网页版代替本地软件

Mobile Web App 当然就是指在手机端打开的 Web App

移动客户端的开发类型主要包含下面三种

  • Native App（原生 APP），也就是完全使用移动设备系统语言写的客户端，iPhone iPad 就是纯 Object-C，安卓就是纯 JAVA, 就是用户看到的界面啦体验到的交互啦都是原生的。这是性能最棒的开发方式，但灵活性就没下面的好

  • Web App, 这个就是在移动浏览器里打开的，纯 HTML + CSS + JS，说白了就是个网页，只不过非常的富应用，比如手机浏览器访问的 GMAIL 之类。但说白了就是在浏览器里打开的页面。IOS 支持可以在桌面创建访问的快捷方式，但是说到底还是打开 Safari 跑。而且对设备硬件的接口什么的挺薄弱

  • Hybrid App [HTML5 in mobile devices] 我觉得这个更为合适一些。实际上是使用原生写了一个容器，然后使用 HTML + CSS + JS 来实现用户界面和交互。Web App 的短处便可以克服（因为自己写的容器可以辅助暴露偏底层的接口，比如本地存储或者麦克风控制之类），同时比起纯原生的 java 或者 object-c 开发灵活性要高（更新可以更快更迅速，也不依赖于市场，因为说白了，就是自己下载更新网页资源。）实际上这种方式已经不限于移动端。豌豆荚其实是个 pc 端的 hybrid app，而且说实在的，桌面开发的性能就现在来说要比移动好很多

具体可以参考 传送门

如何设计突发大规模并发架构？

抢购页面可以独立与商城系统外，可以临时性的在商城系统前添加 N 台机器，有序的将用户 “放行” 到商城系统内

抢购商品页面纯静态化（做好 qps 压测评估），至于用户信息，通过 js 从 cookie 里取（临时且快速的方案，安全性不高，只要没黑客恶意搞，其实没什么问题的），如果不存在用户信息，通过 ajax 发送请求到用户中心生成用户 cookie（加载静态页面的时候就判断是否发送 ajax，别等到抢购时判断），如果存在，在抢购时直接获取 cookie 里的用户信息开始抢购。通过 js 从 cookie 里取信息可以大量的减少对商城主系统的依赖，防止造成主系统瘫痪

抢购开始时用验证码防秒杀器，建议事先生成好几百个验证码，随机取一个，别等到抢购时临时生成，不然容易挂

最难点，抢购减库存。防超卖，库存表和判重表建议单独搞台大服务器专门放这 2 个表，不然 50w 人开秒死都不知道怎么死的

三个方向考虑吧。横向就是做分布式，通过添加 N 台机器，部署 N 套系统的方式来并发处理。这里面要考虑好 session 的一致性。纵向的话，就是把瓶颈部分做优化，使用内存来持久数据，减少 IO，还有合理的使用消息排队。这里可能要好好考虑内存与数据库一致性。还有就是业务方向

知道什么是 SEO 并且怎么优化么? 知道各种 meta data 的含义么?

SEO 是英文 Search Engine Optimization 的缩写，转换为中文的 “搜索引擎优化”。简而言之，SEO 是指从自然搜索结果中获取网站流量的技术和过程。从某种意义上说，SEO 是用搜索引擎玩游戏的过程。SEM，搜索引擎营销，基于用户使用搜索引擎的方式，利用用户的机会尽可能多地检索信息，以向目标用户提供营销信息。在当前的企业网站营销中，SOM（SEO + SEM）模型变得越来越重要

元标记主要是标题，关键字，描述或 TKD（title keywords description）

data-* 属性用于存储页面或应用程序的私有自定义数据

data-* 属性使我们能够在所有 HTML 元素上嵌入自定义数据属性

页面的 JavaScript 可以利用存储的（自定义）数据来创建更好的用户体验（没有 Ajax 调用或服务器端数据库查询）

简单地说，SEO 是搜索引擎，后者是描述标签

SEO 的优势有如下几点

  • 做 SEO 能来客户。为什么要做 SEO？终极目标是能来带销售。从百度获取的流量比今日头条等媒体更精准，因为是用户主动发起，反应的是即时需求，转化率高
  • 流量精准，能变成付费用户的可能性大。因为根据相关的关键词，可以找到非常精准的流量。举个例子，一家北京饭店，在搜索词 “北京美食” 的内容里排到第一的话，会带来多少精准流量
  • 企业付出的成本比较低。只需要进行一些内容、网站上的优化，但是可能带来的流量不论质量还是数量都是非常之高的
  • 一劳永逸，长期有效。一旦占据了高位，就很难下去了。只要及时的进行优化，那么起码是会很长时间占据首位的

百度的搜索内容是如何呈现的呢？

  • 首先百度的机器人会在网上对网站进行爬行和抓取，将网页内容和 HTML 代码收录到百度的数据库中
  • 第二步预处理，会对网页提取文字，分词，去停止词、消噪、去重，提取关键词建立索引，最终根据这些内容计算出网页的权重。网页权重决定了网页在搜索当中的排序
  • 第三步就是排名，百度会对数据库中的网页，根据计算出的权重进行排名，再进行一次过滤，也是最终体现在搜索结果页面的顺序了

重点是：权重值、关键词

HTML 的 head 里有一个 meta 标签。那么它是什么呢？

它是 “关于文档的信息”

meta 的属性有两种，name 和 http-equiv

name 属性用来描述网页的内容，以便搜索引擎查找。比如这个网页的 keywords。http-equiv 属性指示服务器在发送实际的文档之前先在要传送给浏览器的 MIME 文档头部包含名称 / 值对

看下面的🌰

<meta http-equiv="Content-Language" contect="zh-CN">

用以说明主页制作所使用的文字以及语言

更多关于元数据可以参考 传送门

你认为怎样才是全端工程师（Full Stack developer）？

Full Stack Engineer

设计，后台开发，前端开发，移动开发，运营维护，PS，文案… 好像都会了，这算 Full Stack Engineer 了么？不，这只是踏上成为 Full Stack Engineer 的第一步

你知道目前只是每个 stack 都懂一点，离 senior 或者 expert 还差得远，而要每个 stack 都做到极致，需要大量的时间和精力。精力有限，产品开发紧迫，力不从心啊，这条道路也太孤独，因为你不需要与任何人进行协作。难道要把一些 stack 的任务交给别人做么？这样算是放弃成为 Full Stack Engineer 么？不！这不是

什么是 Engineer？「Engineers are versatile minds who create links between science, technology, and society」。Engineer 的本质工作是设计，开发出应用于大众的产品。一个真正的 Full Stack Engineer ，他从生活中发现问题，洞察需求，他设计解决方案，并开发出初始版本的产品。为了达到目标，他愿意去学习任何领域的技能和知识。同时他不追求一个人完成所有工作，如果有人可以比他在某方面做得更出色，便会十分热情的邀请他们加入

最终他的职位也许不再是 Engineer ，他不再设计 UI ，不再写代码 … 他的工作不再是 design and building an app or product，因为他有更大更重要的任务要做 - design and building a team or a company which builds great products

具体可以参考

传送门

你有自己的技术博客吗，用了哪些技术？

https://war408705279.github.io/

使用了 hugo + Github + markdown

对前端安全有什么看法？

“安全” 是个很大的话题，各种安全问题的类型也是种类繁多。如果我们把安全问题按照所发生的区域来进行分类的话，那么所有发生在后端服务器、应用、服务当中的安全问题就是 “后端安全问题”，所有发生在浏览器、单页面应用、Web 页面当中的安全问题则算是 “前端安全问题”。比如说，SQL 注入漏洞发生在后端应用中，是后端安全问题，跨站脚本攻击（XSS）则是前端安全问题，因为它发生在用户的浏览器里

8 大前端安全问题

按照上面的分类办法，总结出了 8 大典型的前端安全问题，它们分别是：

  • 老生常谈的 XSS
  • 警惕 iframe 带来的风险
  • 别被点击劫持了
  • 错误的内容推断
  • 防火防盗防猪队友：不安全的第三方依赖包
  • 用了 HTTPS 也可能掉坑里
  • 本地存储数据泄露
  • 缺失静态资源完整性校验

具体可以查看

传送门 1

传送门 2

是否了解 Web 注入攻击，说下原理，最常见的两种攻击（XSS 和 CSRF）了解到什么程度？

具体可以参考

传送门 1

传送门 2

开放问题

开放问题，没有标准答案，结合自身的实际情况回答即可

这里就不给答案了，大家可以思考一下~

项目中遇到国哪些印象深刻的技术难题，具体是什么问题，怎么解决？

最近在学什么东西？

如何管理前端团队?

最近在学什么？能谈谈你未来 3，5 年给自己的规划吗？