Node.js stream模块（二）可写流

客官°小女子只卖身不卖艺 2023-10-01 16:03 12阅读 0赞

**目录**

数据消费者

可写流Writable

\_write方法

write方法基本使用

write方法执行流程

write缓存流程的意义

state.buffered缓冲区可以无限缓存吗？

state.buffered缓冲区缓存数据如何消费？

drain事件

end方法

--------------------

## 数据消费者 ##

前面介绍了stream模块的可读流stream.Readable，通过可读流的工作模式，我们可以知道可读流其实是数据生产者，而且必须要有消费者通过监听data事件或者监听readable事件调用read方法去消费数据，才能触发可读流进行数据生产。即消费拉动生产。

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16][]

我们需要搞清楚上面程序中，谁是消费者。

监听data事件？data事件回调函数？console.log？

其实纯粹的消费者定义，应该是 单纯消费数据的人。消费者不应该操心数据的生产工作，而是只关注数据的消费。所以上面console.log算是一个消费者。

那么监听data事件算是什么呢？

监听data事件能够取出可读流对象缓冲区中的数据给自身回调函数作为参数，如果没有消费者消费，则数据被丢弃。

监听data事件的行为像是一个配送员：

消费者网上下单到某商店购买商品，被一个配送员接单，然后配送员到达商店，催出商店给货，商店库存发现商品不够就回去工厂调货，调到货后，加入商店库存，或者直接交给配送员，配送员开开心心的送货，结果发现是个假单，没有消费者，而配送员无法消费商品，所以直接丢了。

console.log 才是真正的数据消费者，我们知道console.log可以将入参转为字符串后在控制台打印。而控制台打印算是标准输出流。所以其实真正消费者是process.stdout。而process.stdout就是一个可写流对象。那么可写流对象如何进行数据消费呢？我们又如何创建一个自定义的可写流对象呢？

## 可写流Writable ##

在stream模块下，有一个Writable抽象类，它有一个抽象方法\_write，我们一般用自定义类继承stream.Writable，并重写\_write方法。

### \_write方法 ###

可写流对象的\_write方法用于书写消费数据的逻辑，作用和可读流的\_read相反，可读流的\_read是从数据源中读数据，而可写流的\_write可以理解为向数据源中写数据。那么可写流的\_write写的数据来源于哪呢？

### write方法基本使用 ###

Writable原型上有一个write方法，该方法可以接收三个参数，分别是chunk（写入的数据），encoding（编码），callback（写入完成后的回调），返回一个布尔值。

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 1][]

write方法可以调用多次

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 2][]

write方法每次调用都会同步地返回一个布尔值

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 3][]

另外write方法的chunk参数只能是字符串，Buffer对象，字节数组

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 4][]

### write方法执行流程 ###

Writable.prototype.write = function(chunk, encoding, cb) {
      return _write(this, chunk, encoding, cb) === true;
    };

// If we're already writing something, then just put this
    // in the queue, and wait our turn.  Otherwise, call _write
    // If we return false, then we need a drain event, so set that flag.
    function writeOrBuffer(stream, state, chunk, encoding, callback) {
      const len = state.objectMode ? 1 : chunk.length;
    
      state.length += len;
    
      // stream._write resets state.length
      const ret = state.length < state.highWaterMark;
      // We must ensure that previous needDrain will not be reset to false.
      if (!ret)
        state.needDrain = true;
    
      if (state.writing || state.corked || state.errored || !state.constructed) {
        state.buffered.push({ chunk, encoding, callback });
        if (state.allBuffers && encoding !== 'buffer') {
          state.allBuffers = false;
        }
        if (state.allNoop && callback !== nop) {
          state.allNoop = false;
        }
      } else {
        state.writelen = len;
        state.writecb = callback;
        state.writing = true;
        state.sync = true;
        stream._write(chunk, encoding, state.onwrite);
        state.sync = false;
      }
    
      // Return false if errored or destroyed in order to break
      // any synchronous while(stream.write(data)) loops.
      return ret && !state.errored && !state.destroyed;
    }

