穷追猛打,阿里二面问了我30分钟从URL输入到渲染...

当面试官问出这个题后,大部分人听到都是内心窃喜:早就背下这篇八股文。

但是稍等,下面几个问题你能答出来吗:

  1. 浏览器对URL为什么要解析?URL参数用的是什么字符编码?那encodeURI和encodeURIComponent有什么区别?

  2. 浏览器缓存的disk cache和memory cache是什么?

  3. 预加载prefetch、preload有什么差别?

  4. JS脚本的async和defer有什么区别?

  5. TCP握手为什么要三次,挥手为什么要四次?

  6. HTTPS的握手有了解过吗?

同样的问题,可以拿来招聘P5也可以是P7,只是深度不同。所以我重新整理了一遍整个流程,本文较长,建议先收藏。

概述

在进入正题之前,先简单了解一下浏览器的架构作为前置知识。浏览器是多进程的工作的,“从URL输入到渲染”会主要涉及到的,是浏览器进程、网络进程和渲染进程这三个:

  1. 浏览器进程负责处理、响应用户交互,比如点击、滚动;

  2. 网络进程负责处理数据的请求,提供下载功能;

  3. 渲染进程负责将获取到的HTML、CSS、JS处理成可以看见、可以交互的页面;

“从URL输入到页面渲染”整个过程可以分成网络请求和浏览器渲染两个部分,分别由网络进程和渲染进程去处理。

网络请求

网络请求部分进行了这几项工作:

  1. URL的解析

  2. 检查资源缓存

  3. DNS解析

  4. 建立TCP连接

  5. TLS协商密钥

  6. 发送请求&接收响应

  7. 关闭TCP连接

接下来会一一展开。

URL解析

浏览器首先会判断输入的内容是一个URL还是搜索关键字。

如果是URL,会把不完整的URL合成完整的URL。一个完整的URL应该是:协议+主机+端口+路径[+参数][+锚点]。比如我们在地址栏输入www.baidu.com,浏览器最终会将其拼接成https://www.baidu.com/,默认使用443端口。

如果是搜索关键字,会将其拼接到默认搜索引擎的参数部分去搜索。这个流程需要对输入的不安全字符编码进行转义(安全字符指的是数字、英文和少数符号)。因为URL的参数是不能有中文的,也不能有一些特殊字符,比如= ? &,否则当我搜索1+1=2,假如不加以转义,url会是/search?q=1+1=2&source=chrome,和URL本身的分隔符=产生了歧义。

URL对非安全字符转义时,使用的编码叫百分号编码,因为它使用百分号加上两位的16进制数表示。这两位16进制数来自UTF-8编码,将每一个中文转换成3个字节,比如我在google地址栏输入“中文”,url会变成/search?q=%E4%B8%AD%E6%96%87,一共6个字节。

我们在写代码时经常会用的encodeURIencodeURIComponent正是起这个作用的,它们的规则基本一样,只是= ? & ; /这类URI组成符号,这些在encodeURI中不会被编码,但在encodeURIComponent中统统会。因为encodeURI是编码整个URL,而encodeURIComponent编码的是参数部分,需要更加严格把关。

检查缓存

检查缓存一定是在发起真正的请求之前进行的,只有这样缓存的机制才会生效。如果发现有对应的缓存资源,则去检查缓存的有效期。

  1. 在有效期内的缓存资源直接使用,称之为强缓存,从chrome网络面板看到这类请求直接返回200,size是memory cache或者disk cachememory cache是指从资源从内存中被取出,disk cache是指从磁盘中被取出;从内存中读取比从磁盘中快很多,但资源能不能分配到内存要取决于当下的系统状态。通常来说,刷新页面会使用内存缓存,关闭后重新打开会使用磁盘缓存。

  2. 超过有效期的,则携带缓存的资源标识向服务端发起请求,校验是否能继续使用,如果服务端告诉我们,可以继续使用本地存储,则返回304,并且不携带数据;如果服务端告诉我们需要用更新的资源,则返回200,并且携带更新后的资源和资源标识缓存到本地,方便下一次使用。

DNS解析

如果没有成功使用本地缓存,则需要发起网络请求了。首先要做的是DNS解析。

