【C++】智能指针

桃扇骨 2024-04-27 07:45 28阅读 0赞

#### 文章目录 ####

*  一、为什么需要智能指针？
 *  二、内存泄漏
 *   *  1. 什么是内存泄漏？内存泄露的危害？
     *  2. 内存泄漏的分类
     *  3. 如何检测内存泄漏
     *  4. 如果避免内存泄漏
 *  三、智能指针的使用及原理
 *   *  1. 智能指针的概念
     *  2. auto\_ptr
     *  3. unique\_ptr
     *  4. shared\_ptr（重点）
     *  5. weak\_ptr
 *  四、定制删除器

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

## 一、为什么需要智能指针？ ##

因为C++没有垃圾回收机制，资源需要自己手动管理。同时，异常会导致执行流乱跳，所以C++异常非常容易导致诸如内存泄漏这样的安全问题。

int div()
    {
        
    	int a, b;
    	cin >> a >> b;
    	if (b == 0)
    		throw invalid_argument("除0错误");
    	return a / b;
    }
    void Func()
    {
        
    	int* p1 = new int;
    	int* p2 = new int;
    	cout << div() << endl;
    	delete p1;
    	delete p2;
    	cout << "release pointer" << endl;
    }
    int main()
    {
        
    	try
    	{
        
    		Func();
    	}
    	catch (exception& e)
    	{
        
    		cout << e.what() << endl;
    	}
    	return 0;
    }

在上面的程序中，如果div函数抛异常，会导致程序直接跳转到main函数的catch语句处，p1和p2指向的空间未释放。

![在这里插入图片描述][6adb5e6d1295440880a6011ef9ea801d.png]

对于这种情况，我们只能在Func中对p2和和div进行捕获，然后再将p1和p2释放，最后再将异常重新抛出。如下：

![在这里插入图片描述][91a49a0b370e4dc3a755c2e0228cb0c8.png]

虽然这样可以解决问题，但是这样的代码写起来不仅难受，而且也让别人看着难受。同时，这里如果再多添加几个申请空间的指针p3、p4…呢？因此，C++设计出了智能指针。

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

## 二、内存泄漏 ##

### 1. 什么是内存泄漏？内存泄露的危害？ ###

**`什么是内存泄漏：`** 内存泄漏指因为疏忽或错误造成程序未能释放已经不再使用的内存的情况。内  
存泄漏并不是指内存在物理上的消失，而是应用程序分配某段内存后，因为设计错误，失去了对  
该段内存的控制，因而造成了内存的浪费。

**`内存泄漏的危害：`** 长期运行的程序出现内存泄漏，影响很大，如操作系统、后台服务等等，出现  
内存泄漏会导致响应越来越慢，最终卡死。

![在这里插入图片描述][c5a01c8fb76b46e5adfb95bdf9421dae.png]

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

### 2. 内存泄漏的分类 ###

**`C/C++`** 程序中一般我们关心两种方面的内存泄漏：

*  **`堆内存泄漏(Heap leak)`**  
    堆内存指的是程序执行中依据须要分配通过malloc / calloc / realloc / new等从堆中分配的一块内存，用完后必须通过调用相应的 free或者delete 删掉。假设程序的设计错误导致这部分内存没有被释放，那么以后这部分空间将无法再被使用，就会产生Heap Leak。
 *  **`系统资源泄漏`**  
    指程序使用系统分配的资源，比方套接字、文件描述符、管道等没有使用对应的函数释放  
    掉，导致系统资源的浪费，严重可导致系统效能减少，系统执行不稳定。

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

### 3. 如何检测内存泄漏 ###

*  在Linux下内存泄漏检测：[Linux下几款内存泄漏检测工具][Linux]
 *  在Windows下使用第三方工具：[VLD工具说明][VLD]
 *  其他工具：[内存泄漏工具比较][Link 1]

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

### 4. 如果避免内存泄漏 ###

