简介这是一套面向PHP开发者与电商、品牌防伪业务团队的一物一码溯源防伪系统源码基于PHP构建可用于批量生成和管理防伪码、溯源码帮助商品实现从生产到流通的全流程追溯与防伪管理适合有一定PHP基础、需要搭建防伪溯源平台的开发者二次开发或直接部署。资源包共约2000个文件压缩后18.49MB以996个php核心业务文件为主辅以png、gif等图片素材js、css、html构成前端交互与页面json、xml、txt、md承载配置与说明文档另有ttf、woff等字体及少量sh、bat脚本目录结构完整。该版本为v2.1.0新增模块标签属性、OpenApi与Api中间件AccessGate、MySQL8.0兼容、富文本标签download属性过滤、网站地址配置项等19项特性并优化了模块市场显示样式。目前已有516人学习下载读者可获取完整可运行的防伪溯源系统源码用于研究一物一码业务逻辑、后台管理架构与接口设计快速搭建自有防伪码管理平台。1. 一物一码溯源防伪系统到底在防谁从 PHP 魔众 v2.1.0 的码池设计说起你扫一瓶酒上的二维码页面告诉你「正品第 3 次查询首次查询时间 2024-03-11 09:22」。如果这瓶酒是假的造假者大概率也印了同样的码甚至把真码抄了一万遍。一物一码溯源防伪系统要解决的核心矛盾不是「生成二维码」而是让每一个码在数据库里只对应一次真实的生产行为并且让重复查询这件事本身变成证据。PHP 魔众一物一码溯源防伪系统 v2.1.0 就是这类系统的典型实现用 PHP 做后端把码池、批次、查询日志、防伪判定串成一条链路。它适合谁做快消品、农资、化妆品、汽配的团队手里有生产线或代工厂需要一套能自己部署、能改判定规则、能对接公众号或小程序的溯源后台。不适合谁只想贴个二维码做营销跳转的这套东西的复杂度会让你后悔。下面按「码怎么造 → 怎么发 → 怎么查 → 怎么防」四段拆开讲中间会给出可复现的建表、生成、校验代码也会说清楚哪些参数一改就翻车。2. 码池、批次与身份绑定一物一码系统的数据模型怎么立住2.1 为什么不能把码直接存成一张大表很多新手第一版会建一张codes表字段id, code, product_id, status然后批量插入。码量到百万级时查询开始变慢到千万级导出和统计直接拖垮数据库。魔众这类系统通常把「码」拆成两层码池code_pool负责批量预生成码实例code_item负责绑定具体批次和产品。码池是原料码实例是成品。原料可以一次性生成几百万个随机串成品只在出库或贴标时才写入绑定关系。这样做的好处是生成码和发码解耦生产线不会因为数据库写入慢而卡住。另一个关键点是码的随机性。用md5(uniqid())生成短码看起来够随机但uniqid()基于微秒时间戳同一毫秒内并发生成会碰撞。常见做法是用random_bytes或openssl_random_pseudo_bytes取随机源再转成 Base32 或自定义字符集去掉容易混淆的 0/O、1/I。下面是一段可复现的码生成函数字符集 32 位长度 12理论空间 32^12 ≈ 1.15×10^18足够千万级码池使用。?php // 生成一物一码短码字符集去掉 0/O/1/I长度 12 function generateCode(int $length 12): string { $chars 23456789ABCDEFGHJKLMNPQRSTUVWXYZ; // 32 个字符 $max strlen($chars) - 1; $code ; for ($i 0; $i $length; $i) { // random_int 是密码学安全随机比 rand/mt_rand 可靠 $code . $chars[random_int(0, $max)]; } return $code; } // 批量生成并写入码池注意用事务和批量插入 function batchGenerate(PDO $pdo, int $count, int $batchSize 1000): int { $inserted 0; $pdo-beginTransaction(); $stmt $pdo-prepare( INSERT INTO code_pool (code, status, created_at) VALUES (?, 0, NOW()) ); for ($i 0; $i $count; $i) { $stmt-execute([generateCode()]); $inserted; if ($inserted % $batchSize 0) { $pdo-commit(); $pdo-beginTransaction(); } } $pdo-commit(); return $inserted; }逻辑说明random_int是 PHP 7 引入的密码学安全随机函数比mt_rand更适合防伪场景。批量插入时每 1000 条提交一次事务避免长事务锁表。参数说明$length控制码长度12 位在 32 字符集下已经足够$batchSize根据数据库写入能力调整MySQL 一般 500 到 2000 之间。注意code_pool表必须对code字段建唯一索引否则碰撞后无法发现。2.2 批次表与产品表的关联设计码池只是原料真正让码有业务含义的是批次。一个批次对应一次生产任务包含产品 ID、生产日期、有效期、生产线编号。码实例表code_item里存pool_id、batch_id、product_id、bind_time、status。查询时通过码实例找到批次再找到产品。这样设计后召回一个批次只需要把该批次下所有码实例标记为失效不需要动码池。建表 SQL 如下注意索引和字段类型CREATE TABLE code_pool ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, code CHAR(12) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未使用 1已绑定 2作废, created_at DATETIME NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_code (code), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE code_item ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, pool_id BIGINT UNSIGNED NOT NULL, batch_id INT UNSIGNED NOT NULL, product_id INT UNSIGNED NOT NULL, bind_time DATETIME NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 2冻结 3已查询, PRIMARY KEY (id), UNIQUE KEY uk_pool (pool_id), KEY idx_batch (batch_id), KEY idx_product (product_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;参数说明code用CHAR(12)而不是VARCHAR因为长度固定CHAR在索引和比较时更快。uk_pool唯一索引保证一个码池记录只能绑定一次防止重复发码。idx_batch和idx_product用于按批次和产品统计查询。注意如果码量超过 5000 万考虑分库分表或按批次归档单表 InnoDB 在千万级仍然可用但统计查询要加缓存。3. 从生产到出库PHP 侧批量绑定与发码的落地步骤3.1 批量绑定码实例的脚本怎么写生产线上贴标前需要把码池里的码绑定到具体批次。常见做法是后台点「生成批次码」后台异步任务从码池取未使用的码写入码实例表。这里的关键是并发控制多个任务同时取码不能取到同一条。用SELECT ... FOR UPDATE SKIP LOCKED是 MySQL 8.0 的推荐做法MySQL 5.7 则用UPDATE ... LIMIT配合状态位。?php // 从码池取 N 个未使用码并绑定到批次 function bindBatch(PDO $pdo, int $batchId, int $productId, int $need): int { $pdo-beginTransaction(); // MySQL 8.0 支持 SKIP LOCKED避免锁等待 $stmt $pdo-prepare( SELECT id, code FROM code_pool WHERE status 0 ORDER BY id ASC LIMIT ? FOR UPDATE SKIP LOCKED ); $stmt-bindValue(1, $need, PDO::PARAM_INT); $stmt-execute(); $rows $stmt-fetchAll(PDO::FETCH_ASSOC); if (count($rows) $need) { $pdo-rollBack(); throw new RuntimeException(码池余量不足); } $ids array_column($rows, id); $in implode(,, array_fill(0, count($ids), ?)); // 标记码池已使用 $pdo-prepare(UPDATE code_pool SET status 1 WHERE id IN ($in)) -execute($ids); // 写入码实例 $insert $pdo-prepare( INSERT INTO code_item (pool_id, batch_id, product_id, bind_time, status) VALUES (?, ?, ?, NOW(), 1) ); foreach ($rows as $row) { $insert-execute([$row[id], $batchId, $productId]); } $pdo-commit(); return count($rows); }逻辑说明FOR UPDATE SKIP LOCKED让并发任务跳过已被锁定的行不会互相阻塞。先锁码池行再更新状态再写码实例三步在同一事务内。参数说明$need是本次绑定数量建议按生产批次大小传入比如 5000 或 10000。注意如果码池余量不足直接回滚并抛异常不要部分绑定否则批次码数量对不上。3.2 发码接口与防重复提交出库时系统需要把码导出成 CSV 或推送到贴标机。常见做法是提供一个export接口按批次 ID 查询码实例生成文件。这里容易翻车的地方是重复导出操作员点了两次导出贴标机收到两份文件导致同一批码被重复打印。解决办法是在批次表加export_status字段导出前先检查状态导出后置为已导出。?php // 导出批次码防止重复导出 function exportBatch(PDO $pdo, int $batchId): string { $pdo-beginTransaction(); $stmt $pdo-prepare( SELECT export_status FROM batch WHERE id ? FOR UPDATE ); $stmt-execute([$batchId]); $batch $stmt-fetch(PDO::FETCH_ASSOC); if (!$batch) { $pdo-rollBack(); throw new RuntimeException(批次不存在); } if ((int)$batch[export_status] 1) { $pdo-rollBack(); throw new RuntimeException(该批次已导出禁止重复操作); } $pdo-prepare(UPDATE batch SET export_status 1 WHERE id ?) -execute([$batchId]); $pdo-commit(); // 查询码并生成 CSV $rows $pdo-prepare( SELECT cp.code FROM code_item ci JOIN code_pool cp ON cp.id ci.pool_id WHERE ci.batch_id ? ); $rows-execute([$batchId]); $lines [code]; foreach ($rows-fetchAll(PDO::FETCH_ASSOC) as $row) { $lines[] $row[code]; } return implode(\n, $lines); }逻辑说明先用FOR UPDATE锁住批次行检查export_status再更新状态最后查询码。这样即使两个请求同时进来只有一个能通过检查。参数说明export_status默认 0导出后置 1。注意如果导出文件生成失败需要把状态回滚否则批次永远无法再导出。可以在生成文件后再提交事务或者加一个「重置导出状态」的后台操作。4. 扫码查询与防伪判定一次查询背后要跑多少条 SQL4.1 查询接口的完整链路用户扫码后请求打到query接口参数是码。接口要做的事查码是否存在 → 查码是否有效 → 记录查询日志 → 返回查询次数和首次查询时间。防伪的核心逻辑是同一个码第一次查询是正常的第二次查询要提示「已被查询过」第三次以上要标记为异常。但这里有个坑如果用户自己扫了两次系统就判定为假会误伤。常见做法是设置一个「查询次数阈值」比如 3 次以内正常提示超过 3 次才标记为可疑同时记录 IP 和 User-Agent 用于人工排查。?php // 扫码查询接口核心逻辑 function queryCode(PDO $pdo, string $code, string $ip): array { $stmt $pdo-prepare( SELECT ci.id, ci.batch_id, ci.product_id, ci.status, cp.code, b.product_name, b.production_date FROM code_item ci JOIN code_pool cp ON cp.id ci.pool_id JOIN batch b ON b.id ci.batch_id WHERE cp.code ? LIMIT 1 ); $stmt-execute([$code]); $item $stmt-fetch(PDO::FETCH_ASSOC); if (!$item) { return [status fake, msg 码不存在]; } if ((int)$item[status] 2) { return [status frozen, msg 该码已被冻结]; } // 记录查询日志 $pdo-prepare( INSERT INTO query_log (code_item_id, ip, query_time) VALUES (?, ?, NOW()) )-execute([$item[id], $ip]); // 统计查询次数 $countStmt $pdo-prepare( SELECT COUNT(*) AS cnt, MIN(query_time) AS first_time FROM query_log WHERE code_item_id ? ); $countStmt-execute([$item[id]]); $log $countStmt-fetch(PDO::FETCH_ASSOC); $count (int)$log[cnt]; $result [ status $count 3 ? suspect : ok, product_name $item[product_name], production_date $item[production_date], query_count $count, first_query_time $log[first_time], ]; return $result; }逻辑说明先查码实例再查批次和产品然后写查询日志最后统计次数。参数说明$code是用户扫到的码$ip用于记录来源。注意query_log表会快速增长建议按月分表或定期归档。如果查询量很大统计次数可以用 Redis 计数器代替实时COUNT(*)。4.2 防伪判定的参数怎么调查询次数阈值不是固定的。快消品可能 3 次以内都算正常因为用户可能反复扫高价值商品可能 1 次以上就提示「已被查询」。这个参数应该放在后台可配置而不是写死在代码里。常见做法是在config表存query_threshold默认 3。另外首次查询时间要精确到秒并且不能被篡改。query_log表只允许插入不允许更新和删除从权限上保证日志可信。还有一个容易被忽略的点码的查询页面本身可能被伪造。造假者可以做一个一模一样的查询页面用户输入码后返回「正品」。防这种伪造需要在返回结果里带上只有官方系统才知道的校验字段比如用 HMAC 对「码 查询次数 时间戳」签名前端展示时校验签名。下面是一个简单的签名示例?php // 对查询结果签名防止页面伪造 function signResult(array $result, string $secret): string { $payload $result[code] . | . $result[query_count] . | . time(); return hash_hmac(sha256, $payload, $secret); }参数说明$secret是服务端密钥不能泄露。前端拿到签名后用同样的密钥校验实际项目中前端不存密钥而是由服务端校验后返回一个短时 token。注意HMAC 只能防篡改不能防钓鱼页面直接复制官方页面。真正的防伪还是要靠用户从官方入口进入。5. 避坑与排查一物一码系统上线后最容易翻车的 5 个点5.1 码池生成时碰撞但唯一索引没建现象批量生成 100 万个码插入到 80 万时突然报Duplicate entry任务中断。原因code_pool表的code字段没有唯一索引或者用了INSERT IGNORE把冲突悄悄跳过导致实际可用码少于预期。解决建表时加UNIQUE KEY uk_code (code)生成脚本捕获唯一键冲突异常重新生成该条码并重试。不要用INSERT IGNORE它会掩盖问题。5.2 并发绑定导致同一个码被绑到两个批次现象两个生产任务同时执行导出后发现有些码在批次 A 和批次 B 里都出现了。原因绑定脚本没有用事务和行锁两个任务同时SELECT到同一批未使用码。解决用FOR UPDATE SKIP LOCKED锁行或者用UPDATE code_pool SET status 1 WHERE id IN (...) AND status 0检查受影响行数如果行数不等于预期回滚重试。5.3 查询日志表膨胀查询接口变慢现象上线三个月后扫码查询从 200ms 涨到 2s。原因query_log表没有索引或者数据量到千万级后COUNT(*)全表扫描。解决给query_log的code_item_id加索引统计次数用 Redis 计数器日志表按月分表或定期归档到历史库。查询接口里不要实时COUNT(*)而是查缓存。5.4 码被批量爬取防伪系统变成「查号器」现象有人写脚本遍历短码把有效码全部查出来然后复制到假货上。原因查询接口没有频率限制短码空间虽然大但攻击者可以慢慢跑。解决查询接口加 IP 频率限制比如每分钟最多 30 次对连续查询不存在的码的 IP 加入黑名单码长度不要低于 10 位字符集不要太小。如果码量不大可以在码里加入批次校验位让攻击者无法通过简单遍历命中有效码。5.5 导出文件被重复下载贴标机重复打印现象操作员点了两次导出贴标机打印了两份相同的码导致同一码被贴到两个产品上。原因导出接口没有幂等控制。解决批次表加export_status导出前检查并锁定导出后置为已导出。如果导出失败提供「重置导出状态」的后台按钮并记录操作日志。6. 进阶用 Redis 缓存查询结果与批量导入的优化技巧查询接口是读多写少的典型场景。同一个码可能被扫很多次但码本身的信息不会变。我一般会在查询接口前面加一层 Redis 缓存key 是code:{code}value 是码实例的 JSON过期时间设 10 分钟。这样大部分查询直接命中缓存只有第一次和缓存过期后才查数据库。查询次数统计用 Redis 的INCR异步落库避免每次查询都写query_log。?php // 带 Redis 缓存的查询 function queryCodeWithCache(Redis $redis, PDO $pdo, string $code, string $ip): array { $cacheKey code: . $code; $cached $redis-get($cacheKey); if ($cached ! false) { $item json_decode($cached, true); } else { $stmt $pdo-prepare( SELECT ci.id, ci.batch_id, ci.product_id, ci.status, cp.code, b.product_name, b.production_date FROM code_item ci JOIN code_pool cp ON cp.id ci.pool_id JOIN batch b ON b.id ci.batch_id WHERE cp.code ? LIMIT 1 ); $stmt-execute([$code]); $item $stmt-fetch(PDO::FETCH_ASSOC); if ($item) { $redis-setex($cacheKey, 600, json_encode($item)); } } if (!$item) { return [status fake, msg 码不存在]; } // 查询次数用 Redis 计数器 $countKey code_count: . $item[id]; $count $redis-incr($countKey); if ($count 1) { $redis-expire($countKey, 86400); } // 异步写日志实际项目用队列 $pdo-prepare( INSERT INTO query_log (code_item_id, ip, query_time) VALUES (?, ?, NOW()) )-execute([$item[id], $ip]); return [ status $count 3 ? suspect : ok, product_name $item[product_name], production_date $item[production_date], query_count $count, ]; }逻辑说明先查 Redis命中则直接返回未命中则查数据库并写缓存。查询次数用INCR原子递增第一次设置过期时间。参数说明缓存过期时间 600 秒根据业务调整计数器过期时间 86400 秒保证当天查询次数可统计。注意Redis 和数据库可能不一致比如码被冻结后缓存还没过期。解决办法是冻结操作时主动删除缓存 key。批量导入码池时不要用INSERT一条条插。用LOAD DATA LOCAL INFILE或者批量INSERT INTO ... VALUES (...), (...), ...每批 1000 到 5000 条。我习惯先用脚本生成一个 CSV 文件再用 MySQL 命令行导入速度比 PHP 循环快一个数量级。导入前记得关掉自动提交导入后COMMIT。最后一个技巧码的校验位。在 12 位码的最后加一位校验位用前 11 位计算得出。这样即使攻击者遍历也需要多算一步而且系统可以在查数据库之前先校验格式减少无效查询。校验位算法可以用简单的模 32 加权和不需要复杂加密。我踩过最深的坑是码池生成时没加唯一索引跑到一半报错重跑又因为随机性导致部分码重复。后来养成习惯任何生成唯一码的表第一件事就是加唯一索引第二件事是生成脚本里捕获冲突并重试。希望帮到你。本文还有配套的精品资源点击获取
PHP一物一码溯源防伪系统v2.1.0：码池设计与防伪判定实战
简介这是一套面向PHP开发者与电商、品牌防伪业务团队的一物一码溯源防伪系统源码基于PHP构建可用于批量生成和管理防伪码、溯源码帮助商品实现从生产到流通的全流程追溯与防伪管理适合有一定PHP基础、需要搭建防伪溯源平台的开发者二次开发或直接部署。资源包共约2000个文件压缩后18.49MB以996个php核心业务文件为主辅以png、gif等图片素材js、css、html构成前端交互与页面json、xml、txt、md承载配置与说明文档另有ttf、woff等字体及少量sh、bat脚本目录结构完整。该版本为v2.1.0新增模块标签属性、OpenApi与Api中间件AccessGate、MySQL8.0兼容、富文本标签download属性过滤、网站地址配置项等19项特性并优化了模块市场显示样式。目前已有516人学习下载读者可获取完整可运行的防伪溯源系统源码用于研究一物一码业务逻辑、后台管理架构与接口设计快速搭建自有防伪码管理平台。1. 一物一码溯源防伪系统到底在防谁从 PHP 魔众 v2.1.0 的码池设计说起你扫一瓶酒上的二维码页面告诉你「正品第 3 次查询首次查询时间 2024-03-11 09:22」。如果这瓶酒是假的造假者大概率也印了同样的码甚至把真码抄了一万遍。一物一码溯源防伪系统要解决的核心矛盾不是「生成二维码」而是让每一个码在数据库里只对应一次真实的生产行为并且让重复查询这件事本身变成证据。PHP 魔众一物一码溯源防伪系统 v2.1.0 就是这类系统的典型实现用 PHP 做后端把码池、批次、查询日志、防伪判定串成一条链路。它适合谁做快消品、农资、化妆品、汽配的团队手里有生产线或代工厂需要一套能自己部署、能改判定规则、能对接公众号或小程序的溯源后台。不适合谁只想贴个二维码做营销跳转的这套东西的复杂度会让你后悔。下面按「码怎么造 → 怎么发 → 怎么查 → 怎么防」四段拆开讲中间会给出可复现的建表、生成、校验代码也会说清楚哪些参数一改就翻车。2. 码池、批次与身份绑定一物一码系统的数据模型怎么立住2.1 为什么不能把码直接存成一张大表很多新手第一版会建一张codes表字段id, code, product_id, status然后批量插入。码量到百万级时查询开始变慢到千万级导出和统计直接拖垮数据库。魔众这类系统通常把「码」拆成两层码池code_pool负责批量预生成码实例code_item负责绑定具体批次和产品。码池是原料码实例是成品。原料可以一次性生成几百万个随机串成品只在出库或贴标时才写入绑定关系。这样做的好处是生成码和发码解耦生产线不会因为数据库写入慢而卡住。另一个关键点是码的随机性。用md5(uniqid())生成短码看起来够随机但uniqid()基于微秒时间戳同一毫秒内并发生成会碰撞。常见做法是用random_bytes或openssl_random_pseudo_bytes取随机源再转成 Base32 或自定义字符集去掉容易混淆的 0/O、1/I。下面是一段可复现的码生成函数字符集 32 位长度 12理论空间 32^12 ≈ 1.15×10^18足够千万级码池使用。?php // 生成一物一码短码字符集去掉 0/O/1/I长度 12 function generateCode(int $length 12): string { $chars 23456789ABCDEFGHJKLMNPQRSTUVWXYZ; // 32 个字符 $max strlen($chars) - 1; $code ; for ($i 0; $i $length; $i) { // random_int 是密码学安全随机比 rand/mt_rand 可靠 $code . $chars[random_int(0, $max)]; } return $code; } // 批量生成并写入码池注意用事务和批量插入 function batchGenerate(PDO $pdo, int $count, int $batchSize 1000): int { $inserted 0; $pdo-beginTransaction(); $stmt $pdo-prepare( INSERT INTO code_pool (code, status, created_at) VALUES (?, 0, NOW()) ); for ($i 0; $i $count; $i) { $stmt-execute([generateCode()]); $inserted; if ($inserted % $batchSize 0) { $pdo-commit(); $pdo-beginTransaction(); } } $pdo-commit(); return $inserted; }逻辑说明random_int是 PHP 7 引入的密码学安全随机函数比mt_rand更适合防伪场景。批量插入时每 1000 条提交一次事务避免长事务锁表。参数说明$length控制码长度12 位在 32 字符集下已经足够$batchSize根据数据库写入能力调整MySQL 一般 500 到 2000 之间。注意code_pool表必须对code字段建唯一索引否则碰撞后无法发现。2.2 批次表与产品表的关联设计码池只是原料真正让码有业务含义的是批次。一个批次对应一次生产任务包含产品 ID、生产日期、有效期、生产线编号。码实例表code_item里存pool_id、batch_id、product_id、bind_time、status。查询时通过码实例找到批次再找到产品。这样设计后召回一个批次只需要把该批次下所有码实例标记为失效不需要动码池。建表 SQL 如下注意索引和字段类型CREATE TABLE code_pool ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, code CHAR(12) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未使用 1已绑定 2作废, created_at DATETIME NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_code (code), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE code_item ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, pool_id BIGINT UNSIGNED NOT NULL, batch_id INT UNSIGNED NOT NULL, product_id INT UNSIGNED NOT NULL, bind_time DATETIME NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 2冻结 3已查询, PRIMARY KEY (id), UNIQUE KEY uk_pool (pool_id), KEY idx_batch (batch_id), KEY idx_product (product_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;参数说明code用CHAR(12)而不是VARCHAR因为长度固定CHAR在索引和比较时更快。uk_pool唯一索引保证一个码池记录只能绑定一次防止重复发码。idx_batch和idx_product用于按批次和产品统计查询。注意如果码量超过 5000 万考虑分库分表或按批次归档单表 InnoDB 在千万级仍然可用但统计查询要加缓存。3. 从生产到出库PHP 侧批量绑定与发码的落地步骤3.1 批量绑定码实例的脚本怎么写生产线上贴标前需要把码池里的码绑定到具体批次。常见做法是后台点「生成批次码」后台异步任务从码池取未使用的码写入码实例表。这里的关键是并发控制多个任务同时取码不能取到同一条。用SELECT ... FOR UPDATE SKIP LOCKED是 MySQL 8.0 的推荐做法MySQL 5.7 则用UPDATE ... LIMIT配合状态位。?php // 从码池取 N 个未使用码并绑定到批次 function bindBatch(PDO $pdo, int $batchId, int $productId, int $need): int { $pdo-beginTransaction(); // MySQL 8.0 支持 SKIP LOCKED避免锁等待 $stmt $pdo-prepare( SELECT id, code FROM code_pool WHERE status 0 ORDER BY id ASC LIMIT ? FOR UPDATE SKIP LOCKED ); $stmt-bindValue(1, $need, PDO::PARAM_INT); $stmt-execute(); $rows $stmt-fetchAll(PDO::FETCH_ASSOC); if (count($rows) $need) { $pdo-rollBack(); throw new RuntimeException(码池余量不足); } $ids array_column($rows, id); $in implode(,, array_fill(0, count($ids), ?)); // 标记码池已使用 $pdo-prepare(UPDATE code_pool SET status 1 WHERE id IN ($in)) -execute($ids); // 写入码实例 $insert $pdo-prepare( INSERT INTO code_item (pool_id, batch_id, product_id, bind_time, status) VALUES (?, ?, ?, NOW(), 1) ); foreach ($rows as $row) { $insert-execute([$row[id], $batchId, $productId]); } $pdo-commit(); return count($rows); }逻辑说明FOR UPDATE SKIP LOCKED让并发任务跳过已被锁定的行不会互相阻塞。先锁码池行再更新状态再写码实例三步在同一事务内。参数说明$need是本次绑定数量建议按生产批次大小传入比如 5000 或 10000。注意如果码池余量不足直接回滚并抛异常不要部分绑定否则批次码数量对不上。3.2 发码接口与防重复提交出库时系统需要把码导出成 CSV 或推送到贴标机。常见做法是提供一个export接口按批次 ID 查询码实例生成文件。这里容易翻车的地方是重复导出操作员点了两次导出贴标机收到两份文件导致同一批码被重复打印。解决办法是在批次表加export_status字段导出前先检查状态导出后置为已导出。?php // 导出批次码防止重复导出 function exportBatch(PDO $pdo, int $batchId): string { $pdo-beginTransaction(); $stmt $pdo-prepare( SELECT export_status FROM batch WHERE id ? FOR UPDATE ); $stmt-execute([$batchId]); $batch $stmt-fetch(PDO::FETCH_ASSOC); if (!$batch) { $pdo-rollBack(); throw new RuntimeException(批次不存在); } if ((int)$batch[export_status] 1) { $pdo-rollBack(); throw new RuntimeException(该批次已导出禁止重复操作); } $pdo-prepare(UPDATE batch SET export_status 1 WHERE id ?) -execute([$batchId]); $pdo-commit(); // 查询码并生成 CSV $rows $pdo-prepare( SELECT cp.code FROM code_item ci JOIN code_pool cp ON cp.id ci.pool_id WHERE ci.batch_id ? ); $rows-execute([$batchId]); $lines [code]; foreach ($rows-fetchAll(PDO::FETCH_ASSOC) as $row) { $lines[] $row[code]; } return implode(\n, $lines); }逻辑说明先用FOR UPDATE锁住批次行检查export_status再更新状态最后查询码。这样即使两个请求同时进来只有一个能通过检查。参数说明export_status默认 0导出后置 1。注意如果导出文件生成失败需要把状态回滚否则批次永远无法再导出。可以在生成文件后再提交事务或者加一个「重置导出状态」的后台操作。4. 扫码查询与防伪判定一次查询背后要跑多少条 SQL4.1 查询接口的完整链路用户扫码后请求打到query接口参数是码。接口要做的事查码是否存在 → 查码是否有效 → 记录查询日志 → 返回查询次数和首次查询时间。防伪的核心逻辑是同一个码第一次查询是正常的第二次查询要提示「已被查询过」第三次以上要标记为异常。但这里有个坑如果用户自己扫了两次系统就判定为假会误伤。常见做法是设置一个「查询次数阈值」比如 3 次以内正常提示超过 3 次才标记为可疑同时记录 IP 和 User-Agent 用于人工排查。?php // 扫码查询接口核心逻辑 function queryCode(PDO $pdo, string $code, string $ip): array { $stmt $pdo-prepare( SELECT ci.id, ci.batch_id, ci.product_id, ci.status, cp.code, b.product_name, b.production_date FROM code_item ci JOIN code_pool cp ON cp.id ci.pool_id JOIN batch b ON b.id ci.batch_id WHERE cp.code ? LIMIT 1 ); $stmt-execute([$code]); $item $stmt-fetch(PDO::FETCH_ASSOC); if (!$item) { return [status fake, msg 码不存在]; } if ((int)$item[status] 2) { return [status frozen, msg 该码已被冻结]; } // 记录查询日志 $pdo-prepare( INSERT INTO query_log (code_item_id, ip, query_time) VALUES (?, ?, NOW()) )-execute([$item[id], $ip]); // 统计查询次数 $countStmt $pdo-prepare( SELECT COUNT(*) AS cnt, MIN(query_time) AS first_time FROM query_log WHERE code_item_id ? ); $countStmt-execute([$item[id]]); $log $countStmt-fetch(PDO::FETCH_ASSOC); $count (int)$log[cnt]; $result [ status $count 3 ? suspect : ok, product_name $item[product_name], production_date $item[production_date], query_count $count, first_query_time $log[first_time], ]; return $result; }逻辑说明先查码实例再查批次和产品然后写查询日志最后统计次数。参数说明$code是用户扫到的码$ip用于记录来源。注意query_log表会快速增长建议按月分表或定期归档。如果查询量很大统计次数可以用 Redis 计数器代替实时COUNT(*)。4.2 防伪判定的参数怎么调查询次数阈值不是固定的。快消品可能 3 次以内都算正常因为用户可能反复扫高价值商品可能 1 次以上就提示「已被查询」。这个参数应该放在后台可配置而不是写死在代码里。常见做法是在config表存query_threshold默认 3。另外首次查询时间要精确到秒并且不能被篡改。query_log表只允许插入不允许更新和删除从权限上保证日志可信。还有一个容易被忽略的点码的查询页面本身可能被伪造。造假者可以做一个一模一样的查询页面用户输入码后返回「正品」。防这种伪造需要在返回结果里带上只有官方系统才知道的校验字段比如用 HMAC 对「码 查询次数 时间戳」签名前端展示时校验签名。下面是一个简单的签名示例?php // 对查询结果签名防止页面伪造 function signResult(array $result, string $secret): string { $payload $result[code] . | . $result[query_count] . | . time(); return hash_hmac(sha256, $payload, $secret); }参数说明$secret是服务端密钥不能泄露。前端拿到签名后用同样的密钥校验实际项目中前端不存密钥而是由服务端校验后返回一个短时 token。注意HMAC 只能防篡改不能防钓鱼页面直接复制官方页面。真正的防伪还是要靠用户从官方入口进入。5. 避坑与排查一物一码系统上线后最容易翻车的 5 个点5.1 码池生成时碰撞但唯一索引没建现象批量生成 100 万个码插入到 80 万时突然报Duplicate entry任务中断。原因code_pool表的code字段没有唯一索引或者用了INSERT IGNORE把冲突悄悄跳过导致实际可用码少于预期。解决建表时加UNIQUE KEY uk_code (code)生成脚本捕获唯一键冲突异常重新生成该条码并重试。不要用INSERT IGNORE它会掩盖问题。5.2 并发绑定导致同一个码被绑到两个批次现象两个生产任务同时执行导出后发现有些码在批次 A 和批次 B 里都出现了。原因绑定脚本没有用事务和行锁两个任务同时SELECT到同一批未使用码。解决用FOR UPDATE SKIP LOCKED锁行或者用UPDATE code_pool SET status 1 WHERE id IN (...) AND status 0检查受影响行数如果行数不等于预期回滚重试。5.3 查询日志表膨胀查询接口变慢现象上线三个月后扫码查询从 200ms 涨到 2s。原因query_log表没有索引或者数据量到千万级后COUNT(*)全表扫描。解决给query_log的code_item_id加索引统计次数用 Redis 计数器日志表按月分表或定期归档到历史库。查询接口里不要实时COUNT(*)而是查缓存。5.4 码被批量爬取防伪系统变成「查号器」现象有人写脚本遍历短码把有效码全部查出来然后复制到假货上。原因查询接口没有频率限制短码空间虽然大但攻击者可以慢慢跑。解决查询接口加 IP 频率限制比如每分钟最多 30 次对连续查询不存在的码的 IP 加入黑名单码长度不要低于 10 位字符集不要太小。如果码量不大可以在码里加入批次校验位让攻击者无法通过简单遍历命中有效码。5.5 导出文件被重复下载贴标机重复打印现象操作员点了两次导出贴标机打印了两份相同的码导致同一码被贴到两个产品上。原因导出接口没有幂等控制。解决批次表加export_status导出前检查并锁定导出后置为已导出。如果导出失败提供「重置导出状态」的后台按钮并记录操作日志。6. 进阶用 Redis 缓存查询结果与批量导入的优化技巧查询接口是读多写少的典型场景。同一个码可能被扫很多次但码本身的信息不会变。我一般会在查询接口前面加一层 Redis 缓存key 是code:{code}value 是码实例的 JSON过期时间设 10 分钟。这样大部分查询直接命中缓存只有第一次和缓存过期后才查数据库。查询次数统计用 Redis 的INCR异步落库避免每次查询都写query_log。?php // 带 Redis 缓存的查询 function queryCodeWithCache(Redis $redis, PDO $pdo, string $code, string $ip): array { $cacheKey code: . $code; $cached $redis-get($cacheKey); if ($cached ! false) { $item json_decode($cached, true); } else { $stmt $pdo-prepare( SELECT ci.id, ci.batch_id, ci.product_id, ci.status, cp.code, b.product_name, b.production_date FROM code_item ci JOIN code_pool cp ON cp.id ci.pool_id JOIN batch b ON b.id ci.batch_id WHERE cp.code ? LIMIT 1 ); $stmt-execute([$code]); $item $stmt-fetch(PDO::FETCH_ASSOC); if ($item) { $redis-setex($cacheKey, 600, json_encode($item)); } } if (!$item) { return [status fake, msg 码不存在]; } // 查询次数用 Redis 计数器 $countKey code_count: . $item[id]; $count $redis-incr($countKey); if ($count 1) { $redis-expire($countKey, 86400); } // 异步写日志实际项目用队列 $pdo-prepare( INSERT INTO query_log (code_item_id, ip, query_time) VALUES (?, ?, NOW()) )-execute([$item[id], $ip]); return [ status $count 3 ? suspect : ok, product_name $item[product_name], production_date $item[production_date], query_count $count, ]; }逻辑说明先查 Redis命中则直接返回未命中则查数据库并写缓存。查询次数用INCR原子递增第一次设置过期时间。参数说明缓存过期时间 600 秒根据业务调整计数器过期时间 86400 秒保证当天查询次数可统计。注意Redis 和数据库可能不一致比如码被冻结后缓存还没过期。解决办法是冻结操作时主动删除缓存 key。批量导入码池时不要用INSERT一条条插。用LOAD DATA LOCAL INFILE或者批量INSERT INTO ... VALUES (...), (...), ...每批 1000 到 5000 条。我习惯先用脚本生成一个 CSV 文件再用 MySQL 命令行导入速度比 PHP 循环快一个数量级。导入前记得关掉自动提交导入后COMMIT。最后一个技巧码的校验位。在 12 位码的最后加一位校验位用前 11 位计算得出。这样即使攻击者遍历也需要多算一步而且系统可以在查数据库之前先校验格式减少无效查询。校验位算法可以用简单的模 32 加权和不需要复杂加密。我踩过最深的坑是码池生成时没加唯一索引跑到一半报错重跑又因为随机性导致部分码重复。后来养成习惯任何生成唯一码的表第一件事就是加唯一索引第二件事是生成脚本里捕获冲突并重试。希望帮到你。本文还有配套的精品资源点击获取