会依次搜索:

  1. 浏览器的DNS缓存;

  2. 操作系统的DNS缓存;

  3. 路由器的DNS缓存;

  4. 向服务商的DNS服务器查询;

  5. 向全球13台根域名服务器查询;

为了节省时间,可以在HTML头部去做DNS的预解析:

<link rel="dns-prefetch" href="http://www.baidu.com" />

为了保证响应的及时,DNS解析使用的是UDP协议

建立TCP连接

我们发送的请求是基于TCP协议的,所以要先进行连接建立。建立连接的通信是打电话,双方都在线;无连接的通信是发短信,发送方不管接收方,自己说自己的。

这个确认接收方在线的过程就是通过TCP的三次握手完成的。

  1. 客户端发送建立连接请求;

  2. 服务端发送建立连接确认,此时服务端为该TCP连接分配资源;

  3. 客户端发送建立连接确认的确认,此时客户端为该TCP连接分配资源;

为什么要三次握手才算建立连接完成?

可以先假设建立连接只要两次会发生什么。把上面的状态图稍加修改,看起来一切正常。

但假如这时服务端收到一个失效的建立连接请求,我们会发现服务端的资源被浪费了——此时客户端并没有想给它传送数据,但它却准备好了内存等资源一直等待着。

所以说,三次握手是为了保证客户端存活,防止服务端在收到失效的超时请求造成资源浪费。

协商加密密钥——TLS握手

为了保障通信的安全,我们使用的是HTTPS协议,其中的S指的就是TLS。TLS使用的是一种非对称+对称的方式进行加密。

对称加密就是两边拥有相同的秘钥,两边都知道如何将密文加密解密。这种加密方式速度很快,但是问题在于如何让双方知道秘钥。因为 传输数据都是走的网络,如果将秘钥通过网络的方式传递的话,秘钥被截获,就失去了加密的意义。

非对称加密,每个人都有一把公钥和私钥,公钥所有人都可以知道,私钥只有自己知道,将数据用公钥加密,解密必须使用私钥。这种加密方式就可以完美解决对称加密存在的问题,缺点是速度很慢。

我们采取非对称加密的方式协商出一个对称密钥,这个密钥只有发送方和接收方知道的密钥,流程如下:

  1. 客户端发送一个随机值以及需要的协议和加密方式;

  2. 服务端收到客户端的随机值,发送自己的数字证书,附加上自己产生一个随机值,并根据客户端需求的协议和加密方式使用对应的方式;

  3. 客户端收到服务端的证书并验证是否有效,验证通过会再生成一个随机值,通过服务端证书的公钥去加密这个随机值并发送给服务端;

  4. 服务端收到加密过的随机值并使用私钥解密获得第三个随机值,这时候两端都拥有了三个随机值,可以通过这三个随机值按照之前约定的加密方式生成密钥,接下来的通信就可以通过该对称密钥来加密解密;

通过以上步骤可知,在TLS握手阶段,两端使用非对称加密的方式来通信,但是因为非对称加密损耗的性能比对称加密大,所以在正式传输数据时,两端使用对称加密的方式。

发送请求&接收响应

HTTP的默认端口是80,HTTPS的默认端口是443。

请求的基本组成是请求行+请求头+请求体

POST /hello HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi

name=niannian

响应的基本组成是响应行+响应头+响应体

HTTP/1.1 200 OK
Content-Type:application/json
Server:apache

{password:'123'}

关闭TCP连接

等数据传输完毕,就要关闭TCP连接了。关闭连接的主动方可以是客户端,也可以是服务端,这里以客户端为例,整个过程有四次握手:

  1. 客户端请求释放连接,仅表示客户端不再发送数据了;

  2. 服务端确认连接释放,但这时可能还有数据需要处理和发送;

  3. 服务端请求释放连接,服务端这时不再需要发送数据时;

  4. 客户端确认连接释放;

为什么要有四次挥手

TCP 是可以双向传输数据的,每个方向都需要一个请求和一个确认。因为在第二次握手结束后,服务端还有数据传输,所以没有办法把第二次确认和第三次合并。

主动方为什么会等待2MSL

客户端在发送完第四次的确认报文段后会等待2MSL才正真关闭连接,MSL是指数据包在网络中最大的生存时间。目的是确保服务端收到了这个确认报文段,

