婚恋交友PHP源码实战：部署、匹配、安全全解析

简介：这套婚恋交友 PHP＋MySQL 源码，是一份完全开放、无需付费即可部署使用的建站程序，面向具备基础 PHP 知识和二次开发能力的中小网站开发者、创业者。整体采用粉红色系视觉模板，贴合婚恋交友类产品定位；除了前台注册登录、会员展示等常规模块，还提供了后台管理入口与内置管理账号，方便快速体验系统前后台功能。压缩包内共有文件一千四百余个，包体大小约六点六六兆字节，其中 PHP 文件一百九十三个承担后台核心逻辑，CSS 样式表八十个与 JavaScript 文件二十七个负责前端界面与交互，另有大量 GIF、JPG 图片作为模板视觉素材，同时含 SQL 数据库脚本，便于初始化数据。由于环境中 PHP 版本或配置可能存在差异，压缩包内也给出了全局配置文件用途说明，按提示调整显示即可。目前已有四千七百余人学习下载，适合作为低成本启动中小型婚恋交友项目的参考模板，也适合 PHP 学习者对照真实业务进行实战练习。

1. 婚恋交友 PHP 源码的价值不在「开源」二字，而在你能自己掌控匹配规则与用户数据

「破除婚恋交友收费」「目前网络上最好的源码资源」——源码下载站上这类标题并不罕见，但真正值得你花时间的不是营销话术，而是这套婚恋交友 PHP 源码把用户注册、资料标签、匹配推荐、私信聊天、会员体系完整地摊开在你面前。它解决三个实际问题：不用按年给商业婚恋平台交授权费，不担心用户数据被第三方平台锁定，想按自己目标人群重写匹配规则。适合想快速上线垂直交友产品做验证的开发者，也适合拿整套 UGC 系统练手的 PHP 学习者。最小可运行闭环比你想的短，但部署和生产落地的坑，一点不少。

2. 从标题拆出真实构成：技术栈、授权模式与部署形态

拿到一个标题先做拆解，不急着解压。这套源码从标题能判断出的关键信息是三个：基于 PHP、面向婚恋交友场景、宣称完全开源。它们分别决定技术栈选型、业务功能范围和上线成本结构。这一章把这三件事讲透，你后续部署时才不会被「全网最好」这种话带偏。

2.1 「破除收费」的真实含义：零授权费换的是数据自主

「破除婚恋交友收费」这句话第一次读很容易理解偏，以为是通过什么手段绕过商业平台的会员收费。你把它理解成「自托管替代订阅制」就对了：商业婚恋 SaaS 按年收软件服务费，用户资料、匹配规则、界面品牌都绑在平台上；开源源码则是把程序部署到你自己的服务器，数据库在自己手里，界面标识和功能开关也由你控制。它破的是「软件授权成本」，不是「运营成本」。短信验证码按条计费、实名认证接口按次计费、对象存储按流量计费，这三笔钱无论用开源还是商业方案都省不掉。我做垂直交友项目时吃过一次亏，以为开源版等于零成本，结果上线首月光短信费就花掉几百块。

做预算时把账单模型分两层看：一层是源码使用费，开源版确实是零；一层是基础设施和第三方接口费，这部分按量计费一个不少。想清楚这点，后面评估投入时心态就稳了，不会因为源码免费就低估整体成本。

2.2 读懂源码目录：入口、模块、资源一层层拆开

解压前先静态读目录结构，能避开后续一大半排障。下面是一份典型的婚恋交友 PHP 源码的目录形态：

. ├── index.php ├── app/ │ ├── common.php # 公共函数：鉴权、格式化、防注入 │ ├── config/ │ │ ├── database.php # 数据库连接配置 │ │ └── app.php # 站点名、密钥、分页参数 │ ├── controller/ # 注册登录、匹配、聊天、会员控制器 │ └── model/ # 数据模型与查询封装 ├── public/ │ ├── static/ # CSS、JS、图片资源 │ └── upload/ # 用户头像与相册目录 ├── runtime/ # 日志与缓存目录，需要写权限 └── install/ └── sql.sql # 初始表结构与演示数据