1.  工程前期良好的设计规范，养成良好的编码规范，申请的内存空间记着匹配的去释放。ps：  
    这个理想状态。但是如果碰上异常时，就算注意释放了，还是可能会出问题。需要下一条智  
    能指针来管理才有保证。
2.  采用RAII思想或者智能指针来管理资源。
3.  有些公司内部规范使用内部实现的私有内存管理库。这套库自带内存泄漏检测的功能选项。
4.  出问题了使用内存泄漏工具检测。ps：不过很多工具都不够靠谱，或者收费昂贵。

`总结一下:`

内存泄漏非常常见，解决方案分为两种：

1.  事前预防型。如智能指针等。
2.  事后查错型。如泄漏检测工具。

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

## 三、智能指针的使用及原理 ##

### 1. 智能指针的概念 ###

**智能指针** 本质上是一个类，这个类的成员函数根据其功能被分为两类：

? **RAII**

**`RAII（Resource Acquisition Is Initialization）`** 是一种利用对象生命周期来控制程序资源（如内存、文件句柄、网络连接、互斥量等等）的简单技术。

*  在对象构造时获取资源，接着控制对资源的访问使之在对象的生命周期内始终保持有效
 *  最后在对象析构的时候释放资源。

借此，我们实际上把管理一份资源的责任托管给了一个对象。这种做法有两大好处：

1.  不需要显示的释放资源。
2.  对象所需要的资源在其生命周期内始终保持有效。

简单来说，RAII就是类的构造函数和析构函数，我们将申请到的资源通过构造函数托付给类的对象来管理，然后在类对象销毁调用析构函数时自动释放该资源，在构造和析构期间该资源可以始终保存有效。

? **支持指针的各种行为**

一般我们申请一份资源都是为了使用该资源，所以我们需要能够通过类对象来管理资源，还需要通过类对象来对资源进行各种操作，即通过运算符重载来让类对象支持指针的各种行为 `(* -> [])`

下面是一个简单的智能指针示例：

template <class T>
    class SmartPtr 
    {
        
    public:
    	SmartPtr(T* ptr)
    		:_ptr(ptr)
    	{
        }
    
    	T& operator*()
    	{
        
    		return *_ptr;
    	}
    
    	T* operator->()
    	{
        
    		return _ptr;
    	}
    
    	~SmartPtr()
    	{
        
    		cout << "delete:" << _ptr << endl;
    		delete _ptr;
    	}
    private:
    	T* _ptr;
    };

![在这里插入图片描述][a3786dc32d8647259e1153c680609ca5.png]

上述的代码，我们将new出来的资源交给类的局部对象，这样在类对象生命周期内该资源都有效，同时我们也可以像使用正常指针那样通过类的对象对资源进行各种操作。当p1或者p2new空间、div函数抛异常时，由于异常发生会正常释放函数的栈空间，所以局部对象会被正常销毁，那么被局部对象管理的资源也就能够正常释放了。

智能指针虽然能够很好的管理资源，但是智能指针的拷贝与赋值是一个很大的问题，它涉及到资源的管理权问题 – 由谁管理、由一个单独管理还是多个共同管理。

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

### 2. auto\_ptr ###

C++98版本的库中就提供了 **`auto_ptr`** 的智能指针。他解决智能指针拷贝的方式是：管理权转让，使用当前对象拷贝构造一个新对象时，会将当前对象管理的资源交给新对象，然后将自己的资源置空。auto\_ptr最大的问题是它会导致对象悬空，即后面再使用当前对象时，会造成空指针解引用。

![在这里插入图片描述][168eb6f0937a46ed825064e408d1639b.png]

? **auto\_ptr的简单模拟实现：**

