简介：这是一套完整开源的iApp后台PHP服务端源码，面向移动端应用开发者、iApp脚本作者，以及需要快速搭建轻量级后端接口的PHP学习者。资源包采用zip压缩，共419个文件，整体大小约5.27MB；其中278个php文件构成服务端业务核心，覆盖api、blessing、codeIP、cooperation、docking、exchange等接口模块，包含用户IP处理、随机逻辑、接口签名等常见后端细节；另有49个iapp页面文件、21个iyu配置文件和注册、登录、微信支付、404等HTML模板页，并配有PNG/JPG图片与JS脚本资源，目录划分较清晰，适合直接部署或按模块查找。当前已有214人学习下载。开发者可以从这套全开源源码中完整理解iApp客户端与PHP后端之间的数据交互流程，直接拿支付对接、合作对接、兑换逻辑等现成接口实现，在统一接口风格下进行二次开发，对希望摆脱在线收费接口、自建移动应用后端的读者来说，是一份可直接上手的开源范例。
1. iApp后台带PHP文件源码全开源，到底解决了什么问题
做iApp应用的人应该都有过这种经历：前端界面用积木拖得很快，但一涉及到“登录验证”“卡密充值”“远程列表”这类需要服务端支撑的功能，就卡住了。你不可能把账号密码和商品数据写死在App里，也不可能每次更新列表就让人重新下载安装包。这时候你需要一个后台——一个跑在服务器上的PHP接口，App通过HTTP请求去读数据、验卡密、取版本号。所谓“iApp后台带PHP文件源码全开源”，指的就是这类把服务端PHP代码和数据库结构一起打包放出来的资源包。它能解决的核心问题就一个：让一个没有后端开发经验的iApp作者，也能在半小时内把App从“纯本地”变成“有远程数据支撑”。
这套方案特别适合三类人：一是正在做工具类、资源类iApp的新手，想给App加个卡密登录却不知道接口怎么写；二是接单做演示项目的人，需要快速交付一个带后台的成品；三是想学PHP接口开发但不想从框架入门的iApp玩家，直接对着这套源码改，比看抽象教程快得多。下文我会按“接口原理 → 本地部署 → 前端对接 → 踩坑排查 → 加固进阶”的顺序，把这套东西从能跑到能用给你讲透。
2. 拆解一套“iApp后台带PHP文件源码”：接口、数据表和请求协议
2.1 这类源码包的典型目录结构，拿到手先别急着传服务器
我见过很多新人拿到开源包，第一件事就是拿FTP把全部PHP文件传到服务器，然后打开网站一看，全是报错。实际上这类后台的结构是有规律可循的。一个正常的“iApp后台带PHP文件源码”压缩包，解压后核心通常分为三块：PHP接口文件、SQL数据库文件、说明书或接口文档。PHP文件里关键的不是页面，而是那一堆$_GET、$_POST和json_encode——因为iApp端要的不是网页，而是结构化数据。
以最常见的卡密验证后台为例，代码结构一般是这样：
├── admin # 后台管理目录（用于发卡、查看用户） │ ├── index.php # 管理后台入口 │ └── login.php # 管理员登录 ├── api # App端要请求的接口目录 │ ├── check.php # 卡密验证接口 │ ├── userinfo.php # 用户信息查询接口 │ └── list.php # 远程列表接口 ├── config.php # AF配置：数据库连接、密钥 └── install.sql # 数据库初始表结构拿到包以后不要急着传，先做两件事：打开config.php确认数据库连接信息的长相，再看install.sql里的表名和字段名，这决定了你后面在iApp里怎么拼参数。我也见过有人把SQL文件在记事本里打开发现是UTF-8带BOM，导入MySQL就报语法错——这类小坑后面单独说。
如果你拿到的包结构不一样，不用慌，核心点只有两个：有没有能够响应HTTP请求的PHP接口文件，有没有建表语句。没有SQL文件的包建议直接放弃，因为那种包要么数据库结构写死在PHP里（后期改起来很痛苦），要么干脆只有空壳。
2.2 接口返回的数据格式：为什么大家都默认用JSON而不是HTML
iApp里通过“HTTP请求”组件和后台交互，后台返回的是一段文本。这段文本如果是HTML，iApp还得解析HTML，非常痛苦；如果返回JSON，iApp的“JSON解析”组件直接就能用。所以成熟的“iApp后台带PHP文件源码”里，所有接口都会返回一段固定结构的JSON，比如下面这种：
{ "code": 200, "msg": "验证成功", "data": { "username": "test_user", "expire_time": "2025-12-31", "token": "a1b2c3d4e5" } }其中code用于判断业务成功还是失败——200代表成功，非200代表失败；msg用于给用户弹提示；data用于存具体的业务数据。iApp前端只需要判断code的值，就能决定跳转到主界面还是弹窗报错，逻辑非常清爽。
对应到PHP端，一个最简的卡密验证接口大概长这样：
<?php // 引入配置，拿到数据库连接对象$conn require_once 'config.php'; // 统一接收GET或POST参数 $card = isset($_REQUEST['card']) ? trim($_REQUEST['card']) : ''; // 基础校验：参数不能为空 if (empty($card)) { echo json_encode(['code' => 400, 'msg' => '卡密不能为空']); exit; } // 转义，防止简单的SQL注入 $card = mysqli_real_escape_string($conn, $card); // 查询卡密 $sql = "SELECT * FROM cards WHERE card_no = '{$card}' AND status = 0 LIMIT 1"; $result = mysqli_query($conn, $sql); $row = mysqli_fetch_assoc($result); if (!$row) { echo json_encode(['code' => 401, 'msg' => '卡密不存在或已被使用']); exit; } // 校验有效期（示例：expire_time存的是datetime类型） if (strtotime($row['expire_time']) < time()) { echo json_encode(['code' => 402, 'msg' => '卡密已过期']); exit; } // 更新为已使用 mysqli_query($conn, "UPDATE cards SET status = 1, use_time = NOW() WHERE id = {$row['id']}"); // 返回成功，附带用户信息 echo json_encode([ 'code' => 200, 'msg' => '验证成功', 'data' => [ 'username' => $row['username'], 'expire_time' => $row['expire_time'], 'token' => md5($row['card_no'] . time()) ] ]);这段代码的逻辑说明很简单：先接参数，再查表，查到了判断状态和过期时间，最后更新卡密状态并把用户信息返回给App。这里有三个参数你需要按自己的包实际调整：cards表名、status字段的语义（0未用、1已用，有的包写的是used）、expire_time字段的格式。很多源码包报“卡密验证失败”，问题就出在字段名和你的数据库不匹配。
提示：不要用
$_REQUEST同时接收GET和POST，因为PHP默认优先级会让你的参数来源不可控。iApp的HTTP组件默认发的是POST，调试时用浏览器访问是会变GET的——这两个都能跑通，但上线时建议固定一种，我习惯固定用POST。
2.3 后台管理端和App接口端为什么要分开写
开源包里经常出现两个入口，一个是admin/目录，一个是api/目录。很多新手不理解，觉得都是PHP为什么还要分目录。原因是权限模型完全不同：App端接口的调用者是一个安装包，可被反编译，不能在里面写死管理员密码；后台管理端是给站长在浏览器里用的，必须走登录态。如果这两个混在一个文件里，要么管理员登录逻辑被App调用漏洞绕过，要么接口被管理页拖慢速度。
管理端一般是传统的会话登录，用$_SESSION存管理员状态；接口端则是无状态认证，每次请求带卡密或token。这个分界线也是判断一套源码写得好不好的第一眼：接口文件里如果出现了session_start()，那就要警惕，它大概率会把并发请求变成串行处理，iApp多设备同时登录时后台响应会明显变慢。
3. 在本地把后台跑通：从PHP环境到数据库导入，再用真机联调
3.1 用phpStudy搭建本地环境，5分钟让PHP源码跑起来
“iApp后台带PHP文件源码”毕竟是个服务端程序，你不可能每次调试都把文件传到服务器。本地搭一套PHP运行环境是最快的验证方式。Windows上最常见的做法是用phpStudy或XAMPP，这里以phpStudy为例，因为它自带MySQL管理工具，对新手最友好。
具体步骤如下：
# 1. 下载并安装phpStudy，启动Apache和MySQL服务 # 注意：PHP版本建议选7.4或8.0，有些老的源码在PHP 8.2以上会报 # "Deprecated: mysqli_real_escape_string" 之类的警告 # 2. 将源码包复制到网站根目录 # phpStudy默认根目录是 phpstudy_pro/WWW # 假设你新建一个文件夹 iapp_backend，则访问路径为 http://127.0.0.1/iapp_backend/ # 3. 用phpMyAdmin创建数据库并导入install.sql # 打开 http://127.0.0.1/phpmyadmin ，新建数据库名建议叫 iapp_db， # 字符集选 utf8mb4_unicode_ci，然后在SQL页签里导入install.sql这里第3步最容易出错，特别是导入SQL的时候，如果install.sql第一行有CREATE DATABASE语句而你又手动建了库，会直接报数据库已存在；反过来如果没建数据库就导入，会报No database selected。正确做法是：先新建数据库，再在导入时把SQL文件里的CREATE DATABASE IF NOT EXISTS语句勾选为“不执行”。
导入成功后，去数据库里看一眼表名和前缀。很多开源包喜欢用cd_、iapp_这类前缀，但你如果多套项目共用一个数据库，前缀就是区分数据归属的关键。我见过有人一个库里建了五个项目的表，卡密表名全是cards，最后删数据时把别人的删了，非常狼狈。建议导入后立刻给所有表加上你自己的业务前缀。
3.2 修改config.php里的数据库参数，笔试把这四个值改对
PHP源码能不能连上数据库，全看config.php。这个文件几乎是所有开源后台里最不该动的文件，但又是必须要改对的文件。常见的写法是这样：
<?php define('DB_HOST', '127.0.0.1'); // 数据库地址，一般不用改 define('DB_USER', 'root'); // 数据库用户名，本地phpStudy默认是root define('DB_PASS', 'root'); // 数据库密码，phpStudy默认是root，云服务器按实际写 define('DB_NAME', 'iapp_db'); // 数据库名，第3.1步建的那个 // 初始化数据库连接 $conn = mysqli_connect(DB_HOST, DB_USER, DB_PASS, DB_NAME); mysqli_set_charset($conn, 'utf8mb4'); // 如果你的源码包用PDO，则配置类似这样： // $db = new PDO('mysql:host='.DB_HOST.';dbname='.DB_NAME.';charset=utf8mb4', DB_USER, DB_PASS);这里特别强调两点。第一，mysqli_set_charset($conn, 'utf8mb4')这行必须有，否则你插入卡密表中的中文用户名会乱码或者直接报Incorrect string value错误。第二，很多老包写的是mysql_connect()，这是PHP 7.0之前的老API，PHP 7以上直接报Fatal error: Call to undefined function，遇到这种情况要么把PHP降级到5.6，要么全网搜“mysql_connect改mysqli”的工具，前者更省事。
DB_PASS这个参数，本地和线上完全不同。本地phpStudy没改过密码的话一般是root或空；线上云数据库的密码通常是一串随机字符，复制时注意别带空行。改完配置后，PHP上直接用浏览器访问api/list.php，如果浏览器输出了一串JSON而不是报错页，说明数据库通了。
3.3 iApp模拟器联调和真机联调，为什么IP地址不一样
后台跑起来以后，下面就要让iApp端去找这个后台。这里有几个不同环境下的访问地址，很容易搞混：
| 调试方式 | 后台访问地址 | 前提条件 |
|---|---|---|
| 本地模拟器调试 | http://127.0.0.1/iapp_backend/api/xxx.php | 模拟器和phpStudy在同一台电脑 |
| 局域网真机调试 | http://192.168.x.x/iapp_backend/api/xxx.php | 手机和电脑连同一个WiFi，并关掉电脑防火墙 |
| 云服务器调试 | http://你的域名或IP/iapp_backend/api/xxx.php | 服务器已部署并放行80端口 |
重点说第二行。很多人在iApp模拟器里用127.0.0.1调通了，一到真机就失败。原因很简单：127.0.0.1在手机上指的是手机自己，而不是你的电脑。真机联调必须填电脑在局域网内的IP地址，怎么查？Windows上ipconfig，找到IPv4地址那一栏，一般长成192.168.1.x或172.20.x.x。另外Windows防火墙会拦截MySQL和PHP服务器的入站请求，调试时临时关掉防火墙，或者给Apache提前添加防火墙放行规则，不然真机一样连不上。
到了这个阶段，你已经完成了90%的部署工作。后面就是iApp端对接，这是整个方案里最花时间的环节，也是最容易把新手卡住的环节。
4. iApp端对接PHP后台：HTTP组件、JSON解析和远程列表的完整搭法
4.1 iApp里发起HTTP请求，POST参数到底应该怎么填
iApp是积木式编程，不需要手写网络层代码，但HTTP请求组件的参数配置是很多人的知识盲区。以iApp里最常见的“HTTP请求”事件为例，你需要填写五个东西：请求地址、请求方式、请求头、请求参数和超时时间。地址填的就是PHP接口的完整URL；方式选POST；请求参数是一个键值对列表。
我们以调用api/check.php验证卡密为例，画一下准确的配置映射关系。iApp界面上会有“参数名”和“参数值”两个输入框，你需要填两行：
// 参数名 // 参数值 card // 输入框变量：你界面上那个“卡密输入框”的文本就这么一行，PHP端$_POST['card']就能接住。很多新人填参数时喜欢把整个URL带在参数值里，或者把参数名写成$_POST['card']——这些都是错的，iApp拼请求时会把参数名和值原样编码放进去，你多写个$_POST反而让PHP端取不到值。
请求头不需要填，除非你的PHP接口里设了$_SERVER['HTTP_TOKEN']这种自定义头校验。超时时间默认30秒就够了，不用刻意调小，移动网络下PHPFastCGI偶发响应超过5秒也正常。
请求完成后，iApp会把返回的文本存在你指定的一个文本变量里，比如返回内容。后面就靠JSON解析组件了。
4.2 JSON解析组件怎么用：三层嵌套的取值路径
iApp的“JSON解析”组件，对应JSON这种结构的数据处理，它把你的返回内容转换成一个多维数组。先把返回内容存进源码，“从源码解析Json”事件执行后，就能按层级取数。
对应上面PHP返回的那段JSON，iApp里的取值表达式长这样：
// 取最外层的code（判断成功失败） Json.取文本("code") // 取data里的token（登录成功后存起来） Json.取文本("data.token") // 如果PHP返回的是数组，就取数组成员数量 Json.取成员数("data.list")这一段是iApp对接的核心，很多人卡在这一步，是因为JSON解析组件有“缓存”概念——当返回内容的JSON结构变化时，如果你没有重新执行“从源码解析Json”，取数据拿到的还是旧值，表现为“登录后用户名不变”。实际排查时，先看“返回内容”变量打印出来是不是最新数据，再排查解析路径和取值路径是否一致。
4.3 远程列表接口：让App的内容随时可更，不用重新发版
“远程列表”是iApp后台最常见的需求，也就是App首页的公告、图文列表、商品等内容全部由PHP后台控制。实现思路很简单：PHP查询数据表，把多行结果组装成JSON数组返回，iApp拿到后用“列表”组件动态加载。
PHP端一个标准的远程列表接口，核心代码像这样：
<?php require_once 'config.php'; // 接收分页参数，默认第1页，每页10条 $page = isset($_POST['page']) ? intval($_POST['page']) : 1; $pagesize = isset($_POST['pagesize']) ? intval($_POST['pagesize']) : 10; // 计算偏移量 $offset = ($page - 1) * $pagesize; // 查询公告列表 $sql = "SELECT id, title, content, create_time FROM news WHERE status = 1 ORDER BY id DESC LIMIT {$offset}, {$pagesize}"; $result = mysqli_query($conn, $sql); $list = []; while ($row = mysqli_fetch_assoc($result)) { $list[] = [ 'id' => (int)$row['id'], 'title' => $row['title'], 'content' => mb_substr($row['content'], 0, 50, 'utf-8'), // 截断到50字，列表页不用显示全文 'time' => $row['create_time'] ]; } // 返回统一格式 echo json_encode([ 'code' => 200, 'msg' => 'success', 'data' => [ 'list' => $list, 'page' => $page, 'total' => count($list) // 当前页返回条数，用于判断还有没有更多 ] ]);这里的三个参数需要重点关注：$page和$pagesize是分页参数，iApp里做下拉加载更多时就是不断把page加1再请求；mb_substr的第三个参数50决定列表摘要的长度，太短显示不出内容，太长会让JSON体积膨胀；status = 1这个条件用来控制上/下架，但前提是你的表里有status字段，没有的话要去数据库里加或删掉这个条件。
iApp端收到这个接口的数据后，列表组件的“加载数据”事件里需要循环取出data.list的每个成员，把title和time分别填到列表控件里对应的显示位置。这里的坑在于，很多列表控件要求数据源的字段名和item里的文本控件一一对应，如果你在PHP里把字段名从t_title改成title，iApp端没有同步改，列表就是空白的——这类问题大多是沉默失败，没有任何报错。
4.4 从“能用”到“好用”：给你的App加一个启动时自动拉取公告
远程列表除了手动下拉刷新，更常见的需求是App启动时自动拉取一次公告，弹窗或用滚动条展示。这个逻辑在iApp里可以用“应用启动”事件触发HTTP请求，然后断言返回的code值为200再取数据。要注意的是别让这个请求阻塞主界面，iApp的HTTP请求组件默认是异步回调式的，你只需要在“请求完成”事件里处理数据，不要在启动事件里用循环等待结果——没有经验的人经常写一个“循环等待变量不为空”的逻辑，结果直接卡死界面，这在真机上表现非常明显。
5. 部署和对接的常见坑：本地能跑线上挂，这里有5条血泪经验
5.1 把PHP文件传上服务器后立刻报500，原因只有一个
现象：本地phpStudy一切正常，一传到宝塔或云服务器上全部接口返回500错误。
原因：绝大多数情况是PHP版本升到5.6以上后，老代码里的mysql_connect()函数直接失效了。十套“iApp后台带PHP文件源码”里至少有六套是从老项目拷出来的，写代码时还是PHP 5.2时代。另外少部分情况是Linux服务器的目录没有写权限，卡密验证时UPDATE cards语句执行失败导致500。
解决：在宝塔或面板的PHP设置里把版本切到7.0或7.4，并把源码目录里的api和admin文件夹权限设置为755或775。如果你的代码用了mysql_connect，直接到PHP设置里把“禁用函数”列表里的mysql_connect删掉，这个函数在PHP 7里已经不存在了，禁用也没意义，纯粹是历史遗留选项。
5.2 PHP 8.2下开了报错显示，前端直接输出了Warning
现象：接口返回的不是JSON，而是一大堆Deprecated: mysqli_real_escape_string(): Passing null to parameter开头的文本，iApp端解析JSON直接失败。
原因：PHP 8.1之后对空参数、隐式类型转换这类写法的兼容性收紧，老代码里大量isset($_POST['xxx']) ? $_POST['xxx'] : ''没问题，但有的包直接写$_POST['xxx']访问不存在的键，就会触发Deprecated甚至Warning，而这些文本会混进输出的JSON里。
解决：两个方向，最简单的就是给PHP环境关掉错误显示。在config.php最上面加三行：
error_reporting(0); ini_set('display_errors', 0);但这只是把症状藏住了，真正根因是接口里访问了不存在的数组键，属于脏数据。更稳妥的修法是把所有$_POST['xxx']改成isset($_POST['xxx']) ? trim($_POST['xxx']) : ''，一行一行改确实烦，但换来的是一套不会因为PHP升级就突然挂掉的后台。我现在拿到开源包第一件事就是全局搜索$_POST和$_GET，把所有裸访问清理完再往下改。
5.3 数据库导入时中文乱码，根本原因不是表结构
现象：后台管理端添加卡密时填的中文，在iApp端查询出来变成“???”或者一个个问号。
原因：建表时字符集用了latin1或utf8，PHP连接时又没指定utf8mb4，中文字符在转换时被截断。utf8其实是MySQL的假utf8，只能存基本字符，像“emoji表情”和生僻字就会直接变问号。
解决：打开数据库管理工具，确认所有表字符集是utf8mb4。如果已经建表了，执行一条转换语句：
ALTER TABLE cards CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;对应到PHP端，就是保证mysqli_set_charset($conn, 'utf8mb4')这行代码在数据库查询之前执行。这条问题排查顺序不要错：先改表字符集，再改连接字符集，最后才考虑是不是页面文件本身编码不对。
5.4 iApp真机连不上后台，本地模拟器却可以
现象：模拟器里调后台一切顺利，打包安装到手机上就提示网络异常。
原因：第一是手机和电脑不在同一个WiFi下，手机访问不了局域网IP；第二是电脑防火墙拦了Apache的入站端口；第三是你用了127.0.0.1，这个地址在手机上指向手机自己，自然连不上。
解决：先用手机浏览器访问http://电脑局域网IP/iapp_backend/api/list.php，如果能出JSON，那就是iApp请求代码问题；如果手机浏览器也打不开，优先级是：检查IP是否在同一网段 → 检查电脑防火墙 → 检查Apache是否监听在80端口。有一种特殊情况是电脑开了网络代理，会拦截本地回环流量，把系统代理关掉再试。
5.5 卡密明明数据库里有，接口却提示“卡密不存在”
现象：后台添加了一张卡，到iApp端去验证，返回“卡密不存在或已被使用”。
原因：几乎都是参数key对不上。比如PHP里用的是card_no，但接口接收的参数名是card_no；而iApp端填的参数名是card。两边一个对不上，查询结果集就是空的。
解决：这个坑在调试时最容易定位，别猜，直接在浏览器地址栏模拟一次请求。比如后台地址是http://127.0.0.1/iapp_backend/api/check.php?card=TEST-001，先确认GET方式能不能通过；能通过说明PHP端没问题，问题出在iApp端参数传递，把参数名改成card_no重试。注意PHP端如果用POST接收，浏览器地址栏GET是无效的，此时改用工具或直接在PHP文件里加上var_dump($_REQUEST);打印出当前收到的所有参数，再和iApp发送的参数逐字比对。
6. 把后台从能用做到扛用：时间戳防刷、统一返回体和快速兜底方案
做到这一步，你已经跑通了整套“iApp后台带PHP文件源码”。但真正上线你就会发现，开源后台被刷是常态——卡密接口可以被脚本无限尝试，远程列表接口每秒钟被轮询几百次。老话说得好，能用和扛用之间隔着三层防护。
第一层是时间戳防刷。在PHP接口入口处加一个请求时间戳校验，App端每次POST带timestamp字段，服务器端判断time() - timestamp的差值，超过120秒的请求直接拒绝。这条规则能拦住绝大多数源自“老接口协议重放”的攻击。实现时注意，同时做时间的接受度放宽容许：手机本身的时钟不准会造成误杀，所以我会把可接受的时差放宽到5分钟，并且只拦截明显的重放请求。
第二层是合理利用PHP的错误输出。线上环境必须关掉display_errors，否则一个数据库告警就可能让你的JSON响应被污染，iApp端解析失败时屏幕上只有一片空白，根本不知道问题在哪。我会在config.php里统一处理：
ini_set('display_errors', 0); error_reporting(E_ALL);同时把错误日志写到文件，这样生产环境的排查效率远高于直接看屏幕报错。很多开源包没有这层配置，导致同一个问题线上复现时只能靠猜——这是最耗时间的做法。
第三层是给远程列表接口加一个最简单的内存缓存。用文件缓存代替数据库查询：第一次请求时把查询结果写入服务器上的一个文本文件，后续请求只要文件时间不超过600秒就直接返回文件内容，不碰数据库。iApp的列表页对实时性要求没那么高，10分钟内的旧数据用户根本感知不到。这是在完全不改动前端协议的前提下，把接口并发能力提高几十倍的最有效方式。
验证方法也很简单：用浏览器的无痕窗口或手机飞行模式切换网络，连续请求10次同一接口，观察返回JSON里code是否稳定为200，响应时间是否在1秒以内。如果你追求更高的工程化程度，可以尝试把PHP接口从单文件改成轻量路由，甚至按热词里的方向，把后台管理端做成“vue3后台管理系统”风格的前后端分离版本——思路完全一样，接口返回结构不变，前端套壳即可。做完这些，你这套“iApp后台带PHP文件源码全开源”就不再只停留在能跑通的层面，而是一套真正可以上生产环境、扛住最基础流量的小型后端了。
我个人这几年改过的开源后台少说有二十套，最大的教训是：拿到源码先看它的错误处理习惯，一个不写error_reporting(0)、不统一日志的包，后续维护成本一定极高。反过来，处理掉这几个习惯，你就能把任何一套开源后台变成自己的基础框架，下次再做类似项目时直接复制改字段名就开工。希望这些落地细节能帮到你。
本文还有配套的精品资源，点击获取