这个分层是 PHP 项目最常见的 MVC 形态。看两个位置就能判断改动成本：前端模板如果放在独立 view 目录，说明走模板渲染，改页面结构比改接口慢；public/static 下的 JS 如果是压缩后的单文件，说明前端是传统 jQuery 混编，要做移动端改造就得整个重写前端。我拿到源码的习惯是先数 install/sql.sql 里的建表语句：表少于 20 张，功能精简，适合快速验证闭环；50 张以上，说明会员、订单、消息、标签体系齐全，二次开发工作量也会上来。顺便看一眼里面有没有 demo 前缀的演示账号，有的话到第 5 章我会专门讲清理的事。

2.3 源码完整性自检：入口、数据库脚本与外部依赖

下载站提供的源码包，解压前最好做一次完整性自检，避免装到一半才发现缺文件。自检分三步：看有没有完整的 SQL 脚本、看有没有 composer 依赖、看有没有可疑的混淆代码。第一步直接列目录：

ls -la install/ file install/sql.sql

sql.sql 存在并且 file 命令识别为 UTF-8 文本，说明数据库脚本大概率完整。如果文件被识别成 Non-ISO extended-ASCII 之类的编码，先转码再导入，不然中文数据会变乱码。第二步检查框架依赖：

ls composer.json 2>/dev/null || echo "无 composer 依赖" ls vendor/ 2>/dev/null | head -5 || echo "vendor 目录缺失"

有 composer.json 但 vendor 目录缺失，说明解压后要先跑一次 composer install 才能运行；连 composer.json 都没有，说明是纯手写原生 PHP，依赖少，但业务代码里的维护成本会高一些。第三步排查可疑代码，下载站的源码偶尔会夹带私货：

grep -rn "eval(\|base64_decode(" app/ controller/ 2>/dev/null | head -10

命中这些函数不代表一定是后门，但要逐行看上下文。如果是一整段看不出含义的混淆乱码，建议直接弃用换一份源码。这个检查只要一两分钟，能省掉上线后被挂马的后悔药。

2.4 运行环境取舍：PHP 版本和 Web 服务器的选择

绝大多数婚恋交友 PHP 源码基于 PHP 7.4 或 8.0 开发，数据库用 MySQL 5.7/8.0 或 MariaDB 10.x 都能跑。老源码直接上 PHP 8.1 以上最常见的报错是废弃函数被移除，比如 split 一类的旧函数，以及隐式类型转换行为变化。我的判断方法是先看源码里有没有 mysql_ 开头的旧数据库函数，或者代码里有没有用 @ 抑制错误的老写法；有这些特征，PHP 版本就往 7.4 选，兼容性最稳。

Web 服务器方面，Apache 支持 .htaccess，适合第一次做伪静态的人，RewriteRule 写错还能靠服务器日志逐条看；Nginx 性能好、内存占用低，但伪静态规则得手写进 server 块。生产环境我用 Nginx，本地验证用内置服务器就够了。

如果还想继续往下确认，本地开发环境直接用命令行把 PHP 模块查一遍，比图形面板更直接：

php -v php -m | grep -E "pdo_mysql|mbstring|openssl|curl|gd|fileinfo"

grep 结果缺哪个，对应功能会在跑起来后立刻现形：缺 pdo_mysql 数据库全挂；缺 gd 头像无法生成缩略图；缺 curl 短信和支付接口调用直接失败。环境检查完，就可以进入下一章的导入流程。

3. 本地跑通最小命令集：从零到看到首页

环境确认没问题后，进入一套可以直接复现的导入流程。这章给出的命令都是最小集合，目标只有一个：让首页在本地浏览器里出现。每一步做完都有验证方式，不至于跑完一堆命令还不知道成没成功。

3.1 解压、权限与入口检查：动手前先做三件小事

拿到压缩包后先解压到固定目录，不要直接扔进 Web 根目录完事：

unzip love_source.zip -d /var/www/love_site cd /var/www/love_site chmod -R 755 public/upload runtime ls -la index.php

chmod 755 的作用是把目录读权限和进入权限交给运行用户，upload 和 runtime 两个目录必须有写权限，否则后面头像上传、日志写入都会在运行时报「目录不可写」。这里要确认你当前的 CLI 用户和 Web 服务运行用户一致，不一致的话即使 chmod 了也会在运行时提示权限不足。ls 出来的 index.php 是普通文件还是符号链接值得看一眼，有些源码包会把入口做成软链指向别的盘符，后续迁移服务器时会断链，页面白屏半天找不到原因。

