常见的http状态码
成功(2XX)
状态码 原因短语 说明
200 OK 表示从客户端发来的请求在服务器端被正确处理
201 Created 请求已经被实现,⽽且有⼀个新的资源已经依据请求的需要⽽建⽴ 通常是在 POST 请求,或是某些 PUT 请求之后创建了内容, 进行的返回的响应
202 Accepted 请求服务器已接受,但是尚未处理,不保证完成请求 适合异步任务或者说需要处理时间比较长的请求,避免 HTTP 连接一直占用
204 No content 表示请求成功,但响应报⽂不含实体的主体部分
206 Partial Content 进⾏的是范围请求, 表示服务器已经成功处理了部分 GET 请求 响应头中会包含获取的内容范围 (常用于分段下载)
重定向(3XX)
状态码 原因短语 说明
301 Moved Permanently 永久性重定向,表示资源已被分配了新的 URL 比如,我们访问 www.baidu.com 会跳转到 www.baidu.com
302 Found 临时性重定向,表示资源临时被分配了新的 URL, 支持搜索引擎优化 首页, 个人中心, 遇到了需要登录才能操作的内容, 重定向 到 登录页
303 See Other 对于 POST 请求,它表示请求已经被处理,客户端可以接着使用 GET 方法去请求 Location 里的 URI。
304 Not Modified 自从上次请求后,请求的网页内容未修改过。 服务器返回此响应时,不会返回网页内容。(协商缓存)
307 Temporary Redirect 对于 POST 请求,表示请求还没有被处理,客户端应该向 Location 里的 URI 重新发起 POST 请求。
不对请求做额外处理, 正常发送请求, 请求 location 中的 url 地址
因为 post 请求, 是非幂等的, 从 302 中, 细化出了 303 和 307
简而言之:
301 302 307都是重定向304协商缓存
客户端错误(4XX)
状态码 原因短语 说明
400 Bad Request 请求报⽂存在语法错误(传参格式不正确)
401 UnAuthorized 权限认证未通过(没有权限)
403 Forbidden 表示对请求资源的访问被服务器拒绝
404 Not Found 表示在服务器上没有找到请求的资源
408 Request Timeout 客户端请求超时
409 Confict 请求的资源可能引起冲突
服务端错误(5XX)
状态码 原因短语 说明
500 Internal Sever Error 表示服务器端在执⾏请求时发⽣了错误
501 Not Implemented 请求超出服务器能⼒范围,例如服务器不⽀持当前请求所需要的某个功能, 或者请求是服务器不⽀持的某个⽅法
503 Service Unavailable 表明服务器暂时处于超负载或正在停机维护,⽆法处理请求
505 Http Version Not Supported 服务器不⽀持,或者拒绝⽀持在请求中使⽤的 HTTP 版本
跨域及解决
跨域,是指浏览器不能执行其它网站的脚本。它是由浏览器的同源策略造成的,是浏览器对 javascript 实施的安全限制。
同源策略是浏览器最核心也最基本的安全功能,具有以下特点:
- 协议相同
- 主机相同
- 端口相同
只要其中一项不相同,就会产生跨域
常见的解决方案有 3 种:
JSONP: 利用 script 标签,不受跨域限制的特点,缺点是只能支持 get 请求
CORS: 后端设置响应头 Access-Control-Allow-Origin:*
服务器代理:在 DevServer 中配置 proxy
MVC,MCCM 区别是什么? 哪些场景适合?
1. MVVM基本定义
MVVM 即Model-View-ViewModel的简写。即模型-视图-视图模型。模型(Mod e1)指的是后端传递的数据。视图(View)指的是所看到的页面。视图模型(ViewModel)是mvvm模式的核心,它是连接view和model的桥梁。它有两个方向: - 是将模型(Model)转化成视图(View),即将后端传递的数据转化成所看到的页面。实现的方式是:数据绑定。二是将视图(View)转化成模型(Model),即将所看到的页面转化成后端的数据。实现的方式是:DOM事件监听。这两个方向都实现的,我们称之为数据的双向绑定。
2. MVC基本定义
MVC是Model-View-Controller的简写。即模型-视图-控制器。M和V指的意思
和MVVM中的M和V意思一样。C即Controller指的是页面业务逻辑。使用MVC的目的就是将M和V的代码分离。MVC是单向通信。也就是View跟Model,必须通过Controller来承上启下。MVC和MVVM的区别并不是VM完全取代了C,只是在MVC的基础上增加了一层VM,只不过是弱化了C的概念,ViewModel存在目的在于抽离Controller中展示的业务逻辑,而不是替代Controller,其它视图操作业务等还是应该放在Controller中实现。也就是说MVVM实现的是业务逻辑组件的重用,使开发更高效,结构更清晰,增加代码的复用性。
3. 使用场景
MVC和MVVM其实区别并不大。都是一种设计思想。主要就是MVC中 Controller演变成MVVM中的viewModel,MVVM主要解决了MVC中大量的DOM操作使页面渲染性能降低,加载速度变慢,影响用户体验。 区别:Vue数据驱动,通过数据来显示视图层而不是节点操作。场景:数据操作比较多的场景,需要大量操作DOM元素时,采用MVVM的开发方式,会更加便捷,让开发者更多的精力放在数据的变化上,解放繁琐的操作DOM元素。
跨窗口通讯
前端跨窗口通信是指在不同窗口或浏览器标签页之间进行通信的技术。它可以用于实现如下场景:
- 在同一域名下的不同窗口或标签页之间共享数据。
- 在不同域名下的窗口或标签页之间进行通信。
- 在不同浏览器之间进行通信。
以下是几种常见的前端跨窗口通信方法:
-
Window.postMessage():这是HTML5提供的一种跨窗口通信机制。它允许你向目标窗口发送消息,并在目标窗口的事件监听器中接收消息。通过指定目标窗口的origin(来源)参数,可以确保只有特定窗口能够接收消息,提供了安全性。 -
LocalStorage或SessionStorage:这两个Web Storage API 提供了在同一浏览器的不同窗口之间共享数据的能力。数据存储在本地,可以通过监听storage事件来检测数据的变化。 -
Cookies:Cookies 是在浏览器和服务器之间传递数据的一种机制。可以在不同窗口或标签页之间共享和读取同一域名下的cookie数据。 -
Broadcast Channel API:这是一个新的Web API,可以在同一浏览器的不同窗口或标签页之间进行广播消息。使用Broadcast Channel,可以创建一个频道,并在不同窗口之间发送和接收消息。 -
Shared Worker:Shared Worker 是一种在多个窗口或标签页之间共享 JavaScript 运行环境的机制。可以在多个窗口中实例化一个 Shared Worker,通过共享的 Worker 上下文进行通信。 -
WebSocket:WebSocket 是一种全双工通信协议,可以在客户端和服务器之间建立持久化的连接。通过 WebSocket,可以在不同窗口或标签页之间进行实时的双向通信。
选择适当的跨窗口通信方法取决于具体的需求和场景。需要考虑安全性、浏览器兼容性、通信方式、域名限制等因素来选择最合适的方法。
在地址栏输入网址回车发生了什么?
-
DNS解析:浏览器会提取输入的网址中的域名部分,并向本地DNS服务器发送DNS查询请求,以获取该域名对应的IP地址。如果本地DNS服务器没有缓存该域名的IP地址,它会向其他DNS服务器继续发送查询请求,直到找到对应的IP地址。
-
建立TCP连接:使用获取到的IP地址,浏览器会尝试与目标服务器建立TCP连接。这个过程通常涉及三次握手(三次握手过程见前面的回答),确保浏览器和服务器之间建立起可靠的连接。
-
发起HTTP请求:一旦TCP连接建立成功,浏览器会向服务器发送一个HTTP请求,其中包含了具体的请求方法(如GET、POST)、请求路径、请求头等信息。这些信息告诉服务器需要获取的资源以及其他相关的请求参数。
-
服务器处理请求:服务器收到浏览器发送的HTTP请求后,会根据请求的路径、方法和其他参数来处理请求。这可能涉及查询数据库、执行业务逻辑等操作。
-
服务器发送HTTP响应:服务器处理完请求后,会生成一个HTTP响应,包含了响应状态码、响应头和响应体等信息。响应状态码指示请求的处理结果,响应头包含了与响应相关的附加信息,而响应体则包含了请求的实际数据。
-
接收并渲染响应:浏览器接收到服务器发送的HTTP响应后,会解析响应,根据响应中的内容类型进行相应的处理。如果是HTML页面,浏览器会解析HTML并构建DOM树,然后开始渲染页面。
-
关闭TCP连接:一旦响应被处理完毕,浏览器和服务器之间的TCP连接会被关闭,释放相关的资源。
这是一个简化的描述,实际的过程可能涉及更多细节和步骤,如缓存处理、重定向、安全认证等。整个过程的时间取决于网络延迟、服务器响应时间和页面内容的复杂性等因素。
http2和http3的区别
-
传输方式:
- HTTP/2使用二进制传输格式,将HTTP消息分割为二进制帧并进行传输,提高了传输效率。
- HTTP/3使用QUIC协议(基于UDP),将HTTP消息封装在QUIC数据包中进行传输,从而实现更快的连接建立和数据传输速度。
-
连接建立和头部压缩:
- HTTP/2使用多路复用(Multiplexing)技术,允许在同一个连接上同时发送多个请求和响应,避免了建立多个连接的开销。此外,HTTP/2还引入了头部压缩机制,减少了头部的传输大小。
- HTTP/3基于QUIC,每个请求和响应都在独立的QUIC连接上完成,因此可以更灵活地处理丢包和连接断开的情况。头部压缩也得到改进,采用了QPACK算法,进一步减少了头部的传输大小。
-
可靠性和性能:
- HTTP/2在传输层使用TCP协议,TCP协议保证了可靠性,但在丢包或拥塞时可能会导致延迟增加。
- HTTP/3基于QUIC,QUIC协议在传输层提供了自己的可靠性和拥塞控制机制,能够更好地适应不稳定的网络环境,并减少连接建立的延迟。
-
迁移成本:
- 由于HTTP/2和HTTP/3使用不同的传输方式和协议,因此从HTTP/2迁移到HTTP/3可能需要进行一些调整和更新,包括服务器和客户端的支持以及网络基础设施的更新。
总体来说,HTTP/2和HTTP/3都致力于提高性能和效率,但HTTP/3引入了QUIC协议,带来了更快的连接建立和数据传输速度,以及更好的适应性能不稳定的网络环境。然而,由于HTTP/3仍处于较新的阶段,支持和部署的广泛程度相对较低。
get和post的区别
区别
- Get 使用 URL或 Cookie 传参,而 POST 将数据放在body中
- Get 的 URL 会有长度上的限制,则 POST 的数据则可以非常大
- POST 比 Get 安全, 因为数据在地址栏上不可见
最本质的区别
基于http协议进行请求,其实GET和POST无区别,只是请求时的方式不同,都可以携带请求体,也可以在URL带参数
区别来自于浏览器对URL长度的限制,请求体大小来源于服务器的限制
还有语义的区别: GET是获取,POST是提交 GET是用来从服务器上获取数据,而POST是用来向服务器上传递数据
GET/POST 使用场景 POST:
- 请求的结果有持续性作用,例如:数据库内添加新的数据行
- 若使用GET方法,则表单上收集的数据可能让URL过长
- 要传送的数据不是采用ASCII编码
GET:
- 请求是为了查找资源,HTMl表单数据仅用来搜索
- 请求结果无持续性的副作用
- 收集的数据及html表单内的输入字段名称的总长不超过1024个字符
session storage和localstorage和cookie的区别
cookie是网站为了标示用户身份而储存在用户本地终端(Client Side)上的数据(通常经过加密)
cookie数据始终在同源的http请求中携带(即使不需要),记会在浏览器和服务器间来回传递
sessionStorage和localStorage不会自动把数据发给服务器,仅在本地保存
存储大小:
cookie数据大小不能超过4k
sessionStorage和localStorage虽然也有存储大小的限制,但比cookie大得多,可以达到5M或更大
有期时间:
localStorage 存储持久数据,浏览器关闭后数据不丢失除非主动删除数据
sessionStorage 数据在当前浏览器窗口关闭后自动删除
cookie 设置的cookie过期时间之前一直有效,即使窗口或浏览器关闭
原生小程序的生命周期?
-
App生命周期:
- onLaunch: 当小程序初始化完成时触发,全局只触发一次。
- onShow: 当小程序启动或从后台进入前台显示时触发。
- onHide: 当小程序从前台进入后台时触发。
- onError: 当小程序发生脚本错误或 API 调用失败时触发。
-
Page生命周期:
- onLoad: 当页面加载时触发,只会触发一次。
- onShow: 当页面显示时触发,每次页面打开都会触发。
- onReady: 当页面初次渲染完成时触发,只会触发一次。
- onHide: 当页面隐藏时触发。
- onUnload: 当页面卸载时触发。
-
Component生命周期:
- created: 组件实例被创建时触发,可以在这里进行数据初始化。
- attached: 组件被添加到页面节点树时触发。
- ready: 组件布局完成时触发。
- detached: 组件被从页面节点树移除时触发。
除了上述生命周期,小程序还提供了一些其他的回调函数,例如事件处理函数、数据监听等,可以根据具体需求进行使用。
需要注意的是,不同的小程序框架和版本可能会有略微不同的生命周期钩子和行为。因此,具体的生命周期函数和触发时机可能会有所差异
小程序如何做支付?
-
打开某小程序,点击直接下单
-
wx.login获取用户临时登录凭证code,发送到后端服务器换取openId
-
在下单时,小程序需要将购买的商品Id,商品数量,以及用户的openId传送到服务器
-
服务器在接收到商品Id、商品数量、openId后,生成服务期订单数据,同时经过一定的签名算法,向微信支付发送请求,获取预付单信息(prepay_id),同时将获取的数据再次进行相应规则的签名,向小程序端响应必要的信息
-
小程序端在获取对应的参数后,调用wx.requestPayment()发起微信支付,唤醒支付工作台,进行支付
-
接下来的一些列操作都是由用户来操作的包括了微信支付密码,指纹等验证,确认支付之后执行鉴权调起支付
-
鉴权调起支付:在微信后台进行鉴权,微信后台直接返回给前端支付的结果,前端收到返回数据后对支付结果进行展示
-
推送支付结果:微信后台在给前端返回支付的结果后,也会向后台也返回一个支付结果,后台通过这个支付结果来更新订单的状态
小程序如何获取用户信息?
微信小程序
可通过 wx.getUserProfile() 和 小程序 wx.getSetting() 方法获取
Uniapp
uni.getUserInfo()方法: uni.getUserInfo()是UniApp提供的API,可以获取用户的基本信息,包括用户的昵称、头像、性别等。使用该方法前,需要先获取用户的授权。
uni.login()和uni.getUserProfile()方法:这是UniApp 2.7.0版本及以上的新特性。uni.login()用于获取用户的登录凭证(code),然后通过 uni.getUserProfile()获取用户的详细信息。
小程序如何调用地图?
wx.chooseLocation()
获取用户指定位置的经纬度。在小程序中调用这个接口时必须要在 app.json 中申请调用权限
{
"requiredPrivateInfos": [
"chooseLocation"
]
}
如何做性能优化?
前端性能优化是指通过优化前端代码、减少网络请求和提高页面加载速度等方式来提升网页的性能和用户体验。以下是一些常见的前端性能优化技巧:
-
减少HTTP请求:减少页面上的资源文件数量,如合并CSS和JavaScript文件,使用CSS Sprites合并图片,使用字体图标等,从而减少页面加载所需的HTTP请求次数。 -
压缩和缓存资源:压缩JavaScript、CSS和图片等静态资源,以减小文件大小,从而加快下载速度。另外,设置适当的缓存策略,使浏览器能够缓存静态资源,减少重复下载。 -
使用CDN(内容分发网络):将静态资源部署到全球各地的CDN节点,使用户可以从离他们更近的节点获取资源,加速页面加载速度。 -
懒加载和延迟加载:对于长页面或有大量图片的页面,可以采用懒加载(Lazy Loading)技术,延迟加载非关键资源,当用户滚动到相关区域时再加载。 -
前端构建和打包工具:使用前端构建工具(如Webpack、Parcel)进行代码的压缩、合并和优化,以及打包成较小的文件,减少网络传输时间。 -
优化图片:选择合适的图片格式,使用适当的压缩率,根据需要设置图片尺寸,使用响应式图片等方式来优化图片加载。 -
使用CSS和JavaScript的最佳实践:优化CSS和JavaScript代码,如避免使用昂贵的CSS选择器,尽量减少DOM操作,避免阻塞JavaScript执行等。 -
使用缓存技术:使用浏览器缓存和服务端缓存,如利用HTTP缓存头、使用Redis等,减少对服务器的请求和数据处理。 -
前端性能监测和分析:使用性能监测工具(如Lighthouse、WebPageTest)进行性能分析,找出性能瓶颈和优化机会。 -
移动端优化:针对移动端设备,使用响应式设计、按需加载移动端特定资源、使用可触摸的UI元素等方式进行优化。
以上只是一些常见的前端性能优化技巧,实际的优化策略还需根据具体的应用场景和需求来确定。重要的是,优化应该是一个持续的过程,需要不断地进行监测和改进,以提供更好的用户体验。
通过webpack优化前端的手段有:
- JS 代码压缩
- CSS 代码压缩
- Html 文件代码压缩
- 文件大小压缩
- 图片压缩
- Tree Shaking
- 代码分离
- 内联 chunk
JS 代码压缩
terser是一个JavaScript的解释、绞肉机、压缩机的工具集,可以帮助我们压缩、丑化我们的代码,让bundle更小
在production模式下,webpack 默认就是使用 TerserPlugin 来处理我们的代码的。
CSS 代码压缩
CSS压缩通常是去除无用的空格等,因为很难去修改选择器、属性的名称、值等
CSS 的压缩我们可以使用另外一个插件:css-minimizer-webpack-plugin
Html 文件代码压缩
使用HtmlWebpackPlugin插件来生成HTML的模板时候,通过配置属性minify进行html优化
文件大小压缩
对文件的大小进行压缩,减少http传输过程中宽带的损耗
图片压缩
一般来说在打包之后,一些图片文件的大小是远远要比 js 或者 css 文件要来的大,所以图片压缩较为重要
Tree Shaking
Tree Shaking 是一个术语,在计算机中表示消除死代码,依赖于ES Module的静态语法分析(不执行任何的代码,可以明确知道模块的依赖关系)
在webpack实现Trss shaking有两种不同的方案:
- usedExports:通过标记某些函数是否被使用,之后通过 Terser 来进行优化的
- sideEffects:跳过整个模块/文件,直接查看该文件是否有副作用
代码分离
将代码分离到不同的bundle中,之后我们可以按需加载,或者并行加载这些文件
默认情况下,所有的JavaScript代码(业务代码、第三方依赖、暂时没有用到的模块)在首页全部都加载,就会影响首页的加载速度
代码分离可以分出出更小的bundle,以及控制资源加载优先级,提供代码的加载性能
内联 chunk
可以通过InlineChunkHtmlPlugin插件将一些chunk的模块内联到html,如runtime的代码(对模块进行解析、加载、模块信息相关的代码),代码量并不大,但是必须加载的
关于webpack对前端性能的优化,可以通过文件体积大小入手,其次还可通过分包的形式、减少 http 请求次数等方式,实现对前端性能的优化
type和interface的区别
相同点
- 都能描述对象类型
- 都能实现继承,interface使用extends, type配合交叉类型
不同点
- type除了能描述对象还可以用来自定义其他类型
- 同名的interface会合并(属性取并集,不能出现类型冲突)
如何理解泛型
概念
泛型(Generics)是指在定义接口、函数等类型的时候,不预先指定具体的类型,而在使用的时候再指定类型的一种特性 , 使用泛型可以复用类型并且让类型更加灵活。
泛型接口
语法:在接口类型的名称后面使用<T>即可声明一个泛型参数列表,接口里的其他成员都能使用该参数的类型。
类比:函数的形参
interface 接口名字 <T1,T2,...> {
// 在接口内部使用T1,T2 ......
}
泛型-类型别名
语法:在类型别名type的后面使用<T>即可声明一个泛型参数,接口里的其他成员都能使用该参数的类型。
泛型-函数
语法:在函数名称的后面使用即可声明泛型参数,整个函数中(参数、返回值、函数体)的变量都可以使用该参数的类型
泛型约束
作用:泛型的特点就是灵活不确定,有些时候泛型函数的内部需要访问一些特定类型的数据才有的属性,此时会有类型错误,需要通过泛型约束解决
如何理解微前端技术
微前端技术是一种前端架构模式,旨在帮助开发团队更好地构建和维护大型复杂应用程序。微前端技术将前端应用程序拆分成多个小的、独立的部分,每个部分都由不同的团队负责开发和维护。这些独立的部分可以是单页应用(Single-Page Application)或小型应用,它们可以独立运行、开发和部署。
微前端技术的关键思想是将整个应用程序划分为多个微前端(Micro Frontends),每个微前端都是一个独立的子应用,可以单独开发、测试、部署和运行。这些微前端可以通过共享组件、模块、服务等方式进行通信和协作。
以下是一些常见的微前端技术和工具:
Web组件(Web Components):Web组件是一种用于封装和复用Web界面的技术,包括自定义元素、阴影DOM和HTML模板等。通过使用Web组件,不同团队可以独立开发和维护自己的组件,然后在应用程序中进行组合。
模块联邦(Module Federation):模块联邦是一种Webpack插件,用于将多个独立的Webpack构建整合为一个应用程序。它使不同的团队可以独立构建和部署自己的模块,并在运行时动态加载和共享模块。
前端集成框架:如single-spa、qiankun等,这些框架提供了一套机制和工具,使得多个独立的前端应用可以在同一个页面中并行运行和协同工作,共享路由和状态管理等。
前端微服务架构:在微服务架构中,前端也可以采用类似的方式进行拆分和独立部署。每个微前端可以有自己的服务端和数据存储,通过API进行通信,实现松耦合和独立演进。
微前端技术的好处包括:
团队自治:不同团队可以独立开发和部署自己的微前端,减少了团队之间的依赖和沟通成本。 技术栈灵活性:每个微前端可以使用不同的技术栈和框架,根据需求选择最适合的工具。 独立发布和部署:微前端可以独立进行发布和部署,降低了部署的风险和复杂性。 模块化和复用:通过共享组件和模块,不同的微前端可以共享和复用代码,提高开发效率和一致性。 微前端技术的引入需要仔细考虑应用程序的规模和复杂性,以及团队的组织和协作方式。它适用于大型应用程序和复杂的组织结构,但对于小型应用可能带来额外的复杂性。