简介：一套完整的海外信贷/贷款平台源码，适合有Laravel基础的开发者、借贷系统外包团队或金融科技公司用于快速搭建线上放款与风控业务。基于Laravel框架，支持中英文双语，覆盖借款申请、授信审核、还款管理等核心流程，既可直接部署也可按业务二次开发。压缩包共2000个文件，大小约181.82MB，其中JS脚本1338个、JSON配置文件218个、Markdown文档179个、CSS样式148个、HTML页面103个，另有SQL数据库脚本与少量文本、XML文件，基本涵盖后端逻辑、前端页面、项目说明和数据库初始化内容。部署要求已明确：Linux CentOS7.6、宝塔、PHP7.3、MySQL5.6，根目录指向public，采用Laravel5伪静态并开启SSL证书，数据库连接只需修改根目录.env文件。已有377人学习下载，资源内提供编译后的前端入口、AdminLTE后台主题、Laravel模块化目录及多语言文案，能帮助理解海外借贷平台的目录组织、前后端分离和上线配置思路，减少从零搭建的重复工作。

1. 海外贷款平台源码：先搞清楚贷的是什么，再谈买谁的代码

一套海外贷款信贷产品源码拿到手，大家最先试的永远是注册、进件、放款这一条主链路能不能跑通。但真正做过几单业务之后，你大概率会在某个深夜被对不上的账目砸醒：还款计划少算一期、提前还款后本金对不上、逾期罚息和催收节点各算各的。支撑一个海外借贷平台长期运转的，不是原来那个管理后台美不美观，而是产品参数化和账务内核——同一套代码能不能同时开出现金贷、分期、BNPL 几种线上贷款产品，每个产品的利率期限、还款方式、逾期规则改配置就行，不动一行业务代码。这篇稿子写给三类人：打算采购贷款平台软件源码的技术负责人、正在自研海外信贷系统的开发团队、以及想搞懂线上贷款产品完整模块的从业者。

2. 线上贷款产品大全：从现金贷到 BNPL，每个产品形态都对应一套账务模型

先别急着翻代码。我给不少团队做过系统落地，第一课永远是产品形态梳理。因为源码仓库里所有模块，本质上都是为某一种产品形态服务的，用现金贷的逻辑去套分期产品，账务上会错得离谱。线上贷款产品看上去名字花哨，拆到底就是四种账务模型的组合。

2.1 现金贷、分期、BNPL、随借随还：四种产品形态的账务差异

现金贷（短周期小额度）最常见的还款方式是到期一次性还本付息，一笔借款只有一笔应还金额，账务最简单，但逾期率也最高；分期贷款（消费分期、大额分期）使用等额本息或等额本金摊还，每一期按计划拆本金和利息，还涉及服务费、保险费等附加项；BNPL（先买后付）表面是零息分期，真实账务是商家补贴利息，消费者端每期只还本金，逾期后开始生成罚息，所以账务上要区分正常期和违约期；随借随还（循环额度）按日计息、随借随还，用户有授信额度，借一笔生成一笔子合同，额度实时恢复，账务上要额外管理额度台账。

我见过最常翻车的地方，是把 BNPL 当成免息产品不做利息科目，结果商家补贴一到账就成坏账；也见过把随借随还做成固定分期，导致用户提前还完款额度不恢复。买源码之前，先拿这四种产品形态逐一对照你的业务计划，看看这套代码底子支持几种。

2.2 贷款平台的最小完整功能清单：从进件到结清有哪些节点

一套能上线运营的贷款平台，无论源码写得多花哨，功能上绕不开这几个节点：进件（借款人提交资料、APP 或 H5 表单）、授信（规则引擎自动审批或人工审核）、签约（电子合同签署、生成还款计划）、放款（对接资金方或支付通道打款）、还款（主动还款、银行卡代扣、钱包扣款）、贷后（逾期扫描、催收提醒、展期、提前结清）、核销（坏账处理、账务封账）。

每个节点都不是孤立的，它落在订单状态机里。从贷款平台软件源码的视角看，你只需要确认一件事：这七个节点的状态流转是否有独立的领域表，而不是硬编码在页面流程里。比如订单表里要有 APPLY、APPROVED、DISBURSED、REPAYING、OVERDUE、SETTLED、WRITTEN_OFF 这些状态；还款计划表要有 UNPAID、PAID 状态。如果源码里连这些字段都没有，那它只是个原型，不是能跑钱的软件。

