简介一份企业级「交友社群找搭子陪玩点单」系统的完整前后端源码适合有开发基础、希望研究社交/陪玩平台架构或直接部署运营的技术人员。压缩包为zip格式内含2002个文件其中以1237个JavaScript脚本与688个CSS样式表为主配合Vue组件、SQL数据库脚本、Markdown说明及JSON/XML配置覆盖前端界面、交互逻辑、后端服务、数据表结构等全链路。功能上包含社群圈子、搭子匹配、点单服务等核心模块整体达企业运营级别。已有416人下载学习实用性获认可。相较市面上万元级同行方案这套代码完整度高可部署用于二次开发或运营参考由于不附带教程需要使用者具备独立搭建环境、排查代码问题的能力不建议小白直接上手。1. 交友社群系统源码它不是一个聊天室而是一套完整的点单交易闭环交友社群系统源码在网上一搜一大把但大多数只是把用户表、朋友圈、后台模板拼在一起真正能上线收单的没几个。这套源码不一样它把“找搭子”和“陪玩点单”放在同一条业务链路里用户在圈子里发动态找搭子搭子里有人挂出服务、有人点单点单走到微信支付支付成功后推进订单状态后台自动做佣金结算。作者定价 1w包了前端 H5、后端 PHP 代码和数据库脚本。适合三类人想做同城搭子或游戏陪玩平台但不想从零写起的运营者需要一套可扩展骨架做二次开发的 PHP 后端以及想认真研究订单状态机、支付回调、余额结算这套标准流程的开发者。2. 模块拆解与数据表结构一张订单表如何承载整套点单业务拆这套源码我先从数据表入手。数据库脚本是整套系统的骨架表设计基本决定了业务边界。整套库一共二十多张表核心业务面是六个用户、圈子、动态、订单、余额、平台收入。把这几张表读懂系统能做什么、不能做什么就一目了然了。2.1 用户与圈子社群关系链用什么表承载用户表是整套系统的基础和普通用户表不一样的是它需要承载“搭子”和“服务者”双重身份。我在源码里看到的字段设计是用户同时有status账号状态和is_service是否开通服务者权限两个关键字段。也就是说同一个用户既可以作为消费者下单也可以作为陪玩接单身份切换只改一个字段。CREATE TABLE fw_user ( id int(11) unsigned NOT NULL AUTO_INCREMENT, nickname varchar(50) NOT NULL DEFAULT COMMENT 昵称, avatar varchar(255) NOT NULL DEFAULT COMMENT 头像, gender tinyint(1) NOT NULL DEFAULT 0 COMMENT 性别 0未知 1男 2女, is_service tinyint(1) NOT NULL DEFAULT 0 COMMENT 是否服务者 0否 1是, status tinyint(1) NOT NULL DEFAULT 1 COMMENT 状态 -1禁用 1正常, created_at int(11) NOT NULL DEFAULT 0 COMMENT 注册时间, PRIMARY KEY (id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;这里is_service字段特别关键它在后续订单逻辑里决定了谁能被点单。created_at用 int 类型存时间戳而不是用 datetime这套源码里所有时间字段都是这种风格查询排序效率高但看数据时不够直观需要转格式。当然光有用户表还不够圈子关系链需要单独的表来维护。fw_circle存圈子本身的信息fw_circle_member存成员关系。会员表要特别注意它不是简单记录谁在圈子里还带了is_owner是否圈主和status是否被移出字段。这个设计的用意是圈主能管理成员被移出的人仍然有记录可查而不是把数据删掉。CREATE TABLE fw_circle_member ( id int(11) unsigned NOT NULL AUTO_INCREMENT, circle_id int(11) NOT NULL COMMENT 圈子ID, user_id int(11) NOT NULL COMMENT 用户ID, is_owner tinyint(1) NOT NULL DEFAULT 0 COMMENT 是否圈主 0否 1是, status tinyint(1) NOT NULL DEFAULT 1 COMMENT 状态 0移出 1正常, join_time int(11) NOT NULL DEFAULT 0 COMMENT 加入时间, PRIMARY KEY (id), KEY idx_circle_user (circle_id,user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT圈子成员表;联合索引idx_circle_user是查询的主力查某个圈子有哪些人、某个人加了哪些圈子都走这个索引。很多人建表时忽略这种联合索引导致圈子页面数据量大后查询越来越慢这套源码在这点上做得算规范。2.2 找搭子的信息流动态、标签与匹配记录“找搭子”功能表面上是一个动态发布模块实际上比普通朋友圈多了一层标签匹配逻辑。用户发动态时可以选择标签比如“王者上分”“羽毛球搭子”“剧本杀组队”这些标签落在fw_tag和fw_post_tag关联表里。匹配的逻辑是系统根据当前用户的历史标签在推荐流里优先推送标签重合度高的动态。CREATE TABLE fw_post ( id int(11) unsigned NOT NULL AUTO_INCREMENT, circle_id int(11) NOT NULL DEFAULT 0 COMMENT 所属圈子ID0表示广场, user_id int(11) NOT NULL COMMENT 发布者ID, content text NOT NULL COMMENT 动态内容, images varchar(1000) NOT NULL DEFAULT COMMENT 图片逗号分隔, like_count int(11) NOT NULL DEFAULT 0 COMMENT 点赞数, comment_count int(11) NOT NULL DEFAULT 0 COMMENT 评论数, status tinyint(1) NOT NULL DEFAULT 1 COMMENT 1正常 0删除, created_at int(11) NOT NULL DEFAULT 0, PRIMARY KEY (id), KEY idx_circle_time (circle_id,created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT动态表;这里注意like_count和comment_count是冗余字段每次点赞、评论都在事务里和计数表一起更新。这种设计牺牲了一点写入性能换来的是列表页不需要每次 count 一次对社群这种读多写少的场景非常合适。匹配记录表很有意思它的作用不是长期保存而是记录“撮合过程”。当用户发起找搭子请求系统会插入一条fw_match_record状态是“待对方同意”。如果对方同意了数据会写入好友关系表fw_contact匹配记录本身则保留作为统计素材。这让我想到一个常见的坑很多人会把这种中间状态直接放在好友表里好友表被频繁更新业务逻辑越来越难理清。拆这个模块的时候可以学到“临时关系”和“稳定关系”分表处理的思路。2.3 陪玩点单订单表的状态流转设计订单表是整套系统最核心的表也是这次拆解的重头戏。它的字段设计比较完整业务上的每个操作节点都有对应字段。订单状态用数字表示比字符串更省空间、查询更快但可读性差后面我会给一张完整的状态映射表。CREATE TABLE fw_order ( id int(11) unsigned NOT NULL AUTO_INCREMENT, order_no varchar(32) NOT NULL COMMENT 订单号, user_id int(11) NOT NULL COMMENT 下单用户ID, service_user_id int(11) NOT NULL COMMENT 服务者用户ID, service_type tinyint(1) NOT NULL DEFAULT 1 COMMENT 服务类型 1游戏陪玩 2陪练 3技能服务, hours decimal(10,1) NOT NULL DEFAULT 1.0 COMMENT 服务时长(小时), amount decimal(10,2) NOT NULL COMMENT 订单金额, status tinyint(1) NOT NULL DEFAULT 0 COMMENT 状态 0待支付 1待接单 2进行中 3已完成 4已取消, transaction_id varchar(64) NOT NULL DEFAULT COMMENT 微信支付流水号, created_at int(11) NOT NULL DEFAULT 0 COMMENT 下单时间, paid_at int(11) NOT NULL DEFAULT 0 COMMENT 支付时间, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id), KEY idx_service_user_id (service_user_id), KEY idx_status_created (status,created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;状态流转是这套系统的核心逻辑五个状态之间的转换关系必须理清楚状态值含义触发动作0待支付用户下单生成订单号1待接单支付回调成功等待服务者接单2进行中服务者确认接单3已完成服务完成系统完成结算4已取消用户主动取消或超时系统自动取消源码里的状态变更都封装在 OrderService 里前置条件是每次状态变更必须检查当前状态。举个例子从“进行中”到“已完成”会先查status 2否则直接抛异常。这是防止重复回调、重复结算的第一道防线。2.4 技术栈选型PHP MySQL Redis 为什么够用这套源码用的是原生 PHP 加少量框架风格代码没有引入重框架。存储层是 MySQL 加 Redis。这个选型对这类项目非常合适点单业务的事务密集在支付回调和结算环节PHP 处理这类请求没有性能瓶颈部署成本也低。在这个业务体量下Java 或 Go 的部署和维护成本是 PHP 的三倍以上收益却体现不出来。Redis 在系统里承担三个职责并发下单锁、热点数据缓存、在线状态统计。下单时的 Redis 锁我在第 4 章会详细说。热点缓存指的是圈子热度榜、服务者在线列表这类数据缓存 3 到 5 分钟过期能显著降低 MySQL 压力。源码里还有一个很细致的点服务者在线状态不落库直接用 Redis hash 保存服务者下线就删字段。这个做法在部署时需要注意——如果 Redis 挂了在线状态会全部丢失所以 Redis 配置要单独做持久化。3. 从源码到可访问本地部署和正式上线的完整步骤部署这套系统不需要太多花活LNMP 一套就够。但源码里有些配置项比较隐蔽尤其是伪静态和定时任务不处理到位系统只能跑一半。下面这套步骤我在自己服务器上完整走过一遍按这个顺序操作基本能一次过。3.1 环境准备PHP 版本与扩展配置先看版本要求。这套源码在 PHP 7.4 下跑得最稳8.0 以上也能跑但个别第三方的图片处理扩展需要重新编译。MySQL 用 5.7 或 8.0 都行Redis 建议 5.0 以上Nginx 用 1.18 以上。组件版本说明PHP7.4最稳定8.0 需测试兼容性MySQL5.7推荐 8.0但 5.7 完全够用Redis5.0处理锁与缓存Nginx1.18反向代理与静态资源安装 PHP 时扩展必须装全pdo_mysql、redis、gd、bcmath、curl、openssl。bcmath特别容易漏装没有它订单金额结算会有浮点精度问题比如 9.99 会变成 9.98 或者 10.00。装完之后用命令验证扩展是否全部加载# 以 Ubuntu 20.04 为例安装 PHP 7.4 及扩展 sudo apt-get install -y php7.4-fpm php7.4-mysql php7.4-redis php7.4-gd php7.4-bcmath php7.4-curl # 验证扩展是否全部加载 php -m | grep -E redis|pdo_mysql|gd|bcmath|curlphp -m是 PHP 的扩展列表命令grep 加上扩展名可以快速确认哪些扩展缺失。现实中我遇到过不少情况Redis 扩展装了但 PHP-FPM 没重启导致扩展不生效列表里能看到但业务代码一调用 Redis 就报 Class not found。所以装完扩展后第一步是php -m确认第二步是systemctl restart php7.4-fpm。3.2 导入数据库与配置文件修改源码包的目录结构不算复杂核心是app业务代码、config配置文件、publicWeb 入口、databaseSQL 脚本、runtime日志与缓存。部署时先解压再导入数据库。unzip social_system_bundle.zip -d /data/wwwroot/ cd /data/wwwroot/social mysql -uroot -p CREATE DATABASE social DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE social; SOURCE install.sql;导入 SQL 之后马上要改配置文件。这套源码的配置集中在config/database.php和config/cache.php两个文件里。不用去一个个翻代码找常量所有数据库连接参数都在这个文件里改。?php // config/database.php return [ type mysql, hostname 127.0.0.1, database social, username social_user, password 改成你的安全密码, hostport 3306, charset utf8mb4, prefix fw_, ];prefix是表前缀默认是fw_如果导入 SQL 时表前缀已经是这个就不用动。数据库用户名和密码如果直接用 root建议在 MySQL 里创建一个独立账号只授权social库的权限这样即使源码有 SQL 注入漏洞影响范围也只在单库内。3.3 Nginx 伪静态与定时任务配置Nginx 配置是部署里最关键的一步也是后面最容易翻车的地方。源码的入口在public目录并且用了 pathinfo 风格的路由必须在 Nginx 里配好 rewrite 规则否则首页能打开点进任何详情页都是 404。server { listen 80; server_name yourdomain.com; root /data/wwwroot/social/public; index index.php index.html; location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; } } location ~ \.php$ { fastcgi_pass unix:/run/php/php7.4-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } location ~ /\.(?!well-known).* { deny all; } }这段配置里三个location各负责一件事第一个把不存在的文件路径 rewrite 到index.php这是伪静态的核心第二个把 PHP 请求转发给 PHP-FPM注意 sock 路径要和你的 PHP-FPM 进程一致第三个拦截隐藏文件防止用户直接访问.env这类敏感配置。定时任务也要在部署时就配好否则订单超时取消、服务结束后自动确认这些功能都不会触发。源码里定时任务通过think命令行入口调用crontab -e # 追加下面两行 */1 * * * * /usr/bin/php /data/wwwroot/social/think cron:cancelExpireOrder /var/log/social_cron.log 21 0 3 * * * /usr/bin/php /data/wwwroot/social/think cron:refreshCircleHot /var/log/social_cron.log 21第一行每分钟执行一次取消超过 30 分钟未支付的订单第二行每天凌晨 3 点重新统计圈子热度。注意这里/usr/bin/php必须是绝对路径我之前因为直接写php导致定时任务跑不起来后面第 5 章会细说。3.4 上线前用 curl 验证整条链路服务配置完之后我建议不要直接上业务先跑一轮验证。这轮验证能筛出大部分部署问题比上线后再排查高效得多。# 验证前端页面能否访问 curl -I https://yourdomain.com # 验证后端接口是否正常响应 curl -X POST https://yourdomain.com/api/order/preview \ -H Content-Type: application/json \ -d {service_user_id:2,service_type:1,hours:2} # 确认 PHP-FPM 和 Redis 都在工作 php -m | grep redis systemctl status php7.4-fpm确认页面能打开、接口能返回 JSON再进后台把初始管理员密码改掉这套系统才算真正完成部署。初始后台地址是/admin这一点在源码的 README 文件里写得很清楚。4. 点单与支付链路订单状态机与回调处理的代码逻辑部署完成只是开始真正理解这套系统的价值要看订单从创建到结算的完整代码链路。这一章我会按“下单防重 → 支付回调 → 余额结算”三个环节拆核心逻辑。4.1 创建订单Redis 锁防止重复下单下单接口是整套系统的第一个入口也是并发风险最高的接口。用户在陪玩详情页点“立即下单”前端传过来服务者 ID、服务类型、时长三个参数。后端要做的事比看起来多校验服务者可接单状态、计算金额、生成订单号还要防止用户手抖重复提交。public function createOrder(int $userId, int $serviceUserId, int $serviceType, float $hours) { // 1. 校验服务者存在且可接单 $serviceUser $this-userService-findActive($serviceUserId); if (!$serviceUser || $serviceUser[status] ! 1 || $serviceUser[is_service] ! 1) { throw new BusinessException(服务者不存在或暂不可接单); } // 2. 生成订单号日期 随机数避免并发碰撞 $orderNo date(YmdHis) . mt_rand(1000, 9999) . str_pad($userId % 10000, 4, 0, STR_PAD_LEFT); // 3. 计算订单金额单价 * 时长 $price $serviceUser[price]; $amount bcmul((string)$price, (string)$hours, 2); // 4. Redis 锁防止同一用户对同一服务者 60 秒内重复下单 $lockKey order_lock: . $userId . : . $serviceUserId; $lock Redis::set($lockKey, 1, [nx, ex 60]); if (!$lock) { throw new BusinessException(您正在下单请勿重复操作); } $order new Order(); $order-order_no $orderNo; $order-user_id $userId; $order-service_user_id $serviceUserId; $order-service_type $serviceType; $order-hours $hours; $order-amount $amount; $order-status 0; try { $order-save(); return $orderNo; } catch (\Throwable $e) { Redis::del($lockKey); throw new BusinessException(下单失败请重试); } }有几个细节值得展开。bcmul比直接用*更安全因为浮点数乘法在高精度场景下会有丢失9.99 乘以 1.5 直接乘会得到 14.985000000000001bcmul能精确到两位小数。Redis 锁用的是nx只在不存在时才能设置加ex过期时间组合这是一个原子操作能保证即使两个请求同时进来也只有一个能拿到锁。下单失败时手动Redis::del($lockKey)是为了释放锁不然用户要等 60 秒才能重新下单。4.2 微信支付回调验签与幂等处理支付回调是订单状态从“待支付”变成“待接单”的唯一入口。这里最容易出问题的不是微信接口调不通而是回调处理逻辑不够健壮导致“钱付了订单没变更”。public function handleWxNotify(): string { $data file_get_contents(php://input); // 1. 验签验证回调数据确实来自微信而不是伪造请求 $result Wxpay::verifyNotify($data); if (!$result) { return FAIL; } $orderNo $result[out_trade_no]; $transactionId $result[transaction_id]; $order Order::where(order_no, $orderNo)-first(); // 2. 幂等判断只有待支付状态才允许更新 // 否则一笔订单被回调两次状态会被二次覆盖 if (!$order || $order-status ! 0) { return SUCCESS; } $order-status 1; $order-paid_at time(); $order-transaction_id $transactionId; $order-save(); // 3. 通知服务者有新订单待接单 event(new OrderPaid($order-id)); return SUCCESS; }幂等判断是关键。微信支付回调同一个通知可能会触发多次如果回调处理没有status ! 0这个判断订单状态会被反复覆盖甚至从“已完成”被打回“待接单”。回调处理完成后的返回值必须是SUCCESS这样微信才不会继续重试。返回FAIL会触发微信的自动重试机制重试间隔从 15 秒开始递增。4.3 余额托管与佣金结算平台抽成怎么实现个人开发者申请微信支付的分账功能门槛很高所以这套源码用的是“余额托管”模式来规避分账接口的限制。用户先充值到平台余额下单时把订单金额冻结服务完成后平台自动把扣除佣金后的金额转入服务者余额最后服务者申请提现管理员人工审核打款。public function completeOrder(int $orderId) { $order Order::find($orderId); if (!$order || $order-status ! 2) { return; // 只有进行中才能完成 } // 平台抽成比例可在后端配置这里是 10% $platformFee bcmul((string)$order-amount, 0.10, 2); $serviceAmount bcsub((string)$order-amount, $platformFee, 2); $lockKey settle_lock: . $orderId; if (!Redis::set($lockKey, 1, [nx, ex 10])) { return; } Db::transaction(function () use ($order, $platformFee, $serviceAmount) { // 解冻下单用户的托管金额 UserBalance::where(user_id, $order-user_id)-decrement(frozen, $order-amount); // 增加服务者余额 UserBalance::where(user_id, $order-service_user_id)-increment(balance, $serviceAmount); // 记录平台收入 PlatformIncome::create([ order_id $order-id, amount $platformFee, ]); $order-status 3; $order-save(); }); }这段代码最值得学习的是状态判断和加锁的配合。status ! 2的判断和 Redis 锁形成双保险即使两个请求同时进来也只有一个能执行到事务即使 Redis 锁失效状态判断也会拦下重复结算。decrement(frozen)和increment(balance)是两步操作必须放在同一个事务里否则会出现“用户钱扣了但服务者没收到”的中间状态。5. 部署避坑与常见问题我配置这套系统时踩过的五个坑这套源码我前后部署过三次第一次花了一下午排查问题第三次半小时就上线了。下面这五个坑是按出现频率排的基本都是部署类问题提前避开能省大量时间。5.1 访问层面的翻车404、裂图与白屏坑 1首页能打开点进圈子详情、订单详情全是 404。现象部署完成后首页和后台都能访问但任何二级页面都报 404Nginx 错误日志里全是No such file or directory。原因Nginx 没有配置伪静态规则。这套源码的路由是基于 rewrite 的.html后缀的路径实际都指向index.php入口没有 rewrite 规则Nginx 会直接去找不存在的文件。解决把 3.3 节那段location /配置加到站点配置里然后nginx -t检查语法systemctl reload nginx重载配置。验证方法是访问任意一个详情页网址能正常出内容就说明 rewrite 生效了。坑 2用户头像、圈子封面全部裂图浏览器 Network 面板里显示 404。现象功能都正常就是图片加载不出来有的显示 404有的显示 403。原因两种情况。404 是上传目录没有写权限用户上传的文件没有被真正写入403 是图片域名配置写死了本机地址或旧域名导致前端请求指向错误地址。解决先给上传目录授权chmod -R 755 /data/wwwroot/social/public/uploads再把源码配置里的域名替换成实际域名。这个域名配置在config/app.php里替换后需要清理一下缓存不然老域名还会被读出来。5.2 订单与支付层面的坑丢单与状态卡死坑 3微信支付成功订单状态一直停在“待支付”。现象用户在微信里付了款后台订单状态没有变化服务者也收不到新订单通知。原因三个可能。一是回调地址没配置或配错微信根本找不到回调接口二是支付配置里用了http://而微信要求https://三是本地测试时用了内网 IP微信服务器无法访问。解决把支付回调地址写成公网可访问的完整地址https://你的域名/api/pay/notify。然后在微信商户平台确认 APIv3 密钥已配置。测试环境没有公网 IP 的可以用服务器做反向代理别用内网穿透工具稳定性不够。坑 4定时任务没跑订单超时未支付不自动取消服务完成不自动结算。现象系统上线一天后发现订单积压状态停在“待支付”和“进行中”日志文件为空。原因crontab里写的是php think没有用绝对路径。cron 执行时不会加载用户的 PATH 环境变量php命令根本找不到任务实际上从来没运行过。解决先执行which php确认 PHP 的绝对路径然后修改 crontab*/1 * * * * /usr/bin/php /data/wwwroot/social/think cron:cancelExpireOrder /var/log/social_cron.log 21改完先手动执行一遍这个命令确认能正常跑再等在 crontab 里生效。5.3 性能层面的坑并发上来连接数被打满坑 5流量一起来MySQL 直接报Too many connections。现象做了一次推广投放在线人数从几十涨到几百数据库连接直接被打满全站 500。原因两个原因叠加。MySQL 默认max_connections是 151远不够用PHP-FPM 的进程数设置过高每个进程持有一个数据库连接瞬间就把连接池打爆。Redis 缓存没发挥作用导致每个请求都直查数据库。解决先调 MySQL 连接上限再到 PHP-FPM 配置文件里把pm.max_children调到一个合理值。我给这套系统的建议配置是max_connections500pm.max_children80。更根本的解决方式是把圈子列表、热度榜这类数据做 Redis 缓存3 到 5 分钟过期就够能砍掉八成数据库查询。ALTER TABLE fw_order ADD INDEX idx_status_created (status, created_at);这条索引是我在排查“超时订单查询慢”时补的原本只有status单列索引加上created_at组成联合索引后超时订单扫描行数从几万降到几百效果非常明显。6. 进阶把默认配置调高一倍性能的三件事部署稳定之后如果想把这套系统跑得更快、支撑更高的并发不用改代码三件事就能见效。第一件是打开 PHP Opcache。PHP 是解释执行的语言每个请求都要把源码编译成字节码Opcache 把这一步缓存下来。在php.ini里配置opcache.enable1和opcache.memory_consumption128我实测过接口响应时间能从 150ms 降到 80ms 左右。配置完重启 PHP-FPM再用php -i | grep opcache验证是否生效。第二件是把热点数据落到 Redis 缓存。源码里圈子列表和热度榜本来就有缓存逻辑但默认缓存时间是 0等于没开。在后台配置里把圈子列表缓存设为 300 秒、热度榜设为 600 秒压力立减。这一条对后续接推广流量特别重要上线前一定先确认缓存配置已打开。第三件是用 ab 工具做一次压测把性能基线跑出来。部署全部完成后我不会直接宣布“上线完成”而是先压一轮ab -n 1000 -c 50 https://yourdomain.com/api/circle/hot-n 1000表示总共发送 1000 个请求-c 50表示 50 个并发。重点看两个指标Failed requests必须是 0Requests per second要大于 50。如果失败率很高优先看是不是 Redis 没开持久化导致缓存雪崩如果吞吐量太低检查 Nginx worker 进程数和对 PHP-FPM 的 socket 连接方式。这三件事做完系统性能基本翻倍。我第一次部署这套源码时没有做这些优化结果活动上线第二天数据库连接就被打满了。从那以后我每次发布前都强制自己走一遍先看伪静态再看 Redis 扩展再看定时任务最后跑一次 ab 压测。这套流程走完系统基本就稳了。希望帮到你。本文还有配套的精品资源点击获取