接着看入口文件前 20 行：

head -20 index.php

正常入口会定义常量或引导框架，比如 define('APP_PATH',DIR) 或者 require vendor/autoload.php。如果看到的是跳转 install 目录的逻辑，说明安装向导优先，这时先去浏览器跑安装向导，或者顺手把 install 目录改名，防止每次访问都弹安装页。我见过有人部署完首页一直跳安装向导，就是改配置时忘了处理 install 目录。

3.2 建库导数据：字符集选错会后患无穷

入口确认后先建库，这一步别用图形界面点，直接用 MySQL 命令行最可控：

mysql -uroot -p -e "CREATE DATABASE IF NOT EXISTS love_site DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;" mysql -uroot -p love_site < install/sql.sql mysql -uroot -p love_site -e "SHOW TABLES;"

三条命令分别做三件事：创建带 utf8mb4 字符集的数据库，把初始表结构和演示数据导入，验证表是否真的建出来了。字符集这里要强调一下，有人图省事用默认的 latin1 或者旧版 utf8，跑起来以后用户昵称带 emoji 会直接报错Incorrect string value: '\xF0\x9F\x98\x81'。utf8mb4 是中文场景的底线，它兼容 emoji，排序规则用 utf8mb4_unicode_ci 对中文和英文的排序都比较友好。SHOW TABLES 执行完，记录一下表数量，和第 2 章数出来的建表语句数量做对照，数量对不上说明导入过程中途报错中断。

如果导入时直接报错，不要反复重试同一个文件，先看错误提示指向哪一行。常见原因是 SQL 文件里带了过时的字段定义，或者文件本身是 GBK 编码。用 iconv 转成 UTF-8 再导：

iconv -f GBK -t UTF-8 install/sql.sql > install/sql_utf8.sql mysql -uroot -p love_site < install/sql_utf8.sql

注意转码只针对确认是 GBK 编码的文件，已经是 UTF-8 的再转一次反而会把内容弄乱。

3.3 改配置与启动：三个必改参数别漏

数据库导完，剩下的就是让程序知道连哪个库。打开 app/config/database.php：

<?php // app/config/database.php return [ 'host' => '127.0.0.1', 'port' => 3306, 'database' => 'love_site', 'username' => 'root', 'password' => '你的数据库密码', 'prefix' => 'l_', // 表前缀，同库跑多项目时防冲突 'charset' => 'utf8mb4', ];

每次拿到新源码我都只改三个参数：database、username、password，其余保持默认。prefix 有特殊用途，你如果要在同一个数据库里跑两个婚恋站做对比，其中一个把前缀改成 l2_ 就能直接复用同一套库而互不干扰。host 默认不动，连远程数据库时才改成云数据库地址。改完配置顺手确认一下文件里没有藏着 debug 模式开关，把它关掉，避免上线后把 SQL 语句直接打印在页面上。

然后启动内置服务器验证：

php -S 0.0.0.0:8080 -t public public/index.php

浏览器访问 http://127.0.0.1:8080 看到首页，最小闭环就通了。php -S 是 PHP 自带开发服务器，-t 指定文档根目录为 public，最后的 public/index.php 是路由器脚本，因为框架所有请求都打在入口文件上。注意这个方式只能用于本地验证，它单线程、无并发能力，真正对外服务还是要上 Nginx。

提示：如果首页能打开但样式全丢，优先检查 public 目录下的静态资源路径，这通常是伪静态规则或 base 路径配置的问题，第 5 章会详细排查。

4. 拆开核心模块看实现：匹配、聊天与会员的常规做法

首页跑通只算拿到钥匙，婚恋交友系统真正值钱的是业务层：推荐匹配怎么做、私信怎么实时收、会员怎么收费。这一章拆三个核心模块，给的是最常见、最省成本的实现路径，也是你二次开发时改动最频繁的三块。

4.1 匹配算法从标签重叠开始：权重参数是调教重点

绝大多数开源婚恋系统的匹配第一版就是「标签重叠优先」。用户注册时选兴趣、性格、收入区间之类的标签，系统把和你标签重叠最多的用户排在前面。实现上就是一张关联表 l_user_tag，查询用简单的 JOIN 加 GROUP BY：