假设服务端没有收到第四次握手的报文,试想一下会发生什么?在客户端发送第四次握手的数据包后,服务端首先会等待,在1个MSL后,它发现超过了网络中数据包的最大生存时间,但是自己还没有收到数据包,于是服务端认为这个数据包已经丢失了,它决定把第三次握手的数据包重新给客户端发送一次,这个数据包最多花费一个MSL会到达客户端。

一来一去,一共是2MSL,所以客户端在发送完第四次握手数据包后,等待2MSL是一种兜底机制,如果在2MSL内没有收到其他报文段,客户端则认为服务端已经成功接受到第四次挥手,连接正式关闭。

浏览器渲染

上面讲完了网络请求部分,现在浏览器拿到了数据,剩下需要渲染进程工作了。浏览器渲染主要完成了一下几个工作:

  1. 构建DOM树;

  2. 样式计算;

  3. 布局定位;

  4. 图层分层;

  5. 图层绘制;

  6. 显示;

构建DOM树

HTML文件的结构没法被浏览器理解,所以先要把HTML中的标签变成一个可以给JS使用的结构。

在控制台可以尝试打印document,这就是解析出来的DOM树。

样式计算

CSS文件一样没法被浏览器直接理解,所以首先把CSS解析成样式表。 这三类样式都会被解析:

  • 通过 link 引用的外部 CSS 文件

  • <style>标签内的样式

  • 元素的 style 属性内嵌的 CSS

在控制台打印document.styleSheets,这就是解析出的样式表。

利用这份样式表,我们可以计算出DOM树中每个节点的样式。之所以叫计算,是因为每个元素要继承其父元素的属性。

<style>
    span {
        color: red
    }
    div {
        font-size: 30px
    }
</style>
<div>
    <span>年年</span>
</div>

比如上面的年年,不仅要接受span设定的样式,还要继承div设置的。

DOM树中的节点有了样式,现在被叫做渲染树。

为什么要把CSS放在头部,js放在body的尾部

在解析HTML的过程中,遇到需要加载的资源特点如下:

  • CSS资源异步下载,下载和解析都不会阻塞构建dom树<link href='./style.css' rel='stylesheet'/>

  • JS资源同步下载,下载和执行都会阻塞构建dom树<script src='./index.js'/>

因为这样的特性,往往推荐将CSS样式表放在head头部,js文件放在body尾部,使得渲染能尽早开始。

CSS会阻塞HTML解析吗

上文提到页面渲染是渲染进程的任务,这个渲染进程中又细分为GUI渲染线程和JS线程。

解析HTML生成DOM树,解析CSS生成样式表以及后面去生成布局树、图层树都是由GUI渲染线程去完成的,这个线程可以一边解析HTML,一边解析CSS,这两个是不会冲突的,所以也提倡把CSS在头部引入。

但是在JS线程执行时,GUI渲染线程没有办法去解析HTML,这是因为JS可以操作DOM,如果两者同时进行可能引起冲突。如果这时JS去修改了样式,那此时CSS的解析和JS的执行也没法同时进行了,会先等CSS解析完成,再去执行JS,最后再去解析HTML。

从这个角度来看,CSS有可能阻塞HTML的解析。

预加载扫描器是什么

上面提到的外链资源,不论是同步加载JS还是异步加载CSS、图片等,都要到HTML解析到这个标签才能开始,这似乎不是一种很好的方式。实际上,从2008年开始,浏览器开始逐步实现了预加载扫描器:在拿到HTML文档的时候,先扫描整个文档,把CSS、JS、图片和web字体等提前下载。

js脚本引入时async和defer有什么差别

预加载扫描器解决了JS同步加载阻塞HTML解析的问题,但是我们还没有解决JS执行阻塞HTML解析的问题。所有有了async和defer属性。

  • 没有 defer 或 async,浏览器会立即加载并执行指定的脚本

  • async 属性表示异步执行引入的 JavaScript,经加载好,就会开始执行

  • defer 属性表示延迟到DOM解析完成,再执行引入的 JS

在加载多个JS脚本的时候,async是无顺序的执行,而defer是有顺序的执行

preload、prefetch有什么区别

之前提到过预加载扫描器,它能提前加载页面需要的资源,但这一功能只对特定写法的外链生效,并且我们没有办法按照自己的想法给重要的资源一个更高的优先级,所以有了preload和prefetch。

  1. preload:以高优先级为当前页面加载资源;

  2. prefetch:以低优先级为后面的页面加载未来需要的资源,只会在空闲时才去加载;