template <class T>
    class auto_ptr
    {
        
    public:
    	auto_ptr(T* ptr)
    		:_ptr(ptr)
    	{
        }
    
    	// 拷贝构造
    	auto_ptr(auto_ptr<T>& ap)
    		:_ptr(ap._ptr)
    	{
        
    		ap._ptr = nullptr;
    	}
    	
    	// 赋值运算符重载
    	auto_ptr<T>& operator=(auto_ptr<T>& ap)
    	{
        
    		if (_ptr != ap._ptr)
    		{
        
    			this->~auto_ptr();
    			_ptr = ap._ptr;
    			ap._ptr = nullptr;
    		}
    		return *this;
    	}
    	
    	T& operator*()
    	{
        
    		return *_ptr;
    	}
    
    	T* operator->()
    	{
        
    		return _ptr;
    	}
    
    	~auto_ptr()
    	{
        
    		if (_ptr) {
        
    			delete _ptr;
    		}
    	}
    private:
    	T* _ptr;
    };

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

### 3. unique\_ptr ###

C++11中开始提供更靠谱的 **`unique_ptr`**，他解决拷贝问题的方式是：**直接不允许拷贝—防拷贝**

template <class T>
    class unique_ptr
    {
        
    public:
    	unique_ptr(T* ptr)
    		:_ptr(ptr)
    	{
        }
    
    	T& operator*()
    	{
        
    		return *_ptr;
    	}
    
    	T* operator->()
    	{
        
    		return _ptr;
    	}
    
    	// C++11 语法直接支持删除拷贝构造和赋值重载函数——防拷贝思路
    	unique_ptr(const unique_ptr<T>& up) = delete;
    	unique_ptr<T>& operator=(const unique_ptr<T>& up) = delete;
    
    	~unique_ptr()
    	{
        
    		if (_ptr) {
        
    			cout << "delete: " << _ptr << endl;
    			delete _ptr;
    		}
    	}
    private:
    	T* _ptr;
    };

![在这里插入图片描述][fd6e006f8cb24803bb12f75e60bf9020.png]

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

### 4. shared\_ptr（重点） ###

C++11中开始提供更靠谱的并且支持拷贝的 **`shared_ptr`**，它通过引用计数的方式来解决智能指针的拷贝问题，使得一份资源可以被多个类对象共同管理。同时，shared\_ptr的引用计数是线程安全的。

? **shared\_ptr引用计数问题**

shared\_ptr通过引用计数的方式解决问题的思路如下：

用当前对象拷贝一个新对象时，让新对象与当前对象共同来管理这份资源，并以 `++引用计数` 的方式，来标识这份资源被多少个对象所管理，当对象销毁时，`引用计数--`，但资源并不一定销毁，只有当引用计数为0时才真正销毁。

**`引用计数的设计方式如下：`**

在类中增加一个指针类型的成员变量，该指针指向一块堆空间，空间中保存的是当前资源对应的引用计数，相当于类对象要管理的资源相比之前多了一个 `count –` 这样对于管理不同资源的类对象来说，二者的引用计数不会相互影响；对于管理同一份资源的类来说，引用计数的变化是同步的 (因为引用计数也是资源的一部分)。

template <class T>
    class shared_ptr
    {
        
    public:
    	shared_ptr(T* ptr = nullptr)
    		:_ptr(ptr)
    		,_pcount(new int(1))
    	{
        }
    
    	~shared_ptr()
    	{
        
    		Release();
    	}
    
    	void AddCount()
    	{
        
    		++(*_pcount);
    	}
    
    	// 拷贝构造
    	shared_ptr(const shared_ptr<T>& sp)
    		:_ptr(sp._ptr)
    		,_pcount(sp._pcount)
    	{
        
    		AddCount();
    	}
    
    	void Release()
    	{
        
    		if (--(*_pcount) == 0)
    		{
        
    			if (_ptr) {
        
    				cout << "delete: " << _ptr << endl;
    				delete _ptr;
    			}
    			delete _pcount;
    		}
    	}
    
    	// 赋值运算符重载
    	shared_ptr<T>& operator=(const shared_ptr<T>& sp)
    	{
        
    		if (_ptr != sp._ptr)
    		{
        
    			Release();
    
    			_ptr = sp._ptr;
    			_pcount = sp._pcount;
    			AddCount();
    		}
    		return *this;
    	}
    
    	T& operator*()
    	{
        
    		return *_ptr;
    	}
    
    	T* operator->()
    	{
        
    		return _ptr;
    	}
    
    	T* get() const
    	{
        
    		return _ptr;
    	}
    
    	int use_count()
    	{
        
    		return *_pcount;
    	}
    
    private:
    	T* _ptr;
    	int* _pcount;
    };