2.3 还款计划的数学内核：本金、利息、费用怎么拆才不出错

所有账务问题的起点，是一张正确的还款计划表。这里不是简单的本金除以期数再加利息，而是要考虑摊还顺序、计息起点、四舍五入规则。下面是我在多个项目里反复用的一段生成等额本息还款计划的代码：

def amort_schedule(principal, annual_rate, months, installment_fee=0.0): """ 等额本息还款计划生成器 :param principal: 放款本金，单位元 :param annual_rate: 名义年利率，如 0.18 表示 18% :param months: 分期期数 :param installment_fee: 每期服务费，单位元 :return: 每期计划明细列表 """ monthly_rate = annual_rate / 12.0 if monthly_rate == 0: monthly_payment = principal / months else: # 等额本息公式：M = P * r * (1+r)^n / ((1+r)^n - 1) factor = (1 + monthly_rate) ** months monthly_payment = principal * monthly_rate * factor / (factor - 1) balance = principal schedule = [] for i in range(1, months + 1): interest = round(balance * monthly_rate, 2) principal_part = round(monthly_payment - interest - installment_fee, 2) if i == months: # 最后一期用剩余本金修正，避免浮点尾差 principal_part = round(balance, 2) balance = round(balance - principal_part, 2) schedule.append({ 'period': i, 'due_payment': round(principal_part + interest + installment_fee, 2), 'principal_part': principal_part, 'interest': interest, 'installment_fee': installment_fee, 'balance_after': balance, }) return schedule

这段代码的意图很明确：把一笔贷款拆成每期应还的本金、利息和服务费，并用最后一期修正浮点误差。注意两个关键设计——名义年利率要除以 12 得到月利率，而不是用 360 天或实际天数；服务费单独作为一列，不要混进利率里，否则提前还款时的费用减免逻辑很难写。还有一个隐蔽点：等额本息的实际资金成本不等于名义利率，因为本金在逐期减少，你可以算一下 IRR，会发现它约等于贷款总额一整年都占用的等价利率，这对产品定价很关键。我一般会在产品配置里同时存名义利率和 IRR 两列，方便运营对比。

3. 贷款平台软件源码怎么选：技术栈、目录结构、风控引擎的最小实现

接下来解决最现实的问题：钱该花在哪。在线下评估一套源码值不值时，我不看页面截图，只看三个东西——技术栈、数据库里有多少张账务表、风控规则是不是写死在业务代码里。

3.1 技术栈选型：Java、PHP、Node 分别适合什么团队

市面上的贷款平台软件源码，主流交付形态就三种：Java（Spring Boot / Spring Cloud）、PHP（Laravel / ThinkPHP）、Node.js（Express / NestJS）。Java 的优点是账务系统对事务处理扎实，尤其适合同时跑多个贷款产品的核心系统，但版本迭代慢；PHP 胜在便宜、上线快，很多现金贷源码都是 PHP 写的，但账务精度和并发能力需要额外验证；Node 在 IO 密集型场景好，适合做渠道端接口层，少见整库直接用 Node 跑核心账务。

我这几年见过最典型的翻车，是团队为了快速上线买了一整套 PHP 源码，结果放款金额字段用了 float 类型，账跑了一个月后对不上几块钱。买源码时一定要去代码里搜一下金额字段的类型定义，看到 DOUBLE 或 FLOAT 直接砍价走人，正确做法是 Java 的 BigDecimal、PHP 的 string 或 cent 整数存储。这也是为什么很多团队宁可要一套干净的 Laravel 框架代码自己改，也不要半成品。

3.2 读一套贷款源码：先从目录结构和核心数据表下手

拿到源码不要急着跑起来，先用十五分钟把仓库目录结构过一遍。一套完整的贷款平台源码，目录通常长这样：

loan-platform/ ├── admin-api/ # 管理端接口：产品配置、订单管理、报表 ├── app-server/ # 借款端接口：进件、签约、放款、还款 ├── job/ # 定时任务：逾期扫描、代扣、催收提醒 ├── payment-adapter/ # 支付通道适配层：放款、代扣、退款 ├── risk-engine/ # 风控决策：规则集、评分卡对接 └── gateway/ # API 网关：签名验签、限流