走读以上代码，我们可以分析出：write方法写入的数据\{chunk, encoding, callback\}可能会被缓存在state.buffered中，即可写流对象缓冲区（队列结构）中，也可能直接被传递给可写流对象重写的\_write方法直接消费。即上面WriteOrBuffer方法的逻辑。

WriteOrBuffer方法中如果满足下面条件

if (state.writing || state.corked || state.errored || !state.constructed)

则，write方法写入的数据会被缓存在state.buffered中，否则，直接传给\_write消费。

<table style="width:500px;"> 
 <tbody> 
  <tr> 
   <td>可读流对象_writableState下的属性</td> 
   <td>初值（可读流对象刚创建时）</td> 
  </tr> 
  <tr> 
   <td>writing</td> 
   <td>false</td> 
  </tr> 
  <tr> 
   <td>corked</td> 
   <td>0</td> 
  </tr> 
  <tr> 
   <td>errored</td> 
   <td>null</td> 
  </tr> 
  <tr> 
   <td>constructed</td> 
   <td>true</td> 
  </tr> 
 </tbody> 
</table>

所以默认情况下，上面判断条件为false，即第一次write写入的数据不会被缓存到state.buffered中，而是会被\_write消费。

而在write方法执行过程中，只有state.writing存在被置为true的机会，此机会出现在\_write的回调state.onwrite执行前，当state.onwrite执行之后，state.writing就会被重置为false

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 5][]

其实这里的

stream.\_write(chunk, encoding, state.onwrite)

是对我们重写的\_write的调用

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 6][]

也就是说state.onwrite会被传递给callback。

如果重写的\_write中callback异步执行的话，则在同步过程中，state.writing不会被置为false，而是一直保持为true。

那么callback存在异步执行的情况吗？

我们可以思考一下，可写流的具体实现无非就是文件可写流和网络可写流，而这些具体可写流都涉及了I/O操作，而在Node.js中都是异步I/O。

举个例子，文件可写流的\_write重写逻辑必然是向文件中写入数据，需要调用fs.write，而state.onwrite必然是作为fs.write的回调，则必然是异步执行的。

所以state.onwrite异步执行的情况会占很大比例。

我们这里可以模拟下state.onwrite的异步执行，让write走进缓存流程

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 7][]

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 8][]

当state.onwrite异步执行后，\_write执行完，state.writing还是为true，所以下一次write可以进入缓存流程

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 9][]

### write缓存流程的意义 ###

我们可以思考一下缓存流程的意义在什么地方？

我们以文件可写流这个具体实现来思考，如果不存在缓存流程，则每次文件可写流对象fws调用write方法后，都会直接触发\_write执行，而\_write中是具体的写文件逻辑fs.write，而fs.write会在底层libuv库的线程池中申请一个线程去跟踪异步I/O操作。

fws.write是同步执行，但是每此fws.write都会申请一个线程去跟踪异步I/O。

所以当发送大量的fws.write后，会开启大量线程和大量I/O操作，对系统资源占用极大。

另外，fws.write多次调用，每次调用都是异步I/O写文件，那么必然会发生乱序写入，但是我们期望的是写入数据的顺序和fws.write的调用顺序是一致的。

而想要保证异步任务串行，则必然是前一个异步任务执行完，再执行后一个异步任务。

以前解决异步任务串行的思路是Promise，async await，但是这里给出了另一只异步串行的思路，即将靠后的异步任务缓存起来。等前一个异步任务执行完了，再从缓存中取出队头的异步任务。

所以write缓存流程的意义有两个：

1、避免了大量异步I/O被同时段开启，避免了占用大量线程和I/O资源

2、保证了write执行顺序就是写入数据的顺序

此时有两个问题：

### state.buffered缓冲区可以无限缓存吗？ ###

write方法的缓存流程中，write数据会被缓存在state.buffered缓冲区中，我们可以按照文件可写流的思路思考一下：

既然第一次fws.write由于state.writing为false会进入消费流程，即直接调用\_write，底层开启一个异步I/O写文件。而由于是异步的，所以\_write的回调state.onwrite不会在同步流程被调用，所以第一次write之后，并在同步流程中，state.writing会一直保持为true。

即同步流程中，第一次write之后，的其余次write都会将数据缓存到state.buffered中。