![在这里插入图片描述][7541a4dc9b5048958efc14b612c2baef.png]

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

? **shared\_ptr线程安全问题**

在上面的代码中模拟实现的shared\_ptr在多线程环境下可能会发生线程安全问题：

void SharePtrFunc(cjl::shared_ptr<Date>& sp, size_t n, mutex& mtx)
    {
        
    	for (size_t i = 0; i < n; i++)
    	{
        
    		cjl::shared_ptr<Date> copy(sp);
    	}
    }

![在这里插入图片描述][1b009f0220d1441fa723bda85c54bfc6.png]

当我们换成库中的代码时，则不会产生线程安全的问题：

![在这里插入图片描述][61f898f84f9b420b983537636728e94c.png]

`原因如下：`

*  我们使用当前对象拷贝构造一个新的对象来共同管理当前资源时，资源的引用计数会++，当局部对象出作用域销毁时引用计数会–；但是语言级别的++以及–的操作都 非原子 的，因为它们都对应着多条汇编指令；而在多线程环境下，可能一条语句只执行了部分汇编指令该线程就被挂起了，而此时其他线程再来对 count 进行操作就可能会引发线程安全问题；
 *  比如当前count为10，线程A要++count，但是线程A在未将++后的结果即11写入到内存覆盖掉原来的count之前，它就被阻塞了；后面假设又来了50个线程都对count进行了++操作，那么count的值变为了60；但是现在，线程A被重新调度了，那么它会继续完成它之前未做完的事情 (临时数据保存在线程的上下文中)，即将count的值覆盖为11，此时count的值就错乱了，也就是发生了线程安全问题；count–同理。
 *  而库中的 shared\_ptr 的引用计数之所以是线程安全的，是因为它使用了 互斥锁 对引用计数的 ++ 和 – 操作进行了保护，即通过加锁使得多线程只能串行的修改引用计数的值，而不能并行或并发的修改引用计数。

**`注`：加锁和解锁的过程是原子的 (有特殊的一条汇编指令来完成锁状态的修改)，所以锁本身是线程安全的，我们不需要担心锁的安全性。**

我们也可以使用互斥锁将模拟实现的 shared\_ptr 改造为引用计数线程安全版本，需要注意的是：

和引用计数一样，使用互斥锁的方式也是在类中增加一个互斥锁指针类型的成员变量，该变量指向堆上的一块空间；因为我们要保证的是同一份资源中的同一个引用计数只能被多线程串行访问，而不同资源中的两个无关引用计数是可以被并发/并行操作的。