这个结构的意义是：业务接口、定时任务、支付适配、风控决策彼此分离，后续改动时不会互相踩脚。看目录的同时，顺手抓几张核心表的定义，我一般先看这三张：

-- 借款申请/订单主表 CREATE TABLE loan_application ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_code VARCHAR(32) NOT NULL, -- 产品编码，关联产品配置表 user_id BIGINT NOT NULL, amount_cents BIGINT NOT NULL, -- 放款本金，单位分 term INTEGER NOT NULL, -- 期数 status VARCHAR(16) NOT NULL, -- APPLY/APPROVED/DISBURSED/REPAYING/SETTLED created_at DATETIME NOT NULL ); -- 还款计划表 CREATE TABLE repayment_plan ( id BIGINT PRIMARY KEY AUTO_INCREMENT, loan_id BIGINT NOT NULL, seq INTEGER NOT NULL, -- 第几期 due_date DATE NOT NULL, principal_cents BIGINT NOT NULL, -- 本期本金 interest_cents BIGINT NOT NULL, -- 本期利息 status VARCHAR(16) NOT NULL, -- UNPAID/PAID/OVERDUE paid_at DATETIME ); -- 交易流水表 CREATE TABLE transaction_log ( id BIGINT PRIMARY KEY AUTO_INCREMENT, loan_id BIGINT NOT NULL, biz_type VARCHAR(32) NOT NULL, -- LOAN/REPAY/ADJUST/REFUND/WRITE_OFF amount_cents BIGINT NOT NULL, balance_after_cents BIGINT NOT NULL, -- 该笔交易后的贷款余额 happened_at DATETIME NOT NULL );

看这三张表，核心是确认三点：金额是不是以分为单位的整数、还款计划有没有独立表、交易流水有没有保留业务后的余额快照。前两点决定了账务会不会错位，第三点决定了能不能对账。这里有一个血泪经验：很多源码根本没有 transaction_log 表，还款直接 UPDATE 订单状态，这种代码跑一段时间后余额根本无从追溯，资金对账靠手工 Excel，建议直接放弃这种坑货。另外，采购时一定让对方提供源码文件清单和目录结构说明，很多团队要求附带软件著作权登记证书或者完整的代码交付清单，这是确认源码完整度的最低门槛。

3.3 风控引擎最小实现：把决策规则从业务代码里抠出来

一套贷款平台源码里，最容易写死的地方就是风控。好一点的源码会提供规则引擎，差一点的直接写几十个 if-else 散落在服务里。改利率还能忍，改风控规则要发版本，运营和技术的矛盾基本都从这里开始。我推荐的做法是：把决策规则独立成配置，至少做到规则参数和代码分离。

# risk_rules.json 片段 { "rules": [ {"param": "credit_score", "op": ">=", "value": 620, "action": "APPROVE"}, {"param": "monthly_income", "op": "<", "value": 300, "action": "REJECT"}, {"param": "mobile_age_days", "op": "<", "value": 90, "action": "REJECT"} ], "fallback": "MANUAL_REVIEW" }

import json def evaluate_risk(profile: dict, rules_path: str) -> str: """读取规则文件，逐条评估，返回决策结果""" with open(rules_path, 'r', encoding='utf-8') as f: conf = json.load(f) for rule in conf['rules']: val = profile.get(rule['param']) if val is None: continue # 数据缺失该条不生效，避免误杀 op = rule['op'] if op == '>=' and val >= rule['value']: return rule['action'] if op == '<' and val < rule['value']: return rule['action'] return conf['fallback']

这个最小实现的意图是演示规则外置的思路：每一条决策都是参数、比较符、阈值的组合，业务上调整风控口径时只改 JSON，不用改 Java 或 PHP 代码。注意一个关键点：数据缺失时我用 continue，也就是跳过而不是拒绝，因为海外很多用户输入资料不完整，一刀切拒绝会把好客户送给竞品。实际项目中，你还会面临多条件组合、分数叠加、人工复核队列等需求，但那都是在这套“规则外置”思路上的增量。如果源码里根本没有独立的风险引擎目录，而是把风控写死在放款接口里，这套源码的架构就停留在小作坊水平，警惕后面延期和坏账同时找上门。