无论是preload还是prefetch,都只会加载,不会执行,如果预加载的资源被服务器设置了可以缓存cache-control那么会进入磁盘,反之只会被保存在内存中。

具体使用如下:

<head>
    <!-- 文件加载 -->
    <link rel="preload" href="main.js" as="script">
    <link rel="prefetch" href="news.js" as="script">
</head>

<body>
    <h1>hello world!</h1>
    <!-- 文件文件执行 -->
    <script src="main.js" defer></script>
</body>

为了保证资源正确被预加载,使用时需要注意:

  1. preload的资源应该在当前页面立即使用,如果不加上script标签执行预加载的资源,控制台中会显示警告,提示预加载的资源在当前页面没有被引用;

  2. prefetch的目的是取未来会使用的资源,所以当用户从A页面跳转到B页面时,进行中的preload的资源会被中断,而prefetch不会;

  3. 使用preload时,应配合as属性,表示该资源的优先级,使用 as="style" 属性将获得最高的优先级,as ="script"将获得低优先级或中优先级,其他可以取的值有font/image/audio/video

  4. preload字体时要加上crossorigin属性,即使没有跨域,否则会重复加载:

<link rel="preload href="font.woff" as="font" crossorigin>

此外,这两种预加载资源不仅可以通过HTML标签设置,还可以通过js设置

var res = document.createElement("link"); 
res.rel = "preload"; 
res.as = "style"; 
res.href = "css/mystyles.css"; 
document.head.appendChild(res); 

以及 HTTP 响应头:

Link: </uploads/images/pic.png>; rel=prefetch

布局定位

上面详细的讲述了HTML和CSS加载、解析过程,现在我们的渲染树中的节点有了样式,但是不知道要画在哪个位置。所以还需要另外一颗布局树确定元素的几何定位。

布局树只取渲染树中的可见元素,意味着head标签,display:none的元素不会被添加。

图层分层

现在我们有了布局树,但依旧不能直接开始绘制,在此之前需要分层,生成一棵对应的图层树。浏览器的页面实际上被分成了很多图层,这些图层叠加后合成了最终的页面。

因为页面中有很多复杂的效果,如一些复杂的 3D 变换、页面滚动,或者使用 z-index 做 z 轴排序等,我们希望能更加方便地实现这些效果。

并不是布局树的每个节点都能生成一个图层,如果一个节点没有自己的层,那么这个节点就从属于父节点的图层

通常满足下面两点中任意一点的元素就可以被提升为单独的一个图层。

1、拥有层叠上下文属性的元素会被提升为单独的一层:明确定位属性position的元素、定义透明属性opacity的元素、使用 CSS 滤镜filter的元素等,都拥有层叠上下文属性。

2、需要剪裁(clip)的地方也会被创建为图层overflow

在chrome的开发者工具:更多选项-更多工具-Layers可以看到图层的分层情况。

图层绘制

在完成图层树的构建之后,接下来终于到对每个图层进行绘制。 首先会把图层拆解成一个一个的绘制指令,排布成一个绘制列表,在上文提到的开发者工具的Layers面板中,点击detail中的profiler可以看到绘制列表。

至此,渲染进程中的主线程——GUI渲染线程已经完成了它所有任务,接下来交给渲染进程中的合成现成。

合成线程接下来会把视口拆分成图快,把图块转换成位图。

至此,渲染进程的工作全部完成,接下来会把生成的位图还给浏览器进程,最后在页面上显示。

性能优化,还可以做些什么

本篇不专讲性能优化,只是在这个命题下补充一些常见手段。

预解析、预渲染

除了上文提到的使用preload、prefetch去提前加载,还可以使用DNS PrefetchPrerenderPreconnect

  1. DNS Prefetch:DNS 预解析;

 <link rel="dns-prefetch" href="//fonts.googleapis.com">
  1. preconnect:在一个 HTTP 请求正式发给服务器前预先执行一些操作,这包括 DNS 解析,TLS 协商,TCP 握手;

<link href="https://cdn.domain.com" rel="preconnect" crossorigin>

3. Prerender:获取下个页面所有的资源,在空闲时渲染整个页面;