template <class T>
    class shared_ptr
    {
        
    public:
    	shared_ptr(T* ptr = nullptr)
    		:_ptr(ptr)
    		,_pcount(new int(1))
    		,_pmtx(new mutex)
    	{
        }
    
    	~shared_ptr()
    	{
        
    		Release();
    	}
    
    	void AddCount()
    	{
        
    		_pmtx->lock();
    		++(*_pcount);
    		_pmtx->unlock();
    	}
    
    	// 拷贝构造
    	shared_ptr(const shared_ptr<T>& sp)
    		:_ptr(sp._ptr)
    		,_pcount(sp._pcount)
    		,_pmtx(sp._pmtx)
    	{
        
    		AddCount();
    	}
    
    	void Release()
    	{
        
    		_pmtx->lock();
    		bool deleteFlag = false;
    		if (--(*_pcount) == 0)
    		{
        
    			if (_ptr) {
        
    				cout << "delete: " << _ptr << endl;
    				delete _ptr;
    			}
    			delete _pcount;
    			deleteFlag = true;
    		}
    		_pmtx->unlock();
    
    		if (deleteFlag)
    			delete _pmtx;
    	}
    
    	// 赋值运算符重载
    	shared_ptr<T>& operator=(const shared_ptr<T>& sp)
    	{
        
    		if (_ptr != sp._ptr)
    		{
        
    			Release();
    
    			_ptr = sp._ptr;
    			_pcount = sp._pcount;
    			_pmtx = sp._pmtx;
    			AddCount();
    		}
    		return *this;
    	}
    
    	T& operator*()
    	{
        
    		return *_ptr;
    	}
    
    	T* operator->()
    	{
        
    		return _ptr;
    	}
    
    	T* get() const
    	{
        
    		return _ptr;
    	}
    
    	int use_count()
    	{
        
    		return *_pcount;
    	}
    
    private:
    	T* _ptr;
    	int* _pcount;
    	mutex* _pmtx;
    };

![在这里插入图片描述][bb78c66a197b4c2f89ba6775d4d5e928.png]

这里我们需要注意的是：shared\_ptr的引用计数是安全的，因为有互斥锁的存在，但是shared\_ptr的数据资源是不安全的，因为堆上的数据资源的访问诗人处理的，shared\_ptr无法对其进行保护：

![在这里插入图片描述][96d64c209fd342d198d5da0d46d3c145.png]

在这里就需要我们手动加锁来对其进行保护了：

![在这里插入图片描述][a60443e78c0c4a639443b02e498dcf11.png]

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

? **shared\_ptr的循环引用问题**

struct ListNode
    {
        
    	shared_ptr<ListNode> _prev;
    	shared_ptr<ListNode> _next;
    	int _val;
    
    	~ListNode()
    	{
        
    		cout << "~ListNode()" << endl;
    	}
    };
    
    void test_shared_cycle()
    {
        
    	shared_ptr<ListNode> n1(new ListNode);
    	shared_ptr<ListNode> n2(new ListNode);
    }

![在这里插入图片描述][2dc1c52928bd4f0f9609e090abeb5402.png]

没有智能指针时对于new出来的节点我们需要手动管理，但是有了智能指针后， 我们就可以将节点资源交给智能指针对象来管理了。

![在这里插入图片描述][e1020a449b6b4f3eb26f65070a26df86.png]

但是当我们让n1的next指向n2，n2的prev指向n1后，程序发生了内存泄漏。这是因为在当前场景下，发生了shared\_ptr的循环引用。（假设将n1管理的资源称为资源1，将n2管理的资源称为资源2）：

1.  我们 new 出来两个节点分别赋值给交给智能指针对象 n1 和 n2 管理，此时它们的引用计数都为1；
2.  然后我们让 n1->\_next = n2，由于n1->\_next 也是智能指针类型，所以资源2现在由两个对象管理 – n2 + n1->\_next；n2->\_prev = n1 同理，此时资源1也由两个对象管理 – n1 + n2->\_prev；
3.  现在程序执行完毕，n1、n2 自动销毁，则资源1和资源2的引用计数分别减为1，而当引用计数为0时资源才会释放，所以发生内存泄露。图示如下：  
    ![在这里插入图片描述][a7c036efeff244ca8441d89a2c546b74.png]

注：上面示例中，资源其实就是 ListNode 类型的一个节点，而节点 (资源) 释放，节点里面的变量 \_prev 和 \_next 才会释放；而要让节点释放，节点的引用计数必须先减为0，所以就出现了下面这种情况：