4. 复刻 Home-credit 海外信贷产品的可配置借贷平台：核心账务与三个最容易写错账的事件

Home Credit 这类海外消费金融公司的打法，核心不是单一产品，而是让业务人员像配商品一样配置贷款产品：利率、期限、还款方式、宽限期、提前还款规则全部参数化，产品经理不碰代码就能发布新贷款产品。这一章我按这个思路拆解实现路径，所有代码都围绕“可配置”展开。

4.1 产品参数化：产品配置表的设计与字段含义

要做到产品可配置，先要有一张足够细的产品配置表。这张表是连接业务和账务的桥梁，字段设计直接决定你以后能不能灵活上新。

CREATE TABLE product_config ( product_code VARCHAR(32) PRIMARY KEY, product_name VARCHAR(64) NOT NULL, min_amount_cents BIGINT NOT NULL, -- 最小放款金额（分） max_amount_cents BIGINT NOT NULL, -- 最大放款金额（分） min_term INTEGER NOT NULL, max_term INTEGER NOT NULL, annual_rate_bp INTEGER NOT NULL, -- 年化利率，基点存储，如 1800 表示 18% repayment_method VARCHAR(16) NOT NULL, -- EMI:等额本息 / ONE_TIME:一次性 / INTEREST_FIRST:先息后本 grace_days INTEGER NOT NULL DEFAULT 0, -- 还款宽限期（天） overdue_daily_rate_bp INTEGER NOT NULL, -- 逾期日罚息率（基点） prepayment_enabled BOOLEAN NOT NULL, -- 是否允许提前还款 extension_enabled BOOLEAN NOT NULL, -- 是否允许展期 fee_config JSON NOT NULL, -- 服务费/保险费等附加费用配置 status VARCHAR(16) NOT NULL DEFAULT 'ACTIVE' );

这是一张典型的消费金融产品参数表。两个最容易忽略的字段：annual_rate_bp 用基点存储而不是小数，是从根源避免浮点误差；grace_days 宽限期独立成字段，是因为很多海外市场还款日遇到节假日需要顺延，硬编码在业务逻辑里每次都改得很痛苦。fee_config 用 JSON 存附加费用项，比如“按放款金额 1.5% 收取服务费”“每期固定 2 美元账户管理费”，既灵活又不需要频繁改表结构。实际操作中，我把这张表的操作权限给到运营角色，每次新上线产品只往里面插一行，业务交付周期从两周压缩到一天。

4.2 还款计划落地与逾期计算：等额本息之外的边界处理

有了产品配置表，生成还款计划的逻辑就可以按 repayment_method 做分支。上一章已经给了等额本息的实现，这里补全另外两个分支，同时加上逾期罚息的计算。

def gen_repayment_plan(principal_cents, product_config, start_date): method = product_config['repayment_method'] annual_rate = product_config['annual_rate_bp'] / 10000.0 term = product_config['max_term'] # 示例取最大期数，实际按订单 if method == 'ONE_TIME': plan = [ { 'seq': 1, 'due_date': start_date + timedelta(days=product_config['grace_days']), 'principal_cents': principal_cents, 'interest_cents': round(principal_cents * annual_rate * term / 12), } ] elif method == 'INTEREST_FIRST': plan = [] monthly_rate = annual_rate / 12.0 for i in range(1, term + 1): interest = round(principal_cents * monthly_rate, 0) plan.append({ 'seq': i, 'due_date': start_date + timedelta(days=30 * i), 'principal_cents': principal_cents if i == term else 0, 'interest_cents': interest, }) else: plan = amort_schedule(principal_cents / 100.0, annual_rate, term) return plan def calc_overdue_fine(remain_amount_cents, overdue_days, daily_rate_bp): if overdue_days <= 0: return 0 rate = daily_rate_bp / 10000.0 return round(remain_amount_cents * rate * overdue_days, 0)

这段代码的意图是演示不同还款方式的分支处理。先息后本在海外现金贷和经营性贷款中很常见，它名义利率远低于等额本息，但资金一直全额占用，所以逾期风险更高；一次性还本付息的利息计算用 term/12 是因为整笔贷款只计息一期，这里要注意 start_date 是放款日还是签约日的区别。逾期罚息计算有几个必须做死的规则：罚息基数只含未还本金和利息，不要滚入本金产生复利；罚息率一般按日万分之几到万分之几十设定，折算年化后要受当地利率上限约束；逾期天数要从到期日次日开始计，不要把宽限期算进去。