SELECT u.id, u.nickname, u.city, u.last_login_at, COUNT(ut.tag_id) AS match_cnt FROM l_user u JOIN l_user_tag ut ON ut.user_id = u.id WHERE ut.tag_id IN ( SELECT tag_id FROM l_user_tag WHERE user_id = :uid ) AND u.id != :uid GROUP BY u.id ORDER BY match_cnt DESC LIMIT 20;

核心逻辑是筛选出包含你任意标签的用户，再按共同标签数倒序。这个查询在表量不大的时候跑得很快，用户量到几万以后就要加索引，索引建议落在 (tag_id, user_id) 上。参数 :uid 是当前登录用户，LIMIT 20 决定单页推荐数量，用户量上来后可以改成分页。

但光有共同标签不够，实际运营发现用户更在意「最近活跃」和「同城」。推荐池里太久没登录的账号，会让新用户觉得平台没什么人。我一般会在 SQL 查出候选列表后，再叠加一个加权打分：

function sortCandidates($user, array $candidates) { foreach ($candidates as $candidate) { $score = $candidate['match_cnt'] * 10; // 共同标签：每个 10 分 $daysSinceLogin = floor((time() - strtotime($candidate['last_login_at'])) / 86400); $score += max(0, 5 - $daysSinceLogin); // 一周内登录过才有活跃分 if ($candidate['city'] === $user['city']) { $score += 15; // 同城加分 } $result[] = ['user' => $candidate, 'score' => $score]; } usort($result, fn($a, $b) => $b['score'] <=> $a['score']); return $result; }

中间这个函数把候选列表重新打分。三个系数 10、5、15 就是调教匹配体验的旋钮：同城对你的人群更重要，就把 15 往上调；想让平台显得有活力，就把活跃分权重加大，甚至可以改成一个月内登录都给分。参数没有标准答案，上线后看用户行为数据再调，这是匹配模块最好玩也最玄学的部分。

4.2 私信聊天最省钱的做法是轮询，规模上来再换长连接

婚恋系统的私信是最基础的交互，第一版没必要上 WebSocket。轮询方案 30 行代码就能跑通：前端每隔 3 秒请求一次新消息，后端按消息 ID 增量返回。

// 轮询新消息，lastId 记录当前最大消息 ID setInterval(function () { fetch('/api/chat/poll?room_id=' + roomId + '&last_id=' + lastId) .then(function (res) { return res.json(); }) .then(function (data) { if (data.list.length > 0) { lastId = data.list[data.list.length - 1].id; appendMessages(data.list); } }); }, 3000);

服务端这边就是一条增量 SQL：

// 拉取该会话内 id 大于 last_id 的消息 $stmt = $pdo->prepare( 'SELECT id, user_id, content, created_at FROM l_chat_messages WHERE room_id = ? AND id > ? ORDER BY id ASC LIMIT 50' ); $stmt->execute([$roomId, $lastId]);

这条 SQL 的关键是用主键当游标，而不是用时间戳。原因很简单：同一秒内可能进来多条消息，用时间戳做增量会丢消息或重复拉取，用自增 id 就不会。LIMIT 50 是给极端情况兜底，防止一次拉太多把接口打满。轮询的缺点也明显：每个用户每 3 秒一个请求，在线量到几百人，PHP-FPM 的进程数会被占满。所以轮询适合用户量小的起步期，日活在几百以内都没问题。

会话列表的排序是容易忽略的细节。发完消息后，记得更新会话表的最后消息时间：

UPDATE l_chat_rooms SET last_message_at = NOW() WHERE id = ?;

如果没有这个字段，会话列表永远按创建时间排，用户回了消息列表看起来像沉底一样，体验很差。

4.3 会员与付费体系：开源版通常只做到「虚拟支付」为止

开源婚恋系统的会员功能一般能覆盖到「展示会员特权、生成订单、记录充值」这一步，但真实支付网关很少直接集成，因为每家平台商户号对接方式不一样。拆开看你会发订单表里有支付方式字段、有回调地址字段，但支付回调逻辑可能是写死的虚拟回调。这意味着上线前得补一个真正的支付接入。以主流支付平台为例，必做的三个点是：统一下单拿支付链接、前端展示二维码、用户付完异步回调里校验签名和金额。

校验时最容易漏的是金额校验和重复回调处理：

// 支付回调处理的前两步校验，缺一不可 $isSignOk = verifySign($_POST); // 平台签名机制 $isAmountOk = (int)$_POST['total_fee'] === $order['amount']; // 金额精确匹配 $orderPaid = (int)$order['status'] === 1; // 防止重复发货

三条校验分别对应签名被伪造、订单金额被篡改、回调重复请求三个问题。签名验证用支付平台给出的 SDK 方法，金额比较时注意单位，支付回传的 total_fee 单位是分，而数据库里如果用元存储，直接比较就会翻车。这些逻辑虽然每加一个支付渠道都要重写一遍，但把校验函数抽成公共方法后，下次接另一家平台就是换个 SDK 的事。

会员套餐的设计建议在后台做成可配置的：免费用户能看到谁喜欢我、每天可以打招呼 5 次；付费用户解锁无限制打招呼、查看访客记录、置顶曝光。价格可以参考同类产品，但真正决定转化率的是「免费功能卡得多狠」和「付费功能是否戳中痛点」。这套参数直接放在后台配置表里，别写死在代码里，运营每天都要调。

5. 部署时最容易翻车的五个位置：安全加固与排查清单

本地跑通和生产部署是两回事。这一章把我在部署婚恋交友系统过程中真正踩过的坑按「现象、原因、解决」列出来，每一条都有具体症状，方便你在遇到问题时直接对照。

5.1 数据库连接失败：权限、编码、时区三板斧

现象：页面提示SQLSTATE[HY000] [1045] Access denied for user，或者Connection refused。

原因分三种：密码里带了特殊字符没转义、MySQL 用户权限没给够、PHP 配置里的连接地址指向了错的 socket。密码带特殊字符是最常见的，配置文件里用了双引号包字符串，$开头的内容被当成了变量解析；socket 问题则多出在 PHP 和 MySQL 装了不同版本，默认 socket 路径不一致。

解决：连接参数全用单引号，密码里含特殊字符时先确认没被转义；权限不足时执行授权语句：

GRANT ALL PRIVILEGES ON love_site.* TO 'root'@'127.0.0.1' IDENTIFIED BY '密码'; FLUSH PRIVILEGES;

连接地址连不上的，把 host 从 127.0.0.1 改成 localhost 再试一次，让 PHP 走 socket 连接而不是 TCP。

5.2 首页能开详情页 404：伪静态规则没对上

现象：首页正常，但点进用户主页、私信页面全部 404，报nginx/1.x 404 Not Found。

原因：程序内部用的是路由形式访问，比如/user/detail?id=1要走 index.php 分发，Nginx 配置里没有把请求 rewrite 给入口文件，服务器拿真实路径去找文件，找不到就 404。

解决：在 Nginx 站点配置的 server 块里加上：

location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s=$1 last; } } location ~ \.php$ { include fastcgi_params; fastcgi_pass unix:/run/php/php7.4-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }

加完执行nginx -t验证语法，再 reload。不同框架的路由参数名不一样，有的用s，有的用r，具体看入口文件里怎么解析的。

5.3 头像上传变成 webshell：只校验了 MIME 没校验扩展名

现象：用户上传了一个「图片」，实际是 PHP 一句话木马，服务器被拿去挖矿。

原因：老源码做图片校验时只检查了文件的 MIME 类型，攻击者把 PHP 文件扩展名改成 jpg 上传，配合服务器解析漏洞直接执行。更隐蔽的是图片头里嵌 PHP 代码，靠文件内容检测也拦不住。

解决：上传保存时做三层限制。扩展名白名单、真实文件类型校验、存储路径禁止执行脚本：

// 上传头像时只放行图片扩展名，且不允许直接在 upload 目录执行 PHP $allowExt = ['jpg', 'jpeg', 'png', 'gif', 'webp']; $ext = strtolower(pathinfo($_FILES['avatar']['name'], PATHINFO_EXTENSION)); if (!in_array($ext, $allowExt, true)) { exit('不支持的图片格式'); }

同时给 upload 目录加 Nginx 配置，禁止解析该目录下的 PHP 文件：

location ~ ^/upload/.*\.(php|php5|phtml)$ { deny all; }

这条规则加上后，即使攻击者成功传了恶意文件，访问时也只会得到 403，不会执行。