*  节点1（资源1）要释放就必须让 n2 里面的 \_prev 不再指向自己，并且只有节点1释放后节点2的引用计数才能减到0；
 *  节点2（资源2）要释放就必须让 n1 里面的 \_next 不再指向自己，并且只有节点2释放后节点1的引用计数才能减到0；
 *  最后，只有当节点的引用计数变为0时节点才会释放。

所以，节点1和节点2就会相互等待对方释放，从而满足自身释放的条件，这就是传说中的循环引用 (这里和死锁有点类型，大家可以和死锁发生的四个条件对比一下)。

当然，如果只有一方引用计数为2则不会发生以上的状况：

![在这里插入图片描述][113b0fc3d89d426d8ee25628a22c3b3c.png]  
![在这里插入图片描述][4add985bfedc4028a217c968f74c59e5.png]

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

### 5. weak\_ptr ###

**`weak_ptr`** 是为了解决shared\_ptr循环引用而专门设计出的一款智能指针，weak\_ptr解决循环引用问题的方式也很简单——不增加资源的引用计数。因此它需要程序员再合适的地方来使用它。

template <class T>
     class weak_ptr
     {
        
     public:
    	 weak_ptr()
    		 :_ptr(nullptr)
    	 {
        }
    
    	 weak_ptr(const shared_ptr<T>& sp)
    		 :_ptr(sp.get())
    	 {
        }
    
    	 T& operator*()
    	 {
        
    		 return *_ptr;
    	 }
    
    	 T* operator->()
    	 {
        
    		 return _ptr;
    	 }
    
    	 T* get()
    	 {
        
    		 return _ptr;
    	 }
     private:
    	 T* _ptr;
     };

![在这里插入图片描述][4b44236d78e343faa2098347835abb59.png]

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

## 四、定制删除器 ##

在前面的代码中，我们都是一次申请一份资源， `new int / new Date`，因此我们析构时可以直接用delete。但是如果一次申请多份资源时。比如：`new int[10]/new vector<int> [10]`，此时我们释放资源时就需要用到`delete[]`了，否则程序就会崩溃。

![在这里插入图片描述][f57aed177c7c4aaa8fcb407595660c6c.png]

C++中通过 **`定制删除器`** 来解决delete 和 delete\[\] 的问题，定制删除器本质上是一个仿函数/函数对象，他的思想和我们之前学习的 `Less/Great/HashFunc` 等仿函数的思想是一样的。

shared\_ptr的这种将删除器作为构造函数参数进行传递的方式让我们可以搭配lambda表达式进行使用，非常方便：

![在这里插入图片描述][0dda558ace5849489cdc5de7cb85e9ef.png]

下面，我们对我们模拟实现的shared\_ptr进行改造，这里我们将其改造为支持通过构造函数传递函数对象进行定制删除的版本：

template <class T>
    class shared_ptr
    {
        
    public:
    	shared_ptr(T* ptr = nullptr)
    		:_ptr(ptr)
    		,_pcount(new int(1))
    		,_pmtx(new mutex)
    	{
        }
    
    	template <class D>
    	shared_ptr(T* ptr, D del)
    		:_ptr(ptr)
    		,_pcount(new int(1))
    		,_pmtx(new mutex)
    		,_del(del)
    	{
        }
    
    	~shared_ptr()
    	{
        
    		Release();
    	}
    
    	void AddCount()
    	{
        
    		_pmtx->lock();
    		++(*_pcount);
    		_pmtx->unlock();
    	}
    
    	// 拷贝构造
    	shared_ptr(const shared_ptr<T>& sp)
    		:_ptr(sp._ptr)
    		,_pcount(sp._pcount)
    		,_pmtx(sp._pmtx)
    	{
        
    		AddCount();
    	}
    
    	void Release()
    	{
        
    		_pmtx->lock();
    		bool deleteFlag = false;
    		if (--(*_pcount) == 0)
    		{
        
    			if (_ptr) {
        
    				_del(_ptr);
    			}
    			delete _pcount;
    			deleteFlag = true;
    		}
    		_pmtx->unlock();
    
    		if (deleteFlag)
    			delete _pmtx;
    	}
    
    	// 赋值运算符重载
    	shared_ptr<T>& operator=(const shared_ptr<T>& sp)
    	{
        
    		if (_ptr != sp._ptr)
    		{
        
    			Release();
    
    			_ptr = sp._ptr;
    			_pcount = sp._pcount;
    			_pmtx = sp._pmtx;
    			AddCount();
    		}
    		return *this;
    	}
    
    	T& operator*()
    	{
        
    		return *_ptr;
    	}
    
    	T* operator->()
    	{
        
    		return _ptr;
    	}
    
    	T* get() const
    	{
        
    		return _ptr;
    	}
    
    	int use_count()
    	{
        
    		return *_pcount;
    	}
    
    private:
    	T* _ptr;
    	int* _pcount;
    	mutex* _pmtx;
    
    	// 包装器
    	function<void(T*)> _del = [](T* ptr) {
        
    		delete ptr;
    	};
    };