4.3 提前还款、展期、借新还旧：三个最容易写错账的事件

账务系统的复杂性，不在正常还款日，而在异常事件。提前还款至少要处理三件事：未到期利息是否全部减免、是否收取提前还款手续费、当期本金和利息的冲销顺序。展期的账务本质是重置还款计划：把当前未还金额平摊到新的期数，同时额外收取展期费，这里最常见的坑是直接把原合同期限往后拉长，导致账龄和逾期天数被隐藏。借新还旧则要小心双重放款：旧合同未结清时新合同又放款，两笔贷款同时处于 REPAYING 状态，资金流向是旧订单归还款、新订单放款，本质是用一笔信息流完成两笔资金流，对账时永远要按合同号区分。

提前还款的调整逻辑，我建议用独立的事务函数来写：

def prepayment_settle(loan_id, prepayment_fee_bp=0): # 1. 还原到当前日期所有未还本金余额 outstanding = get_outstanding_principal(loan_id) # 2. 免收未到期利息，只收本金 + 提前还款手续费 fee = round(outstanding * prepayment_fee_bp / 10000.0, 0) # 3. 生成 SETTLED 状态，记录减免利息金额 create_settle_transaction( loan_id, principal=outstanding, fee=fee, waived_interest=get_unearned_interest(loan_id) )

注意这个函数的执行前提是当前订单没有逾期。逾期订单的提前还款，必须先冲逾期罚息再冲本金，否则账上永远挂着一笔罚息。这里我再强调一次：状态机的每个分支都要有唯一入口，不要贷后模块里改状态、核心账务里也改状态，两个地方改同一个字段早晚会出数据不一致。

5. 海外借贷平台上线前的避坑清单：征信、支付、数据安全的真实翻车点

写系统不是把代码跑起来就完了，接口联调和数据安全才是上线前的重头戏，也是最容易翻车的地方。我按征信、支付、数据安全三条线，把真实的踩坑记录整理出来。

5.1 海外征信与第三方数据源对接：评分卡边界与合规红线

海外借贷平台的进件环节，通常要接三类的数据：身份真实性验证（身份证件、手机号、运营商数据）、征信评分（当地征信局或第三方数据服务）、黑名单（反欺诈名单）。对接时需要做成统一的数据源适配层，因为每家服务商的字段格式和响应时间差异很大。评分卡的用法是在申请时取一次分，再配合规则引擎做决策，不要实时多次调用——会贵到你怀疑人生。

关于这里，我记录一个现象：某个合作方接口在高峰期响应超过 10 秒，我们的进件接口做了同步等待，结果导致借款 APP 直接卡死在“提交中”。原因是把征信调用写成了同步阻塞，没设置超时和降级机制。解决方法是征信调用全部异步化，先给用户一个“审核中”的中间状态，规则引擎在后台完成决策后再推送结果；同时给第三方接口加 3 秒超时和本地缓存黑白名单，缓存命中时根本不用出网调用。另一个合规红线：第三方评分和内部评估维度不能直接拼接成复合变量输出到日志，否则就是隐私泄露。所有征信相关数据只进不出，截图导出要打水印。

5.2 放款与代扣通道的幂等设计：回调时序里的三个坑

支付通道是账务系统最容易出鬼故事的地方。放款和代扣本质上都是异步流程，你的系统发起请求，第三方通道处理完后回调通知结果。这里最经典的坑有三个：重复回调（同一笔订单通知两次）、乱序回调（扣款成功回调先到，放款回调后到）、漏回调（需要主动对账查询）。解决方案只有一个：幂等 + 状态机校验。

def handle_payment_callback(payload): txn_id = payload['transaction_id'] # Redis 分布式锁防重复处理 lock_key = f"pay_callback_lock:{txn_id}" if not redis_client.set(lock_key, '1', nx=True, ex=300): log.info('duplicated callback, skip: %s', txn_id) return trade = payment_record.find_by_txn_id(txn_id) if trade.status == 'SUCCESS': # 幂等：已成功的交易直接返回 return if payload['biz_type'] == 'DISBURSE': loan = loan_repo.find_by_id(trade.loan_id) if loan.status in ('REPAYING', 'SETTLED'): return loan.status = 'REPAYING' create_repayment_plan(loan) elif payload['biz_type'] == 'REPAY': apply_repayment(trade.loan_id, trade.amount_cents)