5.4 短信验证码接口被刷：忘记做频率限制

现象：上线第二天，短信服务商后台显示发送量暴涨，一晚上发出上千条验证码，余额迅速清零。

原因：注册和找回密码接口没做限频，攻击者用脚本批量提交手机号，每条验证码都是一笔真实费用，刷量直接变成你的账单。

解决：在服务端做两层限制，第一层同一手机号 60 秒内只能发一次，第二层同一 IP 每小时最多发 10 次：

// 同一手机号 60 秒内只能发一次 $key = 'sms_interval_' . $mobile; if ($redis->get($key)) { exit('发送频率过高，请稍后再试'); } $redis->setex($key, 60, 1); // 同一 IP 每小时限 10 次 $ipKey = 'sms_ip_' . $ip; $count = $redis->incr($ipKey); $redis->expire($ipKey, 3600); if ($count > 10) { exit('当前网络环境发送次数过多'); }

两个限制都做完，短信被刷的概率就低很多了。如果源码没接 Redis，可以把计数器存在数据库表里，效果一样，只是性能差一些。

5.5 演示数据和默认账号没清理：上线就被「接管」

现象：正式上线后收到用户投诉，说看到一堆昵称奇怪的账号在系统里活跃，甚至有人用默认密码登录了管理员后台。

原因：源码自带的演示数据没有清理，下载站的源码包里通常有 admin/123456 这类默认账号，还有一批测试用户。网络上有专门的脚本会扫描这类源码的默认入口，拿到后台权限。

解决：上线前写几条清理语句，把演示数据、测试账号、默认密码全部处理掉：

DELETE FROM l_user WHERE nickname LIKE 'demo%' OR user_name = 'admin'; UPDATE l_user SET password = MD5('重新设置强密码') WHERE user_name = 'admin'; DELETE FROM l_user_tag WHERE user_id NOT IN (SELECT id FROM l_user);

清理完还要检查一下后台地址是不是默认的 admin 路径，能改就改掉。这一条是最容易被忽略的，但往往是最致命的一条，默认账号被拿去发垃圾私信，平台信誉直接崩。

注意：以上五条每一条都对应真实发生过的故障，排查时按顺序来，先把默认账号和上传目录处理了，再谈业务功能优化。

6. 从一个能跑的源码到值得运营的系统：三个进阶改动

本地能跑、线上能开，这只说明「能用」，离「好用」还差三个改动。按投入产出比排序，依次是推荐池冷启动、私信防滥用、数据备份演练。

第一个改动是给推荐模块加活跃度权重。源码默认的推荐是注册时间倒序，新用户永远排在前面，但老用户里高质量、常上线的账号反而被埋没。常见做法是在推荐查询里加一个 last_login_at 的排序因子，比如最近 7 天登录过的账号权重加一档，同城加一档。改完观察两周，看首页到资料页的转化率有没有变化。第二个改动是给私信加频率和敏感词双保险。轮询能跑通但拦不住骚扰，同一用户 60 秒内最多发 5 条消息，超出就提示，敏感词命中直接转人工审核。这套逻辑写在发消息的公共方法里，改动量不大，但对平台风气影响非常直接。

第三个改动是每日备份和恢复演练。婚恋系统的数据比代码值钱，用户资料和聊天记录丢一次就真的没了。写一个定时任务每日凌晨导出数据库和 upload 目录：

# 每周日凌晨全量备份，其余时间增量备份 MySQL 数据 mysqldump -uroot -p --single-transaction love_site | gzip > /backup/love_$(date +%F).sql.gz

别让备份脚本只停留在跑通，每季度要实际恢复一次到测试库，确认备份文件真的能还原，而不是看着文件大小像那么回事。这三件事做完，这套婚恋交友 PHP 源码才真正从「能跑」变成「敢上线」。回看我做过的项目，最亏的一次教训就是省掉了默认账号清理，被刷了三天垃圾消息才反应过来，从那以后我把第 5 章的检查清单当成了上线前置条件，少一步都不发版。希望你按这套流程跑下来，也能避开那些绕远的路。

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