那么又引发了一个新的问题？当我们大量的调用fws.write时，缓冲区state.buffered可以实现无限缓存吗？

答案是：肯定不可能。无限缓存必然导致内存溢出。

那么如何防止缓冲区内存溢出呢？

利用水位线，可写流为缓冲区定义了一个水位线参数highWaterMark，该值默认为16KB，当缓冲区缓存的数据量超过16KB后，就代表如果再缓存的话就有可能发生内存溢出风险，此时不再建议继续调用write方法。

而当write调用后，底层执行发现缓冲区数据量超过水位线值，则write方法会同步地返回false，如果缓冲区数据量没有超过水位线，则write方法会同步地返回true。

即wirte返回false，表示后面继续wirte可能会发生内存溢出，write返回true，表示可以继续调用write。

我们需要注意地是write是同步返回地布尔值，这是为什么呢?因为write是同步地将数据加入缓存的。

还有一个注意是：缓存区的数据量是如何计算的？

计算逻辑是：缓冲区数据量有一个属性length对应，默认值为0，每当write方法调用，就会计算length += chunk.length，每当state.onwrite（\_write回调）执行，就会计算length -= chunk.length。所以第一次write后，length += chunk.length，第一次write的\_write中回调是同步执行的，所以里面length -= chunk.length。而第二次之后的write调用，都会同步地length += chunk.length，但是第二次之后write都是异步地调用\_write的回调，所以同步流程下不会减少length。此时就有可能发生 length >= highWaterMark。即wirte会同步返回false。

那么write返回false，是否意味着之后调用write，write的数据不会被加入缓冲区呢？

答案是：不是的，write返回false更多地是一种预警，并不是说水量超过水位线就一定会发生洪灾，我们一般不会将水位线设为缓冲区的最大容量，那么水位线就没有意义了，即一超过水位线，就内存溢出了。所以wirte返回false之后，我们调用write依旧会将数据加入缓冲区。只是不推荐，会加大发生内存溢出的风险。

那么wirte返回false的作用是啥？

这要结合可读流data事件和可写流drain事件来说，其实就是背压机制，后续会有说明。

我们再来思考第二个问题

### state.buffered缓冲区缓存数据如何消费？ ###

其实可写流消费数据的途径只有一个，那就是重写的\_write方法，即调用了\_write方法就实现了可写流数据的消费。

而state.buffered中的数据也只能被\_write消费。

我们回忆下，第一次write时，走的非缓存流程，其中会调用\_write

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 10][]

但是我们发现一个奇怪的问题，为什么此时传递给\_write的回调并不是我们传入的callback，而是state.onwrite。

下面是onwrite的代码。

通过走读onwrite代码逻辑，我们可知：

state.onwrite如果被传入\_write后同步执行，则state.writing会同步变为false,则第二次write会继续走非缓存消费。

state.onwrite如果被传入\_write后异步执行，则state.writing在同步执行过程中继续保持true,则第二次write会走缓存。

所以state.onwrite代替原有callback的第一个原因就是：控制wirte执行走向，即走缓存消费，还是直接消费

如果走的缓存消费，则state.onwrite必然是被异步执行的，所以：

当同步代码执行完后，state.onwrite会被从异步任务队列中被事件循环捞出来执行。

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 11][]

通过debug可以发现onwrite之后进入了clearBuffer方法，通过名字就可以看出clearBuffer适用于清空state.buffered的。而clearBuffer会调用doWrite，doWrite会调用\_write进行数据消费。

所以state.buffered缓冲区中的数据虽然是同步加入的，但是都是异步被消费的。验证如下:

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 12][]

所以：第一次write会走直接消费流程，但是其指定给\_write的回调state.onwrite中，必然会触发clearBuffer，无论state.onwrite是被同步执行还是异步执行。而clearBuffer的意思就是清空缓冲区数据，而clearBuffer中还会调用\_write，来实现消费被清空出来的数据。

即第二次及后续的write加入到缓冲区中的数据，都是被第一次write的指定给\_write的回调state.onwrite的清空并消费。而state.onwrite能消费的原因是：state.onwrite中也调用了\_write。

### drain事件 ###

当state.buffered中数据被清空完，即state.onwrite执行最后，会调用afterWrite方法