这段代码的意图是演示回调处理的防御姿态：先拿交易号加锁，处理前检查当前业务状态，已经成功的不重复处理。落库时还要记住——支付回调的金额要以支付通道返回为准，而不是以本地订单金额为准，因为海外通道处理小额代扣时经常有手续费拆分，金额不一致时要以通道侧金额为准生成差异流水，等日终对账再处理。这里我踩过的一个坑是代扣失败短信发给了用户以后，用户自己手动还款成功了，结果系统又在下一个批次把该期标记成逾期。原因是手动还款成功没有立即解除该期的正常委托代扣标记。解决方法是还款成功时同步取消未执行的代扣计划，这个逻辑在源码里要明确找到，否则就是无声的资金占用。

5.3 PII 数据安全三件套：脱敏、日志清理、保留与销毁

海外对个人敏感信息的监管一年比一年严，这不是政策问题，是生存问题。贷款系统里用户手机号、证件号、银行卡号是最高频的敏感字段，至少要落地三层：存储加密（AES 加密敏感列）、展示脱敏（管理后台和客服工具实时打码）、日志过滤（禁止把请求体原样打出来）。

def mask_phone(phone: str) -> str: if len(phone) < 7: return '****' return phone[:3] + '****' + phone[-4:] def mask_id_num(uid: str) -> str: if len(uid) < 8: return '****' return uid[:4] + '********' + uid[-4:]

脱敏函数的意图是让所有能在界面上看到 PII 的地方只展示打码后的结果，真实值只允许在强权限的审核接口里按需解密。这里有一个我记忆深刻的教训：测试环境为了方便调试，直接把生产库导入测试库，测试库里所有用户手机号和身份证号明文可查，查询日志里也带着完整请求参数。原因是没有做数据漂白和日志脱敏的强制流程。解决方法是生产到测试的数据同步必须走脱敏脚本，并且把日志网关层的 filter 加上关键字清洗规则。另外，交易流水和用户数据要有明确的保留周期，过期的要定时销毁，不要因为“万一以后用得上”就把底层数据无限期留着，留着就是风险敞口。

6. 全链路演练与对账脚本：验收一套贷款源码值不值得上生产

最后一步不是上线，是先做一轮全链路账务演练。我拿到任何一套贷款源码，第一件事是拿小金额产品跑一遍“进件—放款—部分还款—全部结清”的完整流程，顺便插一笔逾期订单进来，看罚息是不是跟手工计算一致。这个过程里，最有用的乱账查杀工具是一段平账校验 SQL：

SELECT account_date, SUM(CASE WHEN biz_type = 'LOAN' THEN amount_cents ELSE 0 END) AS total_disbursed, SUM(CASE WHEN biz_type = 'REPAY' THEN amount_cents ELSE 0 END) AS total_repaid, SUM(CASE WHEN biz_type = 'WRITE_OFF' THEN amount_cents ELSE 0 END) AS total_written_off FROM transaction_log GROUP BY account_date HAVING total_disbursed - total_repaid - total_written_off != 0;

这段 SQL 的意图是每天核对资金等式：当日放款总额减当日还款总额与核销总额，理论上应该等于当日新增的未偿本金余额，不一致就说明有某笔交易没有正确落到存量和余额。我习惯再补一张按 loan_id 聚合的校验表，把每个订单的本金收支算一遍，和还款计划表的未还本金对平，任何一笔差异都要在当天定位到具体订单。全链路演练至少要跑三种数据量级：最小金额、最大金额、含服务费和逾期的复杂订单，每种都要拿到手工计算确准的预期值再快照比对。

这里我说一个自己的习惯：验收阶段从来不看管理后台的报表页面，报表都是别人写好的视角，我只看三张原始表——订单表、还款计划表、交易流水表，自己写 SQL 用最笨的方式核对。界面好看的源码到处都是，账务扛打、又能参数化扩展产品线的贷款平台源码才是真的稀缺货。买之前先按这个办法跑一遍，能省掉上线后无数个对账的深夜。希望帮到你。

本文还有配套的精品资源，点击获取