简介一套基于PHP的二维码防重防错系统面向需要按日生成二维码并跟踪扫码行为的中小型业务场景适合PHP开发者或运维人员直接部署使用。系统首页提供扫码入口支持生成每日二维码、批量打印、统计当日数量与扫码次数并可通过后台设置二维码前缀、默认日打印量、是否附带年月日序号及序号位数安装后需先配置基础数据再生成二维码。整体资源以ZIP压缩包形式发布大小约5.24MB便于快速下载部署。目前已有232人学习参考。对需要落地二维码防重、防错与追溯机制的团队而言这套系统提供了完整的功能闭环可作为二次开发和流程改造的基础模板也能帮助理解PHP二维码生成、打印联动和数据统计的实现思路。1. 二维码防重防错核心是后台状态机不是扫码那一下二维码本身不区分“用过”和“没用过”它只是一堆黑白格子。真正让一个码只能核销一次、且不能被改头换面后冒充的是服务端的状态机加签名校验。PHP 做这类系统其实很合适核销本质是一个 Web 请求读库、校验、更新状态LAMP/LEMP 这套链路开发效率高也不需要复杂的异步中间件。这个系统典型落在活动券码、提货凭证、签到凭据等“一码一用”业务上。设计上记住一句话二维码里存的东西越少越好防重靠数据库唯一约束防错靠签名校验。下面从设计开始一步步拆到能复现的 PHP 代码和坑。2. 防重防错设计码值怎么选、签名怎么算、状态怎么流转2.1 防重靠唯一约束防错靠签名校验先说结论二维码能防错只是在“内容不可篡改”上有意义防重必须依赖服务端一次性状态标记。防错的本质是“这个码是系统签发的不是外部随手编的”。很多系统直接在二维码里放http://域名?id1order1000这种内容用户顺手改个 ID 就能尝试越权或者复制别人的码。所以码值必须带签名服务端先验签名再响应。防重的本质是“同一个码只能从初始状态成功流转到已用状态一次”。不管二维码被印了多少张、被截图分享多少次后台只要保证状态转移是原子的重复操作就会失败。这里有三条线要同时做码值层生成不可预测的随机短串配上签名数据层表结构里码值唯一、状态明确接口层核销接口用带条件的 UPDATE 完成原子转移。只做码值随机不做签名码值可以被任意构造只做签名不建唯一索引并发下同一个码可能两次成功。三条线少一条都有坑。2.2 二维码内容选型12位随机码8位签名别堆业务ID二维码内容越短越好。QR 码容量有限内容越长纠错后的图形越密集打印在纸上越难扫。我一般把二维码内容设计成下面这种格式B23X-7QK9-MD32-48FA大写字母和数字混排去掉容易混淆的字符0/O、1/I、2/Z 这类。为什么不用 UUID36 个字符太长图案太密而且 UUID 本身没有防伪造能力。也不用订单号、自增 ID因为可预测别人能枚举。业务类型、业务关联 ID 都放到数据库映射表里不进二维码。签名怎么算取随机码本身加上一个只保存在服务端的密钥用 HMAC-SHA256 计算取前 4 字节转成 8 位十六进制作为签名。把随机码和签名用短横线拼在一起就是二维码内容。为什么是 8 位32 位随机码空间足够8 位十六进制签名是 32-bit暴力伪造需要约 40 亿次尝试对单码核销场景安全度够了同时二维码总长度控制在 21 个字符以内打印识别都很稳。签名不能用普通 MD5。MD5 没有密钥概念任何人拿到码值和签名都能碰撞重组HMAC 带密钥不知道密钥就算不出合法签名。这个密钥在 PHP 环境变量里配置不要写进前端代码也不要出现在二维码里。前端拿到的只是一段字符串由它去生成二维码图片签名逻辑完全留在服务端。2.3 数据表设计一张表、一个唯一索引、四个状态数据库设计直接决定防重是否可靠。下面是长期验证过的表结构CREATE TABLE qr_token ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, code VARCHAR(20) NOT NULL COMMENT 随机码值不含签名, sign VARCHAR(8) NOT NULL COMMENT 签名核销时校验, biz_type VARCHAR(32) NOT NULL DEFAULT COMMENT 业务类型如活动券/提货码, biz_ref VARCHAR(64) NOT NULL DEFAULT COMMENT 业务关联ID如订单号, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未使用 1已使用 2过期 3禁用, expire_at INT UNSIGNED NOT NULL DEFAULT 0 COMMENT 过期时间戳, created_at INT UNSIGNED NOT NULL, used_at INT UNSIGNED NOT NULL DEFAULT 0 COMMENT 核销时间戳, UNIQUE KEY uniq_code (code), KEY idx_biz_status (biz_type, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;几个关键点code加唯一索引这是防重的最底层保障如果两次插入同一codeMySQL 会直接拒绝sign字段保存签名核销接口先比对这个字段防止传输中被替换status是状态机核心0/1/2/3 分别代表未使用、已使用、过期、禁用expire_at用 INT 存 UNIX 时间戳不要用datetime后面避坑会细说。状态流转只有两条合法路径未使用 - 已使用正常核销未使用 - 过期定时任务或原子判断已使用状态不可回退不可再次核销。禁用状态一般用于风控手工置入。核销时不是先查状态再更新而是直接用一条带 WHERE 条件的 UPDATE 完成转移UPDATE qr_token SET status 1, used_at :now WHERE code :code AND status 0 AND expire_at :now影响行数为 1 才是核销成功为 0 说明码不存在、已用或已过期。这种写法把“检查状态”和“更新状态”合并成一个原子操作后面给出完整 PHP 实现。3. 用 PHP 实现核心链路生成码、验签、核销3.1 生成带签名的码值random_bytes HMAC生成码值用 PHP 7 系列开始推荐的安全随机源random_bytes()别再用rand()或mt_rand()。下面的函数会生成一段 12 位随机码再拼接 8 位签名?php /** * 生成二维码码值含签名 * param string $key 服务端签名密钥 * return string 完整码串如 B23X-7QK9-MD32-48FA */ function generateQrCode(string $key): string { // 1. 生成10字节安全随机数转成20位十六进制 $bytes random_bytes(10); $hex bin2hex($bytes); // 2. 用32进制字符集映射成12位短码避免易混淆字符 $alphabet ABCDEFGHJKLMNPQRSTUVWXYZ23456789; $code ; for ($i 0; $i 12; $i) { $idx hexdec(substr($hex, $i * 2, 2)) % 32; $code . $alphabet[$idx]; } // 3. HMAC-SHA256 签名取前4字节转8位十六进制 $sign substr(hash_hmac(sha256, $code, $key), 0, 8); // 4. 拼接成最终二维码内容 return $code . - . $sign; }参数说明$key只存在服务端用来计算签名不要出现在任何前端资源里字符集去掉 0/O/1/I因为打印后易混淆用户手输也容易错签名取 8 位二维码总长度 21 个字符适合二维码库生成图片random_bytes是安全随机源生成的码值不可预测别人无法枚举。拿到码串后用 PHP 的 GD 库或第三方二维码库生成图片。定义输出时设置纠错等级 L 即可因为只有 21 个字符图形很稀疏。如果打印在包装袋这类褶皱材质上建议升到 M每增加一个纠错等级识别稳定性和容错率都会好一点。3.2 生成二维码图片最小可落地的 PHP 输出这里用一个最小示例用 GD 库把码串渲染成 PNG?php // 引入二维码生成库后假设库支持 writeString 方法 $qrCode (new \YourQrCodeLibrary($rawCode)) -setSize(300) -setMargin(10) -setErrorCorrectionLevel(L); header(Content-Type: image/png); echo $qrCode-writeString();在真实项目里我一般把这步做成一个接口/qr/{code}返回图片流。前端img src/qr/?php echo $code; ?直接引用。注意$rawCode里已经包含了签名前端不要拆开处理整串作为图片内容即可。3.3 核销接口一条 UPDATE 完成防重防错核销接口是核心必须是“幂等且原子”的。完整逻辑?php /** * 核销二维码 * param string $rawCode 扫码拿到的完整码串 * param PDO $pdo 数据库连接主库 * param string $key 签名密钥 * return array [okbool, msgstring] */ function verifyAndUse(string $rawCode, PDO $pdo, string $key): array { // 1. 分割随机码和签名 $parts explode(-, $rawCode); if (count($parts) ! 2) { return [ok false, msg 二维码格式错误]; } [$code, $sign] $parts; // 2. 先验签名比对数据库里的sign或用密钥重算 $stmt $pdo-prepare(SELECT code, sign, status, expire_at FROM qr_token WHERE code ?); $stmt-execute([$code]); $row $stmt-fetch(PDO::FETCH_ASSOC); if (!$row) { return [ok false, msg 码不存在]; } if (!hash_equals($row[sign], $sign)) { return [ok false, msg 签名不匹配]; } // 3. 原子状态转移带条件UPDATE $stmt $pdo-prepare( UPDATE qr_token SET status 1, used_at :now WHERE code :code AND status 0 AND expire_at :now ); $stmt-execute([ :code $code, :now time(), ]); if ($stmt-rowCount() 1) { return [ok true, msg 核销成功]; } // 4. 影响行数为0时再查状态给用户一个明确原因 $stmt $pdo-prepare(SELECT status, expire_at FROM qr_token WHERE code ?); $stmt-execute([$code]); $row $stmt-fetch(PDO::FETCH_ASSOC); if ($row[status] 1) { return [ok false, msg 该码已使用]; } if ($row[expire_at] time()) { return [ok false, msg 该码已过期]; } return [ok false, msg 当前状态不可核销]; }逻辑说明签名比对用hash_equals()防止时间差攻击不要用UPDATE 的 WHERE 条件同时带status 0和expire_at :now两个条件缺一都会出问题先 UPDATE 后查状态是为了避免“先查后改”在并发下的竞态不管客户端怎么重复提交最终只有一次 UPDATE 能影响到一行天然去重。3.4 过期与禁用定时任务只优化展示不承担防重核销接口的 WHERE 条件里已经带expire_at now所以过期的码在核销时一定会失败。但为了管理后台能直接显示“已过期”可以加一个低频批量任务# crontab 每分钟执行一次 * * * * * /usr/bin/php /path/to/bin/expireChecker.phpUPDATE qr_token SET status 2 WHERE status 0 AND expire_at UNIX_TIMESTAMP()这个任务只是为了展示准确不是防重的组成部分。即使它晚跑几分钟核销接口依然会因为expire_at :now失败所以不需要高精度。4. 高并发防重Redis 锁配合数据库唯一约束4.1 并发场景下哪些防护是多余的、哪些是真必要的业务上线初期流量低一条带条件的 UPDATE 就够。但一旦遇到秒杀、大促核销同一个码可能在几十毫秒内被多个入口同时请求比如门店 POS 机、小程序、后台管理端同时扫同一个二维码。先理清一个事实数据库的 UPDATE 本身有行锁并发执行时 MySQL 会让它们排队最终只有一个 UPDATE 满足影响行数为 1其余为 0。所以“防重”这事数据库天然能做到。真正容易翻车的点在于业务代码在 UPDATE 之前做了耗时操作——查库存、验积分、调外部接口——这些操作不在数据库事务里等它们跑完再执行 UPDATE 时状态早就变了或者产生重复的前置校验结果。所以高并发下要控制的是“核销前后置逻辑的并发度”而不是去重写 UPDATE。Redis 锁用来锁住前置校验过程数据库 UPDATE 用来锁住最终状态。4.2 Redis 分布式锁的正确姿势如果在核销前需要查询会员积分、核对订单状态这类较重的操作可以在 UPDATE 之前加一把锁?php $redis new Redis(); $lockKey qr:lock: . $code; $lockToken bin2hex(random_bytes(8)); // NX键不存在才设置EX 1010秒自动过期 $locked $redis-set($lockKey, $lockToken, [NX, EX 10]); if (!$locked) { return [ok false, msg 操作过于频繁请稍后重试]; } try { // 前置校验、业务数据查询 // 然后执行上一章的 UPDATE 核销 } finally { // 释放锁用Lua脚本保证原子性防止误删别人的锁 $script LUA if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end LUA; $redis-eval($script, [$lockKey, $lockToken], 1); }参数说明NX保证只有第一次请求能拿到锁后面的请求直接返回“请稍后重试”EX 10锁 10 秒自动过期避免进程崩溃导致锁永久占用释放锁用 Lua 脚本比对 token 再删除防止当前请求超时后锁自动过期被另一个请求拿到然后当前请求反而删了别人的锁。这里必须说清楚Redis 锁不能替代数据库的原子 UPDATE。锁只解决了“前置校验并发重复”的问题最终防重仍然以 UPDATE 影响行数为准。如果 UPDATE 成功再补一条消费消息如果 UPDATE 失败直接返回原因不触发后续动作。4.3 幂等表与唯一索引的兜底方案有些团队习惯把核销记录独立存一张流水表再用流水表的唯一索引做兜底。这也可以但必须把“更新码状态”和“插入流水”放在同一个事务里?php $pdo-beginTransaction(); try { $stmt $pdo-prepare( UPDATE qr_token SET status1, used_at? WHERE code? AND status0 AND expire_at ? ); $stmt-execute([time(), $code, time()]); if ($stmt-rowCount() ! 1) { $pdo-rollBack(); return [ok false, msg 核销失败]; } // 流水表code字段有唯一索引重复插入会抛异常事务回滚 $pdo-prepare(INSERT INTO qr_use_log (code, used_at, operator) VALUES (?,?,?)) -execute([$code, time(), $operator]); $pdo-commit(); return [ok true, msg 核销成功]; } catch (Exception $e) { $pdo-rollBack(); return [ok false, msg 系统繁忙请重试]; }qr_use_log的code字段设唯一索引这样即使两个进程都走到了 INSERT也只有一个能成功。这种方案适合需要完整审计的场景但要注意事务里不要做远程调用整个事务要短否则行锁会拖累其他码的核销。5. 避坑指南二维码防重防错最常见的5个踩坑记录5.1 现象扫码显示核销成功但数据库查不到记录原因框架里开了事务UPDATE 之后没 commit 就返回了或者读写分离配置下SELECT 走了从库UPDATE 走了主库返回时数据还没同步。解决确认返回前执行$pdo-commit()。核销接口必须强制使用主库连接。排查时打开 MySQL 慢查询日志看 UPDATE 是否真的执行有没有被事务回滚掉。5.2 现象同一码并发下核销成功两次原因代码里先 SELECT 判断status0再执行 UPDATE。两个请求都读到 0然后都去更新后更新的覆盖了前一个的used_at但状态还是变成 1业务上看起来像两次成功。解决把 SELECT 和 UPDATE 合并成带条件的 UPDATE以影响行数为准。不要保留“先读状态再改状态”的旧写法。如果实在要保留前置查询用SELECT ... FOR UPDATE锁行但锁必须在事务结束前释放否则死锁风险很高。5.3 现象二维码偶尔提示签名不匹配原因二维码内容里的字符集与服务端生成时不一致。比如前端把字符转成了小写或者扫码时带入了空格、换行也可能是部署了多个 PHP 节点签名密钥没有统一。解决扫码入口统一trim和strtoupper。签名密钥只放在环境变量中所有节点读取同一份配置。生成二维码时可以直接输出 Data URI 或图片流避免前端二次处理字符串。5.4 现象打印出来的二维码扫不出来原因二维码内容过长或者纠错等级过低又或者印刷分辨率不够。有人把订单号、用户 ID、渠道标识全部塞进去码值几十个字符喷墨打印后马赛克化扫码工具直接失败。解决码内容控制在 21 个字符以内按“12 位随机码8 位签名”足够。打印前用手机扫码工具实际扫一次如果识别慢把纠错等级从 L 升到 M图形会密一点但识别稳定性提升明显。5.5 现象同一个批次的码有的刚过零点就显示已过期有的还能用原因数据库用datetime字段存过期时间PHP 端用date(Y-m-d H:i:s)拼进去比较两边时区不一致导致临界点判断错位。解决统一定义过期为 INT 字段存 UNIX 时间戳PHP 读出来直接time()比较。expire_at INT UNSIGNED不经过时区转换永远不会因为夏令时或时区配置引起边界错误。6. 进阶技巧把防重验证做到位比多写十行代码更有效每次改完核销接口我不会只拿接口工具发一次请求了事。我会写一个并发脚本模拟同一个码在 50 个并发下同时请求核销然后看成功次数。成功次数只能等于 1大于 1 说明防重有漏洞等于 0 则说明接口本身就错了。for i in $(seq 1 50); do curl -s http://api.example.com/consume \ -d codeB23X-7QK9-MD32-48FA done wait脚本跑完去数据库查SELECT COUNT(*) FROM qr_token WHERE codeB23X-7QK9-MD32-48FA AND status1;结果必须是 1。如果那里不是 1就只查状态更新链路别去查二维码图片库的渲染问题。另外一个我坚持的习惯给核销接口增加一个trace_id日志字段从请求入口到 UPDATE 结束把code、sign、影响行数、当前状态都打出来。用户说“扫了但提示已使用”时看日志比看用户截图高效得多。日志量不大时直接写文件量大了再接集中式日志。系统的复杂度要和流量匹配。并发长期只有每秒几十次时一个原子 UPDATE 加唯一索引就足够了Redis 锁和消息队列先不要急着上。我见过低流量团队给核销接口强加分布式锁结果锁超时时间没调好高峰期反而把服务拖垮。先跑通最小闭环再按真实流量补防护这个顺序值得守住。希望帮到你。本文还有配套的精品资源点击获取
简介一套基于PHP的二维码防重防错系统面向需要按日生成二维码并跟踪扫码行为的中小型业务场景适合PHP开发者或运维人员直接部署使用。系统首页提供扫码入口支持生成每日二维码、批量打印、统计当日数量与扫码次数并可通过后台设置二维码前缀、默认日打印量、是否附带年月日序号及序号位数安装后需先配置基础数据再生成二维码。整体资源以ZIP压缩包形式发布大小约5.24MB便于快速下载部署。目前已有232人学习参考。对需要落地二维码防重、防错与追溯机制的团队而言这套系统提供了完整的功能闭环可作为二次开发和流程改造的基础模板也能帮助理解PHP二维码生成、打印联动和数据统计的实现思路。1. 二维码防重防错核心是后台状态机不是扫码那一下二维码本身不区分“用过”和“没用过”它只是一堆黑白格子。真正让一个码只能核销一次、且不能被改头换面后冒充的是服务端的状态机加签名校验。PHP 做这类系统其实很合适核销本质是一个 Web 请求读库、校验、更新状态LAMP/LEMP 这套链路开发效率高也不需要复杂的异步中间件。这个系统典型落在活动券码、提货凭证、签到凭据等“一码一用”业务上。设计上记住一句话二维码里存的东西越少越好防重靠数据库唯一约束防错靠签名校验。下面从设计开始一步步拆到能复现的 PHP 代码和坑。2. 防重防错设计码值怎么选、签名怎么算、状态怎么流转2.1 防重靠唯一约束防错靠签名校验先说结论二维码能防错只是在“内容不可篡改”上有意义防重必须依赖服务端一次性状态标记。防错的本质是“这个码是系统签发的不是外部随手编的”。很多系统直接在二维码里放http://域名?id1order1000这种内容用户顺手改个 ID 就能尝试越权或者复制别人的码。所以码值必须带签名服务端先验签名再响应。防重的本质是“同一个码只能从初始状态成功流转到已用状态一次”。不管二维码被印了多少张、被截图分享多少次后台只要保证状态转移是原子的重复操作就会失败。这里有三条线要同时做码值层生成不可预测的随机短串配上签名数据层表结构里码值唯一、状态明确接口层核销接口用带条件的 UPDATE 完成原子转移。只做码值随机不做签名码值可以被任意构造只做签名不建唯一索引并发下同一个码可能两次成功。三条线少一条都有坑。2.2 二维码内容选型12位随机码8位签名别堆业务ID二维码内容越短越好。QR 码容量有限内容越长纠错后的图形越密集打印在纸上越难扫。我一般把二维码内容设计成下面这种格式B23X-7QK9-MD32-48FA大写字母和数字混排去掉容易混淆的字符0/O、1/I、2/Z 这类。为什么不用 UUID36 个字符太长图案太密而且 UUID 本身没有防伪造能力。也不用订单号、自增 ID因为可预测别人能枚举。业务类型、业务关联 ID 都放到数据库映射表里不进二维码。签名怎么算取随机码本身加上一个只保存在服务端的密钥用 HMAC-SHA256 计算取前 4 字节转成 8 位十六进制作为签名。把随机码和签名用短横线拼在一起就是二维码内容。为什么是 8 位32 位随机码空间足够8 位十六进制签名是 32-bit暴力伪造需要约 40 亿次尝试对单码核销场景安全度够了同时二维码总长度控制在 21 个字符以内打印识别都很稳。签名不能用普通 MD5。MD5 没有密钥概念任何人拿到码值和签名都能碰撞重组HMAC 带密钥不知道密钥就算不出合法签名。这个密钥在 PHP 环境变量里配置不要写进前端代码也不要出现在二维码里。前端拿到的只是一段字符串由它去生成二维码图片签名逻辑完全留在服务端。2.3 数据表设计一张表、一个唯一索引、四个状态数据库设计直接决定防重是否可靠。下面是长期验证过的表结构CREATE TABLE qr_token ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, code VARCHAR(20) NOT NULL COMMENT 随机码值不含签名, sign VARCHAR(8) NOT NULL COMMENT 签名核销时校验, biz_type VARCHAR(32) NOT NULL DEFAULT COMMENT 业务类型如活动券/提货码, biz_ref VARCHAR(64) NOT NULL DEFAULT COMMENT 业务关联ID如订单号, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未使用 1已使用 2过期 3禁用, expire_at INT UNSIGNED NOT NULL DEFAULT 0 COMMENT 过期时间戳, created_at INT UNSIGNED NOT NULL, used_at INT UNSIGNED NOT NULL DEFAULT 0 COMMENT 核销时间戳, UNIQUE KEY uniq_code (code), KEY idx_biz_status (biz_type, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;几个关键点code加唯一索引这是防重的最底层保障如果两次插入同一codeMySQL 会直接拒绝sign字段保存签名核销接口先比对这个字段防止传输中被替换status是状态机核心0/1/2/3 分别代表未使用、已使用、过期、禁用expire_at用 INT 存 UNIX 时间戳不要用datetime后面避坑会细说。状态流转只有两条合法路径未使用 - 已使用正常核销未使用 - 过期定时任务或原子判断已使用状态不可回退不可再次核销。禁用状态一般用于风控手工置入。核销时不是先查状态再更新而是直接用一条带 WHERE 条件的 UPDATE 完成转移UPDATE qr_token SET status 1, used_at :now WHERE code :code AND status 0 AND expire_at :now影响行数为 1 才是核销成功为 0 说明码不存在、已用或已过期。这种写法把“检查状态”和“更新状态”合并成一个原子操作后面给出完整 PHP 实现。3. 用 PHP 实现核心链路生成码、验签、核销3.1 生成带签名的码值random_bytes HMAC生成码值用 PHP 7 系列开始推荐的安全随机源random_bytes()别再用rand()或mt_rand()。下面的函数会生成一段 12 位随机码再拼接 8 位签名?php /** * 生成二维码码值含签名 * param string $key 服务端签名密钥 * return string 完整码串如 B23X-7QK9-MD32-48FA */ function generateQrCode(string $key): string { // 1. 生成10字节安全随机数转成20位十六进制 $bytes random_bytes(10); $hex bin2hex($bytes); // 2. 用32进制字符集映射成12位短码避免易混淆字符 $alphabet ABCDEFGHJKLMNPQRSTUVWXYZ23456789; $code ; for ($i 0; $i 12; $i) { $idx hexdec(substr($hex, $i * 2, 2)) % 32; $code . $alphabet[$idx]; } // 3. HMAC-SHA256 签名取前4字节转8位十六进制 $sign substr(hash_hmac(sha256, $code, $key), 0, 8); // 4. 拼接成最终二维码内容 return $code . - . $sign; }参数说明$key只存在服务端用来计算签名不要出现在任何前端资源里字符集去掉 0/O/1/I因为打印后易混淆用户手输也容易错签名取 8 位二维码总长度 21 个字符适合二维码库生成图片random_bytes是安全随机源生成的码值不可预测别人无法枚举。拿到码串后用 PHP 的 GD 库或第三方二维码库生成图片。定义输出时设置纠错等级 L 即可因为只有 21 个字符图形很稀疏。如果打印在包装袋这类褶皱材质上建议升到 M每增加一个纠错等级识别稳定性和容错率都会好一点。3.2 生成二维码图片最小可落地的 PHP 输出这里用一个最小示例用 GD 库把码串渲染成 PNG?php // 引入二维码生成库后假设库支持 writeString 方法 $qrCode (new \YourQrCodeLibrary($rawCode)) -setSize(300) -setMargin(10) -setErrorCorrectionLevel(L); header(Content-Type: image/png); echo $qrCode-writeString();在真实项目里我一般把这步做成一个接口/qr/{code}返回图片流。前端img src/qr/?php echo $code; ?直接引用。注意$rawCode里已经包含了签名前端不要拆开处理整串作为图片内容即可。3.3 核销接口一条 UPDATE 完成防重防错核销接口是核心必须是“幂等且原子”的。完整逻辑?php /** * 核销二维码 * param string $rawCode 扫码拿到的完整码串 * param PDO $pdo 数据库连接主库 * param string $key 签名密钥 * return array [okbool, msgstring] */ function verifyAndUse(string $rawCode, PDO $pdo, string $key): array { // 1. 分割随机码和签名 $parts explode(-, $rawCode); if (count($parts) ! 2) { return [ok false, msg 二维码格式错误]; } [$code, $sign] $parts; // 2. 先验签名比对数据库里的sign或用密钥重算 $stmt $pdo-prepare(SELECT code, sign, status, expire_at FROM qr_token WHERE code ?); $stmt-execute([$code]); $row $stmt-fetch(PDO::FETCH_ASSOC); if (!$row) { return [ok false, msg 码不存在]; } if (!hash_equals($row[sign], $sign)) { return [ok false, msg 签名不匹配]; } // 3. 原子状态转移带条件UPDATE $stmt $pdo-prepare( UPDATE qr_token SET status 1, used_at :now WHERE code :code AND status 0 AND expire_at :now ); $stmt-execute([ :code $code, :now time(), ]); if ($stmt-rowCount() 1) { return [ok true, msg 核销成功]; } // 4. 影响行数为0时再查状态给用户一个明确原因 $stmt $pdo-prepare(SELECT status, expire_at FROM qr_token WHERE code ?); $stmt-execute([$code]); $row $stmt-fetch(PDO::FETCH_ASSOC); if ($row[status] 1) { return [ok false, msg 该码已使用]; } if ($row[expire_at] time()) { return [ok false, msg 该码已过期]; } return [ok false, msg 当前状态不可核销]; }逻辑说明签名比对用hash_equals()防止时间差攻击不要用UPDATE 的 WHERE 条件同时带status 0和expire_at :now两个条件缺一都会出问题先 UPDATE 后查状态是为了避免“先查后改”在并发下的竞态不管客户端怎么重复提交最终只有一次 UPDATE 能影响到一行天然去重。3.4 过期与禁用定时任务只优化展示不承担防重核销接口的 WHERE 条件里已经带expire_at now所以过期的码在核销时一定会失败。但为了管理后台能直接显示“已过期”可以加一个低频批量任务# crontab 每分钟执行一次 * * * * * /usr/bin/php /path/to/bin/expireChecker.phpUPDATE qr_token SET status 2 WHERE status 0 AND expire_at UNIX_TIMESTAMP()这个任务只是为了展示准确不是防重的组成部分。即使它晚跑几分钟核销接口依然会因为expire_at :now失败所以不需要高精度。4. 高并发防重Redis 锁配合数据库唯一约束4.1 并发场景下哪些防护是多余的、哪些是真必要的业务上线初期流量低一条带条件的 UPDATE 就够。但一旦遇到秒杀、大促核销同一个码可能在几十毫秒内被多个入口同时请求比如门店 POS 机、小程序、后台管理端同时扫同一个二维码。先理清一个事实数据库的 UPDATE 本身有行锁并发执行时 MySQL 会让它们排队最终只有一个 UPDATE 满足影响行数为 1其余为 0。所以“防重”这事数据库天然能做到。真正容易翻车的点在于业务代码在 UPDATE 之前做了耗时操作——查库存、验积分、调外部接口——这些操作不在数据库事务里等它们跑完再执行 UPDATE 时状态早就变了或者产生重复的前置校验结果。所以高并发下要控制的是“核销前后置逻辑的并发度”而不是去重写 UPDATE。Redis 锁用来锁住前置校验过程数据库 UPDATE 用来锁住最终状态。4.2 Redis 分布式锁的正确姿势如果在核销前需要查询会员积分、核对订单状态这类较重的操作可以在 UPDATE 之前加一把锁?php $redis new Redis(); $lockKey qr:lock: . $code; $lockToken bin2hex(random_bytes(8)); // NX键不存在才设置EX 1010秒自动过期 $locked $redis-set($lockKey, $lockToken, [NX, EX 10]); if (!$locked) { return [ok false, msg 操作过于频繁请稍后重试]; } try { // 前置校验、业务数据查询 // 然后执行上一章的 UPDATE 核销 } finally { // 释放锁用Lua脚本保证原子性防止误删别人的锁 $script LUA if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end LUA; $redis-eval($script, [$lockKey, $lockToken], 1); }参数说明NX保证只有第一次请求能拿到锁后面的请求直接返回“请稍后重试”EX 10锁 10 秒自动过期避免进程崩溃导致锁永久占用释放锁用 Lua 脚本比对 token 再删除防止当前请求超时后锁自动过期被另一个请求拿到然后当前请求反而删了别人的锁。这里必须说清楚Redis 锁不能替代数据库的原子 UPDATE。锁只解决了“前置校验并发重复”的问题最终防重仍然以 UPDATE 影响行数为准。如果 UPDATE 成功再补一条消费消息如果 UPDATE 失败直接返回原因不触发后续动作。4.3 幂等表与唯一索引的兜底方案有些团队习惯把核销记录独立存一张流水表再用流水表的唯一索引做兜底。这也可以但必须把“更新码状态”和“插入流水”放在同一个事务里?php $pdo-beginTransaction(); try { $stmt $pdo-prepare( UPDATE qr_token SET status1, used_at? WHERE code? AND status0 AND expire_at ? ); $stmt-execute([time(), $code, time()]); if ($stmt-rowCount() ! 1) { $pdo-rollBack(); return [ok false, msg 核销失败]; } // 流水表code字段有唯一索引重复插入会抛异常事务回滚 $pdo-prepare(INSERT INTO qr_use_log (code, used_at, operator) VALUES (?,?,?)) -execute([$code, time(), $operator]); $pdo-commit(); return [ok true, msg 核销成功]; } catch (Exception $e) { $pdo-rollBack(); return [ok false, msg 系统繁忙请重试]; }qr_use_log的code字段设唯一索引这样即使两个进程都走到了 INSERT也只有一个能成功。这种方案适合需要完整审计的场景但要注意事务里不要做远程调用整个事务要短否则行锁会拖累其他码的核销。5. 避坑指南二维码防重防错最常见的5个踩坑记录5.1 现象扫码显示核销成功但数据库查不到记录原因框架里开了事务UPDATE 之后没 commit 就返回了或者读写分离配置下SELECT 走了从库UPDATE 走了主库返回时数据还没同步。解决确认返回前执行$pdo-commit()。核销接口必须强制使用主库连接。排查时打开 MySQL 慢查询日志看 UPDATE 是否真的执行有没有被事务回滚掉。5.2 现象同一码并发下核销成功两次原因代码里先 SELECT 判断status0再执行 UPDATE。两个请求都读到 0然后都去更新后更新的覆盖了前一个的used_at但状态还是变成 1业务上看起来像两次成功。解决把 SELECT 和 UPDATE 合并成带条件的 UPDATE以影响行数为准。不要保留“先读状态再改状态”的旧写法。如果实在要保留前置查询用SELECT ... FOR UPDATE锁行但锁必须在事务结束前释放否则死锁风险很高。5.3 现象二维码偶尔提示签名不匹配原因二维码内容里的字符集与服务端生成时不一致。比如前端把字符转成了小写或者扫码时带入了空格、换行也可能是部署了多个 PHP 节点签名密钥没有统一。解决扫码入口统一trim和strtoupper。签名密钥只放在环境变量中所有节点读取同一份配置。生成二维码时可以直接输出 Data URI 或图片流避免前端二次处理字符串。5.4 现象打印出来的二维码扫不出来原因二维码内容过长或者纠错等级过低又或者印刷分辨率不够。有人把订单号、用户 ID、渠道标识全部塞进去码值几十个字符喷墨打印后马赛克化扫码工具直接失败。解决码内容控制在 21 个字符以内按“12 位随机码8 位签名”足够。打印前用手机扫码工具实际扫一次如果识别慢把纠错等级从 L 升到 M图形会密一点但识别稳定性提升明显。5.5 现象同一个批次的码有的刚过零点就显示已过期有的还能用原因数据库用datetime字段存过期时间PHP 端用date(Y-m-d H:i:s)拼进去比较两边时区不一致导致临界点判断错位。解决统一定义过期为 INT 字段存 UNIX 时间戳PHP 读出来直接time()比较。expire_at INT UNSIGNED不经过时区转换永远不会因为夏令时或时区配置引起边界错误。6. 进阶技巧把防重验证做到位比多写十行代码更有效每次改完核销接口我不会只拿接口工具发一次请求了事。我会写一个并发脚本模拟同一个码在 50 个并发下同时请求核销然后看成功次数。成功次数只能等于 1大于 1 说明防重有漏洞等于 0 则说明接口本身就错了。for i in $(seq 1 50); do curl -s http://api.example.com/consume \ -d codeB23X-7QK9-MD32-48FA done wait脚本跑完去数据库查SELECT COUNT(*) FROM qr_token WHERE codeB23X-7QK9-MD32-48FA AND status1;结果必须是 1。如果那里不是 1就只查状态更新链路别去查二维码图片库的渲染问题。另外一个我坚持的习惯给核销接口增加一个trace_id日志字段从请求入口到 UPDATE 结束把code、sign、影响行数、当前状态都打出来。用户说“扫了但提示已使用”时看日志比看用户截图高效得多。日志量不大时直接写文件量大了再接集中式日志。系统的复杂度要和流量匹配。并发长期只有每秒几十次时一个原子 UPDATE 加唯一索引就足够了Redis 锁和消息队列先不要急着上。我见过低流量团队给核销接口强加分布式锁结果锁超时时间没调好高峰期反而把服务拖垮。先跑通最小闭环再按真实流量补防护这个顺序值得守住。希望帮到你。本文还有配套的精品资源点击获取
