简介：本资源为ThinkPHP V5.0.7官方框架完整源码包，面向PHP Web开发初学者与中级开发者，解决快速搭建标准化、可扩展Web应用的技术入门与工程实践问题。压缩包共190个文件，含154个核心PHP类库文件（涵盖路由、控制器、模型、视图等MVC组件）、4个模板文件（tpl）、4个Markdown文档（含README与构建说明）、3个YAML配置（含Travis CI持续集成脚本）、以及think命令行工具、LICENSE协议、vendor依赖目录和extend扩展入口等关键模块，结构清晰体现模块化设计思想。资源大小仅359KB，轻量高效，便于本地部署与源码研读。目前已有351人学习下载，读者可直接获取开箱即用的稳定框架版本，深入理解依赖注入容器机制、自动路由调度原理、Composer依赖管理规范及CLI工具链使用方法，是掌握ThinkPHP 5.x架构演进与企业级开发流程的优质实操素材。 提到ThinkPHP 5.0.7，不少刚接触PHP的同学可能一脸懵：这都什么年代了，怎么还有人聊一个七八年前的版本？但只要你翻一翻那些还在稳定运行的存量项目，就会发现生产环境里到处是它的影子。它不像新版框架那样“现代化”，但也正是这种老版本，反而逼着你去理解框架最核心的骨架原理：入口文件、路由解析、容器、ORM、模板引擎。这篇内容不是教你炫技，而是围绕ThinkPHP 5.0.7这个具体版本，把架构思路、部署步骤、核心开发、安全加固、升级到6.0的迁移路径，以及EasyWeChat在TP里的实例化方式一次讲透。无论你是刚接手老项目的新人，还是准备把5.0项目往上迁移的开发者，都可以参考一下。
1. ThinkPHP 5.0.7 核心架构与设计思路
1.1 一个旧版本为什么还有大量项目在跑
先说个现实情况。ThinkPHP 5.0.7发布的时候，PHP还停留在5.4、5.5、5.6时代，MySQL也普遍用着5.5和5.6。当年很多团队选择ThinkPHP，原因很简单：中文文档全、上手门槛低、社区问问题有人回复。
放到现在看，ThinkPHP 5.0.7已经算“高龄软件”了，但大量项目还在跑的原因往往不是技术选型，而是业务成本。我见过不少公司，系统稳定运行了好几年，订单、用户、财务模块都在这个框架上，业务方根本不会为“升级框架”这件事买单。对维护这类项目的开发者来说，最大的诉求不是“换个新框架重写”，而是“在老框架上安全地改需求、补功能、堵漏洞”。
明白这个背景，你才能理解为什么还要去研究一个旧版本。它不是用来学习“最新最佳实践”的，而是用来理解“历史代码为什么长这样”的。你在老项目里看到的各种看似不合理的写法，很多时候都要回到5.0.x时代的框架能力来看。
1.2 5.0.7的目录结构与运行机制
下载ThinkPHP 5.0.7完整包解压后，目录非常清爽：
├─ application // 应用目录，业务代码基本都在这 │ ├─ common.php │ ├─ config.php │ ├─ route.php │ ├─ database.php │ └─ index │ ├─ controller │ ├─ model │ └─ view ├─ public // 唯一对外公开的目录 │ └─ index.php ├─ think // 命令行入口 ├─ vendor // Composer依赖目录 └─ runtime // 运行时缓存、日志目录这套结构放到现在看依然合理。应用代码和公共入口分离，public目录是Web服务器唯一对外开放的根目录，框架文件、配置文件、runtime日志都放在外部访问不到的位置。这个设计和现代框架的“前端控制器”思想完全一致：所有请求先进public/index.php，再由入口文件加载框架、解析路由、分发到具体控制器。
这里有一个容易被忽略的细节：5.0.7的入口文件会自动判断当前环境，生成APP_PATH、RUNTIME_PATH等常量。如果你以后部署到线上时发现页面报“runtime目录不可写”，基本就是权限没给够，和这个机制直接相关。
1.3 5.0.7在5.0系列里的定位
ThinkPHP 5.0系列前后迭代了很多个版本，5.0.7属于早期版本。相比后面的5.0.12、5.0.24，5.0.7在依赖注入、容器能力上还比较“稚嫩”，不少后来常用的语法糖在5.0.7里是没有的。
举个典型例子：在5.0.7里，Route::get('hello/:name', 'index/hello')这种路由定义是可用的，但路由参数绑定到控制器方法参数上，后面版本做了很多兼容调整。如果你刚接触老版本，看到“路由不生效”“参数取不到”这类问题，第一反应不应该是怀疑自己写错了，而要考虑当前版本的路由实现细节。
我给新人的建议是：如果项目已经停在5.0.7，不要直接在老版本上长期开发新功能，优先规划升级到5.0.x系列的最新版本。老版本的新功能开发越少，后面迁移成本越低。
2. 本地环境搭建与首次跑通
2.1 环境版本怎么选才不踩坑
ThinkPHP 5.0.7官方要求PHP 5.4.0以上，但我的实测经验是：在PHP 5.6和PHP 7.0环境下表现得最稳定。如果你用PHP 7.2以上跑它，不少老代码会出现兼容性问题，比如each()函数被移除、构造函数相关行为变化，这些会直接导致框架报错。
数据库方面，MySQL 5.5、5.6、5.7都兼容，但注意一定要确认php_pdo_mysql扩展已开启。我遇到过很多次“数据库连接成功但查询报错”的情况，最后排查下来就是这个扩展没加载。如果你还要用Redis做缓存，额外确认php_redis扩展存在，否则Cache::store('redis')会直接抛异常。
建议本地方案：
- PHP 5.6或7.0
- MySQL 5.6或5.7
- Nginx或Apache
- 不要用PHP 8.x，兼容性会很痛苦
2.2 下载5.0.7源码并调整目录权限
如果你需要指定版本，用Composer拉取最稳：
composer create-project topthink/think=5.0.7 tp507 --prefer-dist注意命令里的--prefer-dist会下载压缩包而不是Git仓库，速度更快，也避免把.git历史拉下来。
如果项目本身是别人给的压缩包，解压后第一步就是把runtime目录权限放开：
chmod -R 777 runtime这一步不做，你访问首页大概率会看到类似“目录没有写入权限”的报错。说得直白点，runtime目录就是ThinkPHP放临时编译文件、缓存、日志的地方，5.0.7没有自动创建目录的能力，必须先手动建好并且让PHP进程能写进去。
2.3 Nginx和Apache的伪静态配置
ThinkPHP 5.0.7默认入口是public/index.php，URL形如http://localhost/index.php/index/index/index。这种URL能跑通，但难看。想做到http://localhost/index/index/index这种干净URL，就需要伪静态配置。
Nginx环境下，在server配置里加上：
location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s=$1 last; } }Apache环境下，在public/.htaccess里加上：
<IfModule mod_rewrite.c> Options +FollowSymlinks -Multiviews RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ index.php/$1 [QSA,PT,L] </IfModule>这里最关键的一点：伪静态规则里的条件和路径判断，一定要指向public目录内。很多人把规则写到项目根目录，结果静态资源全部404，排查半天发现是路径写错了。
2.4 首次访问与常见报错处理
配置完成后，浏览器访问http://localhost，如果看到ThinkPHP的默认欢迎页，说明环境通了。
如果你看到的是空白页或500，按顺序检查：
runtime目录是否有写权限。PHP是否开启pdo_mysql、mbstring扩展。public/index.php中定义的APP_DEBUG是否开启为true。默认安装包里APP_DEBUG可能是false，这时页面不会显示具体错误信息，只能看到500，对调试很不友好。- Nginx是否配置了
fastcgi_pass。有些Nginx配置里没有把PHP请求转发给PHP-FPM，导致所有PHP文件都被当静态文件处理，直接下载或者404。
调试期间还有个推荐做法：在application/config.php里找到'default_module' => 'index'，确认默认模块是index，否则访问根路径时会找不到控制器。
3. 核心功能开发实战
3.1 路由定义：从简单规则到分组路由
ThinkPHP 5.0.7支持在application/route.php里集中定义路由，也可以在控制器里使用注解式路由（通过think\route\Annotation，但5.0.7支持度一般，后面版本才逐步完善）。最常用的是集中定义方式：
use think\Route; // 简单路由 Route::get('hello/:name', 'index/hello'); // POST请求 Route::post('user/save', 'user/save'); // 分组路由 Route::group('api', function () { Route::get('user/:id', 'api/user/read'); Route::post('user', 'api/user/save'); });分组路由是我自己在项目里使用频率很高的功能。老项目接口一多，如果不分组，route.php会乱成一锅粥。建议一个业务模块一个分组，分组名称尽量和模块名一致，这样排查请求路径时能快速定位。
需要注意，5.0.7的路由参数使用了:name这种单冒号语法，和后续版本的<name>尖括号语法不同。如果你后来升级到5.1或6.0，这里是要改的。
3.2 控制器与请求生命周期
控制器文件默认放在application/index/controller/目录下，命名空间是app\index\controller：
<?php namespace app\index\controller; use think\Controller; use think\Request; class Index extends Controller { public function hello(Request $request, $name = 'World') { return "Hello, {$name}! 你当前的请求方式是：" . $request->method(); } }从这段代码能看到5.0.7的一个优势：依赖注入已经在控制器方法中可以使用了。Request对象作为方法参数传入，不需要手动new Request，框架会自动帮你注入。这一点在5.0早期版本算很先进的能力，很多老框架还停留在手动获取全局变量的阶段。
控制器基类think\Controller提供了一个很有用的钩子：_initialize()方法。它在当前控制器的任何方法执行前都会调用，适合做登录校验、权限检查、公共数据赋值：
class Base extends Controller { protected function _initialize() { parent::_initialize(); $user = session('user_info'); if (empty($user)) { $this->error('请先登录', 'login/index'); } $this->assign('current_user', $user); } }这里要特别提醒：如果你把_initialize写在子类里而没有调用parent::_initialize()，父类中定义的初始化逻辑不会执行，这是个很隐蔽的坑。
3.3 模型层：ORM和查询构造器
5.0.7内置了ORM，你可以在application/index/model/下定义模型：
<?php namespace app\index\model; use think\Model; class User extends Model { protected $table = 'tp_user'; protected $pk = 'id'; }然后控制器里直接调用：
$user = User::get(1); // 查单条 $users = User::where('status', 1)->select(); // 查多条 $user->name = '张三'; $user->save(); // 更新模型关联在5.0.7里已经支持hasOne、hasMany、belongsTo等常用关联。我建议重点掌握hasMany和belongsTo，因为绝大多数业务都是“一对多”和“多对一”：
class Order extends Model { public function user() { return $this->belongsTo('User', 'uid', 'id'); } }查询构造器方面，链式操作是核心。where、order、limit、field可以任意组合。需要注意5.0.7的limit写法支持limit(10)，也支持limit(0, 10)，但和6.0的page概念不同。老版本里更习惯用paginate做分页，它会自动读取请求参数里的page值，返回一个带render()方法的分页对象。
3.4 模板引擎与视图输出
视图层使用$this->assign()和$this->fetch()配合：
public function index() { $list = Db::name('article')->where('status', 1)->select(); $this->assign('article_list', $list); return $this->fetch(); }模板文件默认位于application/index/view/index/index.html，命名格式是“控制器名/操作方法名.html”。模板语法沿用了ThinkPHP标签库的老风格：
{volist name="article_list" id="vo"} <h3>{$vo.title}</h3> <p>{$vo.create_time|date='Y-m-d',###}</p> {/volist}模板继承也是可用的，但写法和新版本略有差异。老项目常用的做法是定义layout.html基础模板，然后子模板通过{extend name="layout" /}继承。如果你之前用过6.0，再回来看5.0.7会明显感觉到模板引擎的老派，但核心的{$变量}、{if}、{volist}、{foreach}标签完全够用，没必要非用最新语法重构模板。
4. ThinkPHP安全加固与常见风险排查
4.1 ThinkPHP 5.0.x历史上的安全风险
这里聊一个绕不开的话题：ThinkPHP 5.0.x系列，尤其是早期版本，确实出现过被公开讨论的安全风险。2018年底到2019年初，ThinkPHP 5.0.x被曝出存在远程代码执行类的高危问题，官方在后续版本里做了大量安全更新。问题的根源不在于框架“故意留后门”，而是框架为了追求开发便利，提供了动态调用、方法重载等灵活能力，如果没有严格校验外部输入，这些能力就可能被恶意利用。
对还在维护5.0.7项目的人来说，正确的态度不是“听说了漏洞很恐慌”，而是搞清楚修复路径：先把框架版本升到5.0.x系列最新版。我见过的绝大多数老项目，从5.0.7升级到5.0.24，业务代码其实不需要大改，主要是框架核心文件的替换，这个性价比非常高。
4.2 从安全角度看开发规范
抛开漏洞细节，这些安全问题给我们最大的教训是：不要把用户的输入直接拼进任何“动态执行”的场景。具体来说有几点：
第一，避免使用call_user_func或call_user_func_array时，参数来自用户请求。如果业务上必须用，务必对方法名做白名单校验，而不是直接拼接。
第二，控制器方法参数绑定要谨慎。ThinkPHP支持URL参数自动绑定到方法形参，例如/index/user/delete?id=1会自动把id赋值给$id参数。这种便利本身没问题，但你在方法里拿这个$id去查数据库或删数据时，必须校验它的类型和取值范围，至少用(int)强制转换或验证器过滤。
第三，SQL注入风险主要来自字符串拼接。使用查询构造器时，where条件建议用数组或参数绑定方式，例如：
// 推荐 Db::name('user') ->where('username', $username) ->where('password', md5($password)) ->find(); // 不推荐 Db::query("select * from tp_user where username='{$username}'");老项目里常能翻出第二种写法，看到就建议改成查询构造器，成本低风险小。
4.3 老项目建议先升到5.0.24再考虑迁移
如果你的项目还在5.0.7，我的第一建议不是直接跳到6.0，而是先升级到5.0.24。原因有三个：
一是5.0.7到5.0.24都是5.0.x系列，整体架构完全一致，升级几乎不需要改业务代码，核心变化在框架底层安全和性能修复。
二是很多第三方扩展、老业务逻辑是基于5.0.x编写的，直接跳到6.0会涉及大量接口变更，短时间内很容易改出线上问题。
三是5.0.24之后，ThinkPHP 5.0.x进入了稳定维护期，至少安全上不会裸奔太久。
升级方式很简单：拿一个干净的5.0.24包，把thinkphp目录和vendor里的核心文件替换到项目里，然后逐个跑业务，观察日志。如果遇到类或函数不存在，多半是5.0.x内部实现有调整，再针对性改。
4.4 生产环境加固清单
除了升级版本，老项目的上线前安全检查建议按下面清单过一遍：
| 检查项 | 推荐配置 |
|---|---|
| 调试模式 | APP_DEBUG设为false，避免暴露路径和SQL |
| 强制路由 | 开启url_route_must，减少非路由访问 |
| 目录权限 | runtime可写，application不可写 |
| 数据库账户 | 使用最小权限账号，不要用root |
| 日志记录 | 开启log，定期检查异常日志 |
| 备份策略 | 数据库每日自动备份，代码版本库管理 |
最后加一条实际操作经验：上线前用安全性扫描工具扫一遍老项目。这类工具能帮你快速定位明显的注入、XSS、文件上传漏洞，虽然不能杜绝所有问题，但能标记出重点检查的代码位置。对比扫描结果和代码，你会更快找到问题入口。
5. 从ThinkPHP 5.0.7升级到6.0：迁移差异与实操要点
5.1 官方升级路线：为什么要走5.0 → 5.1 → 6.0
ThinkPHP官方给出的升级路线是5.0先升5.1，再从5.1升6.0。不推荐5.0直接跳6.0，原因在于5.0到6.0之间的内部变化太大了，直接跨版本意味着你同时要处理两代框架的差异，代码改动量会非常大，排错难度也很高。
我在一个订单管理项目上做过类似升级。从5.0.24到5.1相对平滑，主要是把数据库配置从application/database.php挪到.env或config/database.php，以及部分Db调用方式的变化；但从5.1到6.0才是重头戏，路由、控制器基类、中间件、事件系统都变了，几乎等于重写了一层骨架。
如果业务系统复杂，建议分两步走：先升到5.1，跑一个季度稳定后，再规划6.0。这种渐进式迁移虽然时间跨度长，但风险是可控的。
5.2 核心差异对比速查表
| 项目 | ThinkPHP 5.0.7 | ThinkPHP 6.0 |
|---|---|---|
| PHP版本要求 | PHP 5.4+ | PHP 7.2.5+ |
| 多应用模式 | 通过模块实现 | 独立多应用模式 |
| 控制器基类 | think\Controller普遍使用 | 默认无强制基类 |
| 初始化钩子 | _initialize() | 中间件、事件 |
| 路由语法 | :name | <name> |
| 数据库配置 | application/database.php | .env或config/database.php |
| 门面类 | 支持 | 支持，更全面 |
| 模板引擎 | 内置模板 | 默认集成，可使用第三方 |
这个表基本就是迁移时的改动范围。多应用模式改变最明显，5.0里一个application下挂多个模块就叫“模块”，6.0里一个app下可以有多个独立应用，目录结构变成了：
app ├─ index │ ├─ controller │ └─ model ├─ admin │ ├─ controller │ └─ model └─ common控制器基类的变化也是最容易踩的坑。5.0里几乎每个控制器都继承think\Controller来用$this->success()、$this->redirect()、$this->fetch()这些方法，到6.0里这些方法不再通过基类提供，要么用app\BaseController，要么自己封装一个基础控制器。如果你不处理就直接把旧控制器拷到6.0里，系统会直接报“类不存在”。
5.3 一个老项目的迁移实操
我以实际迁移时的操作顺序，整理一套可复用的流程：
第一步，搭建6.0空白应用，确认新环境跑通。
composer create-project topthink/think tp60 --prefer-dist第二步，把旧项目的application/database.php迁移到新项目的.env文件里：
[APP] APP_DEBUG = false [DATABASE] TYPE = mysql HOSTNAME = 127.0.0.1 DATABASE = order_system USERNAME = root PASSWORD = HOSTPORT = 3306 PREFIX = tp_ CHARSET = utf8mb4第三步，调整目录结构。把旧项目application/index/下的控制器、模型、视图，分别复制到新项目的app/index/下的controller、model、view目录。
第四步，全局替换控制器基类。旧代码里use think\Controller;改成use app\BaseController;，然后把$this->fetch()换成视图工厂方式：
use think\facade\View; public function index() { return View::fetch('index/index'); }第五步，逐模块跑接口、页面，优先排查路由、验证器、分页三块。路由写法从Route::get('hello/:name', 'index/hello')改为Route::get('hello/<name>', 'index/hello')，验证器的validate方法在6.0里更强调依赖注入，分页对象的方法名也有调整。
5.4 升级过程中常见报错与排查速查
| 报错信息 | 可能原因 | 处理方式 |
|---|---|---|
Class app\index\controller\Index not found | 控制器命名空间不对，或目录位置不对 | 检查app/index/controller/Index.php的命名空间和文件路径 |
Call to undefined method think\facade\Route::get() | 路由版本差异，或没有正确引入门面类 | 确认use think\facade\Route; |
Method [fetch] does not exist | 6.0里控制器没有fetch方法 | 改用View::fetch()或安装官方模板驱动 |
Database configuration not found | .env未正确配置数据库，或缓存未清理 | 检查.env和runtime缓存 |
Undefined constant "" | 老代码用了5.0的全局常量 | 搜索替换为6.0对应常量或配置项 |
迁移6.0最花时间的反而不是改代码，而是找旧的隐式依赖。很多老项目没写全use语句，靠框架自动加载“碰巧”能跑，换了目录结构后这些隐藏依赖就全都会暴露出来。建议迁移时直接打开错误日志跑全面测试，比手工检查代码高效很多。
6. EasyWeChat在ThinkPHP中的实例化与使用
6.1 安装与依赖管理
EasyWeChat是PHP生态里非常流行的微信开发工具包。在ThinkPHP项目里集成它，通常有两种方式：用Composer安装到vendor目录，或者把SDK代码放入extend目录手动引用。
推荐用Composer方式。在项目根目录执行：
composer require overtrue/wechat但注意版本和PHP环境的兼容性。EasyWeChat 4.x支持PHP 5.5.9以上，和ThinkPHP 5.0.x配合比较顺；EasyWeChat 5.x以上要求PHP更高版本，通常会配ThinkPHP 6.0使用。如果你在5.0.7里强行装新版EasyWeChat，很可能因为函数或语法不兼容直接白屏。
6.2 ThinkPHP 6.0里的标准写法：use EasyWeChat\Factory
在ThinkPHP 6.0项目里，目前社区常用的实例化方式是use EasyWeChat\Factory;。例如初始化公众号应用：
<?php namespace app\index\controller; use EasyWeChat\Factory; use think\facade\Cache; use think\facade\Config; class Wechat extends BaseController { public function index() { $config = [ 'app_id' => 'wx1234567890', 'secret' => 'your-secret', 'token' => 'your-token', 'aes_key' => 'your-aes-key', 'response_type' => 'array', 'log' => [ 'level' => 'debug', 'file' => runtime_path() . 'wechat.log', ], ]; $app = Factory::officialAccount($config); $app->server->push(function ($message) { return "欢迎关注！"; }); $response = $app->server->serve(); return $response; } }这段代码的核心就是把微信平台配置传给Factory::officialAccount()，返回一个服务容器，后续的菜单、用户、客服消息、微信支付等能力都可以从$app上取。Factory类的意义在于，把不同业务对象例如公众号、小程序、开放平台、支付等的初始化逻辑统一封装，开发者不需要自己去new一堆类，也不用记忆每个类的构造方法参数。
在ThinkPHP 6.0里，runtime_path()是框架提供的基础函数，用来拿运行时目录路径。如果你想保证日志文件可靠写入，最好在控制器外层就确认这个目录已存在且有权限，否则EasyWeChat内部写日志时会抛异常。
6.3 在ThinkPHP 5.0里怎么兼容集成
如果你的项目还跑在ThinkPHP 5.0.x，又想用EasyWeChat，有几种做法。
老一些的EasyWeChat版本（3.x和4.x初期）里，初始化方式更直接：
use EasyWeChat\Foundation\Application; $options = [ 'app_id' => 'wx1234567890', 'secret' => 'your-secret', 'token' => 'your-token', 'aes_key' => 'your-aes-key', ]; $app = new Application($options);这个Application对象就是整个EasyWeChat应用的入口，通过$app->server、$app->user、$app->menu等属性去调用对应模块。
如果你在5.0项目里还是希望保留Factory::officialAccount()这种更统一的写法，可以自己在extension.php或公共函数库里封装一个单例方法：
use EasyWeChat\Factory; if (!function_exists('wechat_app')) { function wechat_app() { static $app = null; if ($app === null) { $config = [ 'app_id' => config('wechat.app_id'), 'secret' => config('wechat.secret'), 'token' => config('wechat.token'), 'aes_key' => config('wechat.aes_key'), ]; $app = Factory::officialAccount($config); } return $app; } }这样做的好处是把“不同版本SDK初始化差异”隔离在函数内部，业务代码只需要调用wechat_app()就能拿到对象，以后升级SDK版本时只改这一处。
6.4 EasyWeChat集成时的常见坑
先说一个高频问题：签名验证失败。这通常不是代码的问题，而是服务器时间不准，或者token填写不一致。微信服务器会校验请求签名，如果服务器时间和微信服务器时间差得太多，响应会直接被拒绝。处理办法是开启NTP时间同步，同时检查config/wechat.php里的token是否和公众号后台设置一致。
其次是网络代理问题。EasyWeChat发请求时走的是GuzzleHttp，如果服务器在内网环境，需要配置代理。否则你会看到“cURL error 28: Connection timed out”，排查半天找不到原因。
最后是缓存冲突。EasyWeChat默认会缓存access_token，如果你在多个服务器上部署了同一套公众号，且共用同一份数据库或其他缓存，很容易导致token刷新混乱。建议在配置里显式指定缓存句柄，例如用ThinkPHP的Redis驱动：
'cache' => [ 'type' => 'redis', 'host' => '127.0.0.1', 'port' => 6379, ],这样access_token统一存放在Redis里，多个实例共享同一条缓存数据，能减少很多莫名其妙的“token无效”问题。
最后提醒一点：不管你是用ThinkPHP 5.0.7还是6.0，集成微信支付或公众号时，尽量把app_id、secret这类敏感配置放在.env或独立配置文件中，不要硬编码到控制器里。老项目里最常见的隐患就是代码仓库里混着各种测试密钥，一旦仓库泄露，后果比框架漏洞更直接。
本文还有配套的精品资源，点击获取