<link rel="prerender" href="https://www.keycdn.com">

减少回流和重绘

回流是指浏览器需要重新计算样式、布局定位、分层和绘制,回流又被叫重排;

触发回流的操作:

  • 添加或删除可见的DOM元素

  • 元素的位置发生变化

  • 元素的尺寸发生变化

  • 浏览器的窗口尺寸变化

重绘是只重新像素绘制,当元素样式的改变不影响布局时触发。

回流=计算样式+布局+分层+绘制;重绘=绘制。故回流对性能的影响更大

所以应该尽量避免回流和重绘。比如利用GPU加速来实现样式修改,transform/opacity/filters这些属性的修改都不是在主线程完成的,不会重绘,更不会回流。

结语

把“URL输入到渲染”整个过程讲完,回到开头几个比较刁钻的问题,在文中都不难找到答案:

  1. 浏览器将输入内容解析后,拼接成完整的URL,其中的参数使用的是UTF-8编码,也就是我们开发时会常用的encodeURI和encodeURIComponent两个函数,其中encodeURI是对完整URL编码,encodeURIComponent是对URL参数部分编码,要求会更严格;

  2. 浏览器缓存的disk cache和memory cache分别是从磁盘读取和从内存中读取,通常刷新页面会直接从内存读,而关闭tab后重新打开是从磁盘读;

  3. 预加载prefetch是在空闲时间,以低优先级加载后续页面用到的资源;而preload是以高优先级提前加载当前页面需要的资源;

  4. 脚本的async是指异步加载,完成加载立刻执行,defer是异步加载,完成HTML解析后再执行;

  5. TCP握手需要三次的三次是为了保证客户端的存活,防止服务端资源的浪费,挥手要四次是因为TCP是双工通信,每一个方向的连接释放、应答各需要一次;

  6. HTTPS的握手是为了协商出一个对称密钥,双方一共发送三个随机数,利用这三个随机数计算出只有双方知道的密钥,正式通信的内容都是用这个密钥进行加密的;

如果这篇文章对你有帮助,帮我点个赞呗~这对我很重要

(点个在看更好!)

