接到这个需求标题的时候我第一反应是又是一个“标题越短活越多”的典型。PHP 多闪进群 群二维码 获取 验证 进群断句拆开就是“用PHP做一套社群进群功能获取群二维码、扫码验证、验证通过后自动进群”。标题里的“多闪”我就当作某个短视频社交App的代号下面文章里统一用“闪聊App”这个模拟项目名来讲核心逻辑完全通用不管宿主产品叫什么你要做的后端能力就是这三板斧二维码生成、扫码验证、成员落库进群。这篇文章不是PPT式的流程讲解我把整个模块从需求拆解、表结构、核心PHP代码到线上排查一条线写完适合刚拿到类似需求的PHP开发、也想把社群运营工具落地的小团队参考。内容偏后端服务端实现前端只涉及一个可扫的H5验证页不会扯太多客户端的东西。1. 需求拆解先把标题翻译成人话1.1 这个需求背后到底要做什么很多同学看到“进群”两个字就以为要调IM SDK或者直接去薅现成软件的接口这其实是误区。拿闪聊App这种带群聊功能的社交产品来说“群二维码获取、验证、进群”本质上是要做一个邀请加入群的闭环服务群主或运营在后台点击“获取本群二维码”服务端返回一张二维码图片。二维码不能只是群ID的图片否则谁扫都能进、参数还能被伪造所以它需要指向一个服务端接口生成的带参地址。用户扫码后跳到H5验证页页面展示群信息用户输入手机号、图形验证码、短信验证码完成验证。服务端确认该用户有进群资格写入群成员表并通知IM系统把用户拉入群聊。这个过程不是“多闪独有”微信群、企业微信、各类短视频App的社群入口都是类似逻辑。区别只在于有的产品直接把验证逻辑前置到App客户端有的走H5中转有的验证只要点一下授权有的需要强制绑手机号。但不管形态怎么变服务端核心动作都是签发一个一次性的、可失效的二维码凭证扫码后用这个凭证去换取进群资格。1.2 参与角色与核心流程我把参与方列一下群主/运营通过管理后台或App内操作调接口获取群二维码。用户看到二维码海报或线下物料用App扫一扫或微信扫一扫。PHP服务端负责生成二维码、校验凭证、发短信验证码、落库进群。Redis缓存二维码ticket、限制验证码发送频率、实现并发下的幂等控制。MySQL存群、群成员、二维码批次记录、验证码记录。IM系统进群落库成功后由PHP服务端回调或异步通知IM进行拉人入群。完整时序我用文字描述一遍没画图但按这个顺序走不会乱运营请求POST /api/qrcode/generate参数是group_id。服务端校验运营权限生成一个随机字符串作为ticket把群ID、过期时间、剩余可扫次数等塞进Rediskey的过期时间跟二维码有效期对齐。服务端把https://您的域名/h5/join?ticketxxx生成二维码图片返回给前端展示。用户扫码手机浏览器打开这个H5地址前端先调用GET /api/qrcode/info?ticketxxx拉取群名称、群成员数、群主昵称等信息展示。用户点击“申请进群”输入手机号前端调POST /api/qrcode/sendCode发送短信验证码。用户输入验证码前端调POST /api/qrcode/verify把 ticket、phone、code 提交上来。服务端依次校验ticket存在且未过期、群状态正常、验证码正确、用户没在这个群里、群人数没满。校验全部通过后开事务把用户写入group_members表同时把ticket的使用次数used_count加一。事务提交成功后扔一条消息进队列由队列消费者去调IM系统拉人入群。用户界面立即显示“加入成功”。这个流程把“获取二维码”和“验证进群”串成了一个整体ticket是中间的令牌所有安全检查都围绕它做。1.3 拆出来的核心模块二维码生成模块选择服务端还是客户端生成、如何把ticket塞进二维码内容。ticket管理模块生成、校验、过期、防重用。验证模块短信验证码、图形验证码、频控。群成员模块入群资格判断、重复入群拦截、人数上限。补偿模块进群落库成功但IM推送失败后的重试机制。后面每一节都会落到这些模块的具体实现上。2. 整体方案设计为什么这么选2.1 二维码方案服务端生成还是客户端生成社群二维码这类需求我的建议是服务端生成不要省这个事让客户端画。原因很简单服务端生成二维码的时候你可以在同一段代码里完成ticket的签发和Redis写入是天然的事务性操作。如果让客户端根据后端返回的群ID自己画二维码那二维码内容里就必须包含明文群ID用户拿这个码去网上随便找个生成器换一个群ID就能伪造安全上完全不可控。服务端生成有两个选择直接在PHP里用二维码库输出图片比如endroid/qr-code或phpqrcode。调用第三方二维码生成API把内容传过去返回图片地址。我建议用PHP侧生成理由是不额外依赖外部服务内网环境也能稳定出图。endroid/qr-code是老牌库PHP 7.4以上用起来很顺手生成的二维码还可以设置logo、尺寸、边距对运营要印刷海报的场景很友好。二维码内容格式推荐https://example.com/h5/join?ticket9f8a7b6c5d4e3f2a1b0c这里的ticket是一段无意义的高熵随机串不在URL里暴露群ID也不暴露任何可预测的业务参数。别人即使拿到了这个码只能去请求H5页面没有ticket就拿不到群信息和进群资格。2.2 ticket与Redis缓存设计ticket是整个流程的命根子必须做到不可猜测、可过期、可计数、可作废。生成的算法我习惯这样$ticket md5(uniqid(, true) . $groupId . microtime(true) . random_int(100000, 999999));uniqid本身可能被猜到加一个random_int混进去之后强度就够用了。实际项目里我还会再加一层HMAC签名防止ticket被二次拼接篡改但那个属于进阶玩法MVP阶段先不用。Redis存储结构我用Hash而不是简单的Stringqrcode:ticket:{ticket} - { group_id: 1, creator_id: 1001, max_uses: 200, used_count: 0, expire_at: 1710000000, status: 1 }Hash的好处是校验的时候一次HGETALL把所有字段拿出来再逐步check逻辑清晰不用拆串。ticket作为key本身已经带了前缀Redis里不会跟其他业务数据混在一起。过期时间用EXPIRE命令设置跟二维码有效期的秒数保持一致。比如二维码有效期24小时就SETEX86400秒这样Redis里的数据到点自动消失查不到就等于是二维码过期不用额外写定时任务去清理。2.3 验证流程设计不能扫码就直接进群标题里的“验证”两个字很容易被人忽略但它是整个需求里最能拉开水平差距的地方。很多初版方案是用户扫码 - 调接口 - 后端查一下ticket有效 - 直接进群。这种方案上线就会被羊毛党刷爆因为二维码是公开传播的任何人拿到都能扫控制不住谁在扫。所以我加了三个递进校验ticket有效性存在、未过期、未超过最大使用次数。手机号验证用户必须填手机号并收短信验证码这一步把进群跟真实身份绑定也能拦住大部分批量小号。资格校验群是否满员、用户是否已经在群里、用户是否在黑名单。短信验证码这块自己别造轮子接靠谱的短信服务商服务端只负责生成验证码、存Redis、控制发送频率、校验用户提交的code。验证码存储用Redis Stringkey是verify:phone:{phone}:{scene}value是验证码SETEX5分钟过期。注意一个细节发送验证码接口和校验接口都要做频控。发送接口限制同一手机号60秒内只能发一次一天最多10次校验接口限制同一IP一分钟最多试5次防止暴力撞码。2.4 防刷与安全边界二维码一旦被传到外部渠道被刷是必然的防刷设计不是可有可无。每ticket限用次数max_uses字段默认200次二维码海报上印着“限量200人扫码进群”一方面给运营操作空间一方面防止一个码被全网扩散。群人数上限进群前必须查群表max_members当前人数达到上限直接拒绝。重复进群拦截group_id user_id 在群成员表建唯一索引数据库层面兜底。二维码可作废运营后台要有“作废当前二维码重新生成”的按钮一旦发现二维码被恶意传播可以立即让旧ticket失效。短信接口防轰炸图形验证码前置到短信发送环节用户先过图形验证码再触发短信。之前在真实项目里见过一个案例运营在群公告里贴了一个不限次数的进群二维码结果被竞品拿去做短信轰炸验证一晚跑了三千多条短信费用。所以防刷这块宁可多挡一步也别嫌麻烦。3. 数据库设计与接口定义3.1 四张核心表建表SQL给出一个可直接用的版本字段名我尽量通用你们根据团队规范调整前缀即可。CREATE TABLE groups ( id int unsigned NOT NULL AUTO_INCREMENT, name varchar(100) NOT NULL DEFAULT COMMENT 群名称, owner_id int unsigned NOT NULL DEFAULT 0 COMMENT 群主用户ID, max_members int unsigned NOT NULL DEFAULT 200 COMMENT 最大成员数, current_members int unsigned NOT NULL DEFAULT 0 COMMENT 当前成员数, status tinyint NOT NULL DEFAULT 1 COMMENT 1正常 0解散 2封禁, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT群表;CREATE TABLE group_members ( id bigint unsigned NOT NULL AUTO_INCREMENT, group_id int unsigned NOT NULL DEFAULT 0, user_id int unsigned NOT NULL DEFAULT 0, phone varchar(20) NOT NULL DEFAULT , role tinyint NOT NULL DEFAULT 0 COMMENT 0普通成员 1管理员 2群主, status tinyint NOT NULL DEFAULT 1 COMMENT 1正常 0退群 2被移除, joined_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, quit_at datetime DEFAULT NULL COMMENT 退群/被移除时间, PRIMARY KEY (id), UNIQUE KEY uk_group_user (group_id,user_id), KEY idx_phone (phone) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT群成员表;CREATE TABLE qrcode_records ( id bigint unsigned NOT NULL AUTO_INCREMENT, group_id int unsigned NOT NULL DEFAULT 0, ticket varchar(64) NOT NULL DEFAULT , creator_id int unsigned NOT NULL DEFAULT 0 COMMENT 创建人用户ID, expire_at datetime NOT NULL DEFAULT 1970-01-01 00:00:00, max_uses int unsigned NOT NULL DEFAULT 200, used_count int unsigned NOT NULL DEFAULT 0, status tinyint NOT NULL DEFAULT 1 COMMENT 1有效 0已作废 2已过期, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_ticket (ticket), KEY idx_group_id (group_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT群二维码记录表;CREATE TABLE verify_codes ( id bigint unsigned NOT NULL AUTO_INCREMENT, phone varchar(20) NOT NULL DEFAULT , code varchar(10) NOT NULL DEFAULT , scene varchar(30) NOT NULL DEFAULT join_group, expired_at datetime NOT NULL, used tinyint NOT NULL DEFAULT 0 COMMENT 0未用 1已用, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_phone_scene (phone,scene) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT短信验证码记录表;这几张表之间的关系很简单groups跟group_members一对多qrcode_records记录每次生成的二维码批次verify_codes只做审计留存实时校验走Redis。3.2 接口清单与参数约定接口我设计了四个全部走POST JSON只有二维码图片本身走GET。接口方法入参说明/api/qrcode/generatePOSTgroup_id, operator_id运营生成群二维码返回二维码图片base64和有效期/api/qrcode/infoPOSTticket扫码后H5页拉取群名称、群人数、群头像/api/qrcode/sendCodePOSTticket, phone, captcha先通过图片验证码再发送短信验证码/api/qrcode/verifyPOSTticket, phone, code校验验证码并进群为什么不用GET暴露info接口因为H5页是给扫码用户用的ticket会出现在URL里用GET的话CDN日志、浏览器历史、运营统计系统都会把这个ticket记下来泄露面太大。POST在一定程度上缓解日志泄露虽然防不了抓包但至少日志层面的暴露少很多。3.3 关键字段设计理由qrcode_records.expire_at二维码的绝对过期时间。Redis里的TTL是方便快速失效但数据库里必须保留一份用来做审计和运营后台展示比如“这个二维码昨天过期了扫码量是多少”。qrcode_records.max_uses单个二维码可进群的最大人数。有些运营活动只放100个名额这个字段直接限死不用靠业务代码去判断。group_members.uk_group_user唯一索引是防重复进群的最后一层保障就算业务代码有并发漏洞数据库也不会让你插入两条相同群和用户的数据。verify_codes.phone scene同一个手机号在“join_group”场景可能多次收到验证码索引这个组合方便后台查某个用户是不是频繁尝试进群。4. 核心代码实现从生成二维码到进群全流程4.1 环境准备与依赖我的演示环境是 PHP 7.4 Laravel 8 风格的路由写法但核心逻辑抽出来是纯PHP放到ThinkPHP、Hyperf 或者原生框架都能改过去。先装二维码库composer require endroid/qr-code这个库在PHP 7.4以上跑得很好输出base64图片很省事。如果用老项目不方便上Composerphpqrcode这个单文件库也是替代方案只是封装和文档差一些。Redis连接用phpredis扩展MySQL连接用PDO环境上保证这两个扩展开启就行。4.2 生成群二维码签发ticket代码里我把校验和生成写在一起public function generateQrcode(Request $request) { $groupId intval($request-input(group_id)); $operatorId intval($request-input(operator_id)); // 1. 校验操作者是否是群主或管理员 $group $this-findGroup($groupId); if (!$group || $group[owner_id] ! $operatorId) { return $this-error(无权限生成二维码); } // 2. 生成唯一ticket $ticket md5(uniqid(, true) . $groupId . random_int(100000, 999999)); // 3. 二维码有效期默认24小时 $expireSec 86400; $expireAt time() $expireSec; // 4. 写入RedisHash结构 $redisKey qrcode:ticket: . $ticket; $this-redis-hMSet($redisKey, [ group_id $groupId, creator_id $operatorId, max_uses 200, used_count 0, expire_at $expireAt, status 1, ]); $this-redis-expire($redisKey, $expireSec); // 5. 落库方便运营后台展示历史二维码 $this-insertQrcodeRecord($groupId, $ticket, $operatorId, $expireAt, 200); // 6. 生成二维码内容 $content https://example.com/h5/join?ticket . $ticket; // 7. 用endroid生成二维码并输出base64 $result \Endroid\QrCode\Builder\Builder::create() -data($content) -size(400) -margin(10) -build(); return $this-success([ qrcode_base64 $result-getDataUri(), ticket $ticket, expire_at $expireAt, ]); }这一段把“获取群二维码”这个需求完整落地了。要注意几个点注意hMSet之后必须单独调expire因为hMSet不会自动设置TTL。忘了这一步Redis里的ticket永远不会过期二维码等于永久有效极危险。max_uses我硬编码成200真正的项目应该从群表或运营后台参数读这里为了演示不额外拉参数。4.3 扫码验证进群最核心的逻辑验证进群的代码拆成两块发送短信验证码、校验并进群。发送验证码前面要加图形验证码这里简化直接用手机号做频控public function sendCode(Request $request) { $ticket $request-input(ticket); $phone $request-input(phone); // 1. 校验ticket $qrInfo $this-redis-hGetAll(qrcode:ticket: . $ticket); if (!$qrInfo || $qrInfo[status] ! 1) { return $this-error(二维码无效或已过期); } // 2. 手机号格式校验 if (!preg_match(/^1\d{10}$/, $phone)) { return $this-error(手机号格式不正确); } // 3. 60秒发送频控 $sendKey verify:sms: . $phone; $exists $this-redis-get($sendKey); if ($exists) { return $this-error(发送太频繁请稍后再试); } // 4. 生成6位验证码塞进Redis5分钟有效 $code (string) random_int(100000, 999999); $this-redis-setex(verify:phone: . $phone, 300, $code); // 5. 调用短信服务商发送这里省略具体API对接 $this-sendSms($phone, $code); // 6. 标记60秒内不能重发 $this-redis-setex($sendKey, 60, 1); return $this-success(验证码已发送); }发送验证码成功之后用户把验证码填进来走verify接口。这个接口要处理的细节最多我一步步写清楚public function verify(Request $request) { $ticket $request-input(ticket); $phone $request-input(phone); $code $request-input(code); // 1. 取ticket信息 $redisKey qrcode:ticket: . $ticket; $qrInfo $this-redis-hGetAll($redisKey); if (!$qrInfo) { return $this-error(二维码不存在或已过期); } if ($qrInfo[status] ! 1) { return $this-error(二维码已被作废); } $groupId intval($qrInfo[group_id]); // 2. 校验短信验证码 $codeKey verify:phone: . $phone; $cacheCode $this-redis-get($codeKey); if (!$cacheCode || $cacheCode ! $code) { return $this-error(验证码错误); } // 3. 群状态与人数校验 $group $this-findGroup($groupId); if (!$group || $group[status] ! 1) { return $this-error(群不存在或已解散); } if ($group[current_members] $group[max_members]) { return $this-error(群人数已满); } // 4. 判断是否已在群里 if ($this-isInGroup($groupId, $phone)) { return $this-error(您已经在群内请勿重复扫码); } // 5. 使用Redis分布式锁防并发重复进群 $lockKey lock:join: . $groupId . : . md5($phone); $lockGot $this-redis-set($lockKey, 1, [NX, EX 10]); if (!$lockGot) { return $this-error(正在处理中请勿重复提交); } try { // 6. 开启事务写成员表 更新群人数 增加二维码已用次数 $this-pdo-beginTransaction(); $this-pdo-insert(group_members, [ group_id $groupId, user_id $this-getUserIdByPhone($phone), phone $phone, role 0, status 1, ]); $this-pdo-update(groups, [ current_members $group[current_members] 1, ], id ?, [$groupId]); $this-pdo-update(qrcode_records, [ used_count $qrInfo[used_count] 1, ], ticket ?, [$ticket]); $this-pdo-commit(); // 7. 标记验证码已使用防止重放 $this-redis-del($codeKey); } catch (\Throwable $e) { $this-pdo-rollBack(); throw $e; } finally { $this-redis-del($lockKey); } // 8. 异步通知IM系统拉人进群 $this-notifyImToJoinGroup($groupId, $phone); return $this-success(加入成功); }这个实现把“验证进群”的核心全部包住了。有几个点特意说一下校验验证码之前没有删验证码而是等事务成功后再删这样事务失败用户不用再收一次短信。分布式锁的key是 群ID 手机号哈希同一用户同时点十次提交只有一次能拿到锁。DB事务包住了三个写操作成员表、群人数、二维码用量。任何一个失败都回滚不会出现“人没进群但人数加了一”的情况。4.4 群成员落库与IM推送的补偿进群写到MySQL只是业务成功用户要真正能在App里看到群、能发言还得IM系统把他拉进实时群。IM系统通常是另一个服务不能把它的失败拖到主流程里。我在主流程最后只做了一件事把消息丢进队列。public function notifyImToJoinGroup($groupId, $phone) { $payload json_encode([ group_id $groupId, phone $phone, action join, time time(), ]); // 这里用的是简单Redis队列也可以替换成RabbitMQ或NATS $this-redis-lPush(queue:im:join, $payload); }队列消费端的工作是取消息 - 调IM系统接口 - 成功则标记完成 - 失败则重试最多重试3次。三次还失败就丢到死信队列人工介入。为什么不直接在主流程里调IM接口我踩过坑某个时段IM系统负载高一个进群请求在主流程里等了3秒用户以为卡死了连点好几次结果并发一上来把整个PHP进程池打满。后来改成异步进群秒回IM再慢慢拉人体验问题全没了。5. 联调实战与常见问题排查5.1 联调环境准备二维码功能联调有个特别烦的点只要是“扫码”就必须有一台能被手机访问到的服务。本地开发用127.0.0.1生成的二维码手机根本扫不通。我常用的做法是本地起服务后用内网穿透工具把服务端口映射到一个公网临时域名然后把二维码内容里的域名改成临时域名去生成。如果公司有测试环境服务器那就直接把代码部署到测试环境省事得多。还有一个容易忽略的地方二维码内容里的域名必须带HTTPS。iOS和Android对明文HTTP的扫码跳转限制越来越严格尤其微信内置浏览器直接拦截HTTP链接。测试阶段临时域名没有HTTPS证书的话先用网盘传二维码原图到手机用App自带扫一扫打开部分App允许HTTP但H5页里的短信验证码发送接口必须也是HTTPS否则混合内容同样被拦。5.2 高频问题速查表联调阶段和上线初期的问题基本集中在这几个点上我整理成表格问题现象根本原因解决方式扫码打不开页面二维码内容用了内网IP或localhost换成公网HTTPS域名生成二维码提示二维码不存在Redis key过期或者被LRU淘汰检查ticket写入是否设置了expire用持久化策略或延长TTL提示二维码已过期运营把码发给用户时已经过了有效期生成时算好活动时间增加“重新生成二维码”入口验证码一直提示错误用户手机号填错、或验证码发到旧手机上记录日志对比Redis中的code和用户输入检查手机号脱敏展示用户重复进群成功并发请求绕过了前置判断靠数据库唯一索引和分布式锁兜底进群成功了App里看不到群IM系统拉人失败主流程未处理加队列重试重试3次后告警二维码被刷短信费用爆了没做图形验证码和频控短信发送前加图形验证码 60秒/日频控5.3 并发与性能优化要点这个功能看起来简单但并发场景一点都不简单。一个二维码被丢到大群里瞬间可能有几百人同时扫码。压测之前先想清楚瓶颈在哪Redis单点操作ticket校验、验证码校验、分布式锁都是毫秒级扛得住几千QPS。MySQL瓶颈group_members的插入、groups表的current_members更新都会行锁竞争。同一个群的并发进群锁竞争会很严重但这属于正常现象群人数上限一般200200并发的行锁冲突在可控范围。短信服务商的QPS你本地再快短信服务商每秒只能发几十条这个不是靠代码能解决的。真要应对大流量把发短信改成异步批量前端文案改成“验证码稍后送达”。我用压测工具测过一个模拟项目纯Redis校验 MySQL事务落库单机PHP能扛到300QPS左右。到了这个量级再往上就得拆分服务了二维码生成和验证进群拆成两个服务验证进群再拆出独立的入群worker。5.4 我踩过的几个坑写这类进群功能我真正踩过的、也是常规文档不会提的坑有两个让我印象特别深。第一个是Redis的过期淘汰策略。当时图省事把二维码信息存进Redis之后没显式设置TTL而是靠程序里手动EXPIRE。结果某次高峰期Redis内存不够触发了allkeys-lru淘汰活动还没结束二维码ticket就被踢了。用户在群里扫同一个码一半人成功一半人提示“二维码不存在”。排查半天才想到是Redis淘汰策略。后来我把业务数据从默认库挪到专门库并设置了noeviction二维码相关的key全部显式带TTL再没出过这事。第二个是二维码图片缓存。我最初在生成二维码时直接把图片base64返回给前端前端把图片地址存在CDN上。后来运营改了群名称重新生成二维码却发现扫码后显示的群名还是旧的。原因很简单CDN缓存了二维码图片图片内容是旧的ticket URL用户扫出来还是旧ticket旧ticket关联的群信息也没变所以页面显示旧群名。解决办法是生成新的二维码时强制刷新CDN缓存或者在二维码图片URL后面加时间戳参数绕开缓存。第三个坑是验证码校验成功后没有删除验证码。某次灰度测试用户第一次输入验证码网络抖动导致请求超时前端自动重试幸好后端事务成功前没删验证码重试请求才能继续完成。但反过来如果事务第二次执行时验证码已经被第一次删了就会再次触发“验证码错误”。这个问题的本质是要给进群接口做幂等同一ticketphone重复提交第一次成功后第二次应该直接返回“已在群内”而不是再校验验证码。我后来在代码入口加了幂等判断才算彻底根治。经验总结进群这类高频写操作先想幂等和补偿再想业务逻辑。验证码删早了、锁没拿住、事务没提交都是能靠代码补的用户被提示“正在处理中”才是最影响体验的。6. 个人实操中的几点体会收到标题里这种需求我最想提醒接手的人一句话别把“进群”理解成单纯的数据库插入。二维码、验证、进群是一条完整链路链路里每一环都可能成为攻击点。实际开发时建议分三步走第一步先把二维码生成和ticket校验跑通第二步引入短信验证码和防刷频控第三步再补IM异步推送和补偿机制。三步做完这个功能才敢说能上线面对真实用户。另外一个实用小技巧二维码的ticket和验证码的Redis key一定要带上业务前缀和场景标识比如qrcode:ticket:和verify:phone:千万别用裸key。等项目跑起来你一定会感谢这个命名习惯——排查线上问题的时候redis-cli keys扫一眼就知道数据在哪一层出了问题。