![在这里插入图片描述][677525aab3cc4d03a78feb0f6af0a75a.png]

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

[6adb5e6d1295440880a6011ef9ea801d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/de3f0de3e2834697a3384d384d03e384.png
[91a49a0b370e4dc3a755c2e0228cb0c8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/3a06a9522b85428a8840cab1eea96573.png
[c5a01c8fb76b46e5adfb95bdf9421dae.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/54c4191cda8e42fd9f6b71601707cf1d.png
[Linux]: https://blog.csdn.net/gatieme/article/details/51959654
[VLD]: https://blog.csdn.net/GZrhaunt/article/details/56839765
[Link 1]: https://www.cnblogs.com/liangxiaofeng/p/4318499.html
[a3786dc32d8647259e1153c680609ca5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/7380d4be078d4dcb808b8321512ab005.png
[168eb6f0937a46ed825064e408d1639b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/4a4d7eccf7784e6a91b43ce80af41436.png
[fd6e006f8cb24803bb12f75e60bf9020.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/1571772e4b9f4f4b8b16447623f63b4e.png
[7541a4dc9b5048958efc14b612c2baef.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/22a78298255041bcb6d64e6073df9b50.png
[1b009f0220d1441fa723bda85c54bfc6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/c2819492dbac4eb6989d3fdece6884ca.png
[61f898f84f9b420b983537636728e94c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/010eb24e87ba454cadf4e307edc3f43b.png
[bb78c66a197b4c2f89ba6775d4d5e928.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/5e3c015954c94e5bb63d160bd42fd62a.png
[96d64c209fd342d198d5da0d46d3c145.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/eb3926b847184af0b2f11f2b990e5052.png
[a60443e78c0c4a639443b02e498dcf11.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/b7b52581c2de434faf17406347c6dad8.png
[2dc1c52928bd4f0f9609e090abeb5402.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/ce302da477cc4aaab29f06505148f0e5.png
[e1020a449b6b4f3eb26f65070a26df86.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/26eac8b3751d47278f08944789e509d5.png
[a7c036efeff244ca8441d89a2c546b74.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/0650473eefbd4e6b96ebb2459c5c7250.png
[113b0fc3d89d426d8ee25628a22c3b3c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/8a71d0e016504c978b49e2fd423fa9e3.png
[4add985bfedc4028a217c968f74c59e5.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/9a3cc0f9bf1e4cce81722ee3b2c56606.png
[4b44236d78e343faa2098347835abb59.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/11a29650d0544820858937b05f1b44f8.png
[f57aed177c7c4aaa8fcb407595660c6c.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/ae78ef51b11e4417b405cef23fb48324.png
[0dda558ace5849489cdc5de7cb85e9ef.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/ae0ec35031bf409c9d1150d9e0b3a3ae.png
[677525aab3cc4d03a78feb0f6af0a75a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/27/776a507284bc47669b68717c2feee194.png