### 使用 Sa-Token 实现登录操作 为了实现基于 Sa-Token 的用户登录验证机制,需遵循特定流程来确保安全性与功能性。具体而言,在用户通过浏览器发送带有 Token 的请求时,该框架能够自动拦截并校验此令牌的有效性[^2]。 #### 登录接口设计 创建一个用于处理用户登录逻辑的服务端 API 接口: ```java @PostMapping("/login") public JsonResult login(@RequestParam String username, @RequestParam String password){ // 验证用户名密码是否正确 (此处省略业务逻辑) // 如果账号密码都匹配成功,则发放 token 给前端 StpUtil.login(userId); return JsonResult.ok().setData(StpUtil.getTokenInfo()); } ``` 上述代码片段展示了如何构建一个简单的 POST 请求处理器,负责接收来自客户端的身份凭证参数,并在确认无误的情况下调用 `StpUtil.login()` 方法为当前会话分配唯一的身份标识符——Token[^1]。 #### 前端获取 Token 并存储于 Cookie 或 LocalStorage 中 一旦服务器返回有效的响应数据包给到前端应用层面上之后,应当立即将其中所含有的访令牌妥善保存起来以便后续发起其他受保护资源请求时能顺利附带上传递给服务端完成鉴权过程。 对于 Web 应用程序来说,通常会选择把接收到的新鲜出炉的 Token 存入 HTTP-only Cookies 内部或者利用 JavaScript 提供的 localStorage/sessionStorage 对象来进行持久化管理。 #### 后续请求携带 Token 每当应用程序准备向远程服务器发出新的 AJAX 调用或者其他形式的数据交换指令之前,请务必记得从本地储存空间读取出先前获得过的有效 Token 字符串,并将其作为 Authorization 头字段的一部分附加至每一个待发送出去的消息体里头去。 例如,在使用 Axios 发起 GET 请求前设置默认头部信息如下所示: ```javascript axios.defaults.headers.common['Authorization'] = 'Bearer ' + getTokenFromLocalStorage(); ``` 这样做的目的是为了让目标主机能够在第一时间识别出本次连接是由哪位已授权成功的个体发起的,从而允许其正常访那些被标记为私密级别的网页内容或 RESTful APIs 端点地址集合之一成员对象实例资源实体记录项详情页面视图组件单元格表格行列表项目条目元素节点位置坐标方位地理区域范围边界轮廓形状大小尺寸比例尺度量衡单位标准规格型号版本迭代更新频率周期时间戳日期区间间隔跨度长度宽度高度深度面积体积质量重量密度浓度温度湿度气压海拔高度经度纬度地理位置定位导航地图路径轨迹路线行程距离近似估算测量计算公式算法模型理论概念定义描述解释说明备注注解评论反馈意见建议改进措施方案策略规划计划安排部署实施执行落实到位程度效果影响意义价值贡献作用地位重要紧急优先级权重系数因子变量参数属性特征特性特点优点优势特长专长技能技巧经验案例研究分析总结归纳推理演绎论证证明证据依据来源出处参考资料文献书目索引目录清单列表枚举分类分组分级层次结构体系架构模式范型模板样板样本例子示范展示呈现表现表达传达传递传播扩散蔓延扩展延伸扩大放大缩小减少降低升高提高提升增强强化加强巩固稳定平衡协调配合协作合作交流沟通联系关联关系网络系统平台环境背景条件情景场景场合情况状况状态性质本质内涵外延表意示意指示指引指导引导带领率领统领管辖治理管理控制调节调整优化改善改进建设发展进步成长成熟完善健全完备齐全完整全面广泛普遍常见一般特殊个别独特唯一单数复数多数少数部分整体全部总体全局局部细节细微微小巨大庞大宏大广阔宽广深远深邃浅显易懂难理解复杂简单简化简化版精简版浓缩精华摘要概述综述论述论说议论讨论辩论争辩争论争议分歧差异区别区分辨别辨认认识了解掌握熟悉精通擅长善于巧于妙手回春药到病除一针见血切中要害直击痛点解决题提供帮助给予支持鼓励激励鼓舞士气振奋精神焕发活力展现魅力散发吸引力引起注意吸引眼球夺人耳目令人瞩目让人刮目相看印象深刻难以忘怀记忆犹新历久弥新永志不忘铭记心中刻骨铭心念念不忘耿耿于怀萦绕心头挥之不去如影随形形影不离寸步不离紧紧跟随紧跟不舍紧追慢赶穷追猛打锲而不舍持之以恒坚持不懈百折不挠勇往直前奋不顾身冲锋陷阵披荆斩棘乘风破浪扬帆远航驶向未来迎接挑战应对变化适应新形势把握机遇抓住机会创造奇迹谱写华章书写辉煌成就梦想圆梦成真心想事成万事如意顺心遂愿幸福安康平安喜乐笑口常开欢乐无限快乐无穷享受生活热爱生命珍惜时光感恩戴德回报社会奉献爱心传递温暖播撒希望点亮心灵照亮世界改变命运扭转乾坤重塑人生重拾信心重建家园复兴中华振兴华夏光大中华民族屹立东方傲然挺立巍峨耸立高高矗立稳稳站立牢牢扎根深深植根扎扎实实脚踏实地实事求是求真务实开拓创新锐意进取积极向上乐观开朗阳光明媚灿烂辉煌光辉灿烂熠熠生辉闪闪发光发亮耀眼夺目光芒四射辐射四周普照大地沐浴恩泽蒙受庇护受到照顾得到关怀感受到爱体会到情分享喜悦共同庆祝携手同行齐心协力众志成城团结一心万众一心同舟共济风雨同舟患难与共生死攸关危急时刻关键时刻决定胜负成败得失输赢较量竞争竞赛比赛竞技对抗角逐争夺抢夺夺取占领占据掌控操纵驾驭驾驶引领领航掌舵操盘把控把握时机机不可失时不我待稍纵即逝转瞬即逝弹指之间刹那间一瞬间眨眼工夫瞬间片刻须臾俄顷少倾斯须旋踵反顾回顾回想回忆往事追溯历史缅怀先烈纪念英雄致敬楷模学习榜样效仿模范追随偶像崇拜明星追捧网红追逐潮流时尚追求流行趋势引领风尚树立标杆设立典范建立标准制定规则确立原则坚持立场坚定信念执着追求不懈努力持续奋斗不断前进永远
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值