在afterWrite方法会判断state.needDrain，若为true（且可写流非结束态）则触发drain事件。

需要注意的是，state.needDrain是在write调用时，如果写入的数据超过了缓冲区水位线，则state.needDrain就会被设为true，

write->writeOrBuffer

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 13][]

可以发现 state.needDrain和write方法的同步返回值是刚好相反的。

write返回false，state.needDrain值为true。

write返回true，state.needDrain值为false。

通过代入afterWrite方法逻辑可以发现，state.needDrain是作为是否触发可写流对象的drain事件的判断条件。即真的是need drain?

那么drain事件又是啥呢？

我们思考一个问题，当我们清空了缓冲区之后，我们期望下一步操作是啥？

答：期望继续调用wirte，因为此时不会存在缓冲区内存溢出的风险了。

所以最终思路是这样的：write返回false，我们就不要调用后续wirte了，因为继续调用可能会触发内存溢出，但是当缓冲区清空后，我们就可以继续调用wirte了，因为此时再调用write不会触发内存溢出。

那么可写流如何通知外界缓冲区清空了呢？这和write同步返回false不同，缓冲区的清空动作一般都是异步流程完成的。

所以必然要借助事件驱动了。所以在afterWrite中，即缓冲区清空后，如果发现state.needDrain为true，则表示需要触发drain事件，来通知外部缓冲区清空了。

所以drain事件正是可写流通知外界可以继续write的方式

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 14][]

总结：可写流的write方法可以同步的返回true/false，来告知外界缓冲区使用情况，如果write返回false，则外界最好不要再调用write了。给可写流一点事件，可写流通过onwrite来清空一下缓冲区，当清空完成后，为了实时告知外界，所以借助了事件驱动，触发drain事件，所以外界只需要监听drain事件就知道可以继续写入了。

### end方法 ###

那么可写流对象如何知道不会再有数据写入了呢？即如何标志写入结束呢？

Writable原型上有一个end方法，当可写流对象调用end方法后，标志可写流对象停止写入数据，之后再调用write方法就会报错。

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 15][]end方法参数和write方法一致。但是end方法返回值是当前可写流对象。

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 16][]

[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/de83f8206c114744b49955fb2c07609b.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 1]: https://img-blog.csdnimg.cn/1fae70c94184452c94454b7b3b4a4c69.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 2]: https://img-blog.csdnimg.cn/0b7bba8ffe3e40c8bb95b8c0a8e8fb40.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 3]: https://img-blog.csdnimg.cn/2d0059855b9d4c01afd338a96a48d903.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 4]: https://img-blog.csdnimg.cn/0b14c287c6284777b550ca34536139ae.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 5]: https://img-blog.csdnimg.cn/053115bdb9eb49dcb7a289f3f5a52874.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 6]: https://img-blog.csdnimg.cn/a8478153d08845a7945224196e81062d.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 7]: https://img-blog.csdnimg.cn/3fcf82f2c497420793366f3b1ca9a801.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 8]: https://img-blog.csdnimg.cn/3622cf2357e643ba8dcb3c0fecf1af4a.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 9]: https://img-blog.csdnimg.cn/3c9eaffc9a824c9b9de2a0d62a54a8f3.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 10]: https://img-blog.csdnimg.cn/3cf3aa0baa3a4b349f0446f4c3f431da.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 11]: https://img-blog.csdnimg.cn/4c08ed628db54595be0a8a9ca05e60a9.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 12]: https://img-blog.csdnimg.cn/ef670f9b90af4c3fb9a1de4054e11832.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 13]: https://img-blog.csdnimg.cn/a4bb14ff71124c1d901dabdffa58b24b.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 14]: https://img-blog.csdnimg.cn/a7da0d941bf74a90807e33e5f198e157.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 15]: https://img-blog.csdnimg.cn/58b0a8fb49f44ba1a618660f896d06b2.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBA5LyP5Z-O5LmL5aSW_size_20_color_FFFFFF_t_70_g_se_x_16 16]: https://img-blog.csdnimg.cn/461811d2bd064af6971ff7e369681ce9.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5LyP5Z-O5LmL5aSW,size_20,color_FFFFFF,t_70,g_se,x_16