简介：在电商与品牌运营场景中，防伪码查询系统已成为验证产品真伪、维护品牌信誉的基础设施。一套高效、安全的防伪系统核心在于不可预测的防伪码生成算法与稳定可靠的查询链路。基于PHP与MySQL设计的防伪码查询系统，通过密码学安全随机数生成高强度混合编码，并附加校验位快速拦截无效输入，同时利用原子更新解决首次查询的并发冲突，确保数据一致性。系统还集成了查询日志、风险监控及批次管理，可在LNMP环境下低成本部署，完全自主可控。该方案适用于电商配套、品牌官方验真入口及PHP项目实践，为技术人员提供从算法设计到部署上线的完整参考。 现在做电商和品牌方项目的朋友应该都遇到过这个需求：产品包装上印一串防伪码，消费者刮开涂层、扫码或者手动输入，就能查真伪。我刚做完这套“PHP产品商品防伪码查询系统”，从数据库设计到防伪码生成算法，再到查询端和管理后台，整套源码都是PHP写的，部署在常规LNMP环境就能跑。今天把这套系统的设计思路和核心代码拆开讲一遍，填一填我在开发中踩过的坑，给想自己搭防伪系统或者正在做PHP项目练手的朋友一份可以参考的实操记录。
这套系统适合谁？如果你正在给传统企业做电商配套，或者自己运营品牌想要一个轻量级的验真入口，又或者你想找一个能写进简历的PHP完整项目，这套系统的源码和逻辑都值得过一遍。它不依赖第三方API，防伪码生成、存储、查询、统计全部自主可控，部署成本也就是一台普通服务器加一个MySQL库。
1. 我先说说这个项目到底要解决什么问题
很多非技术背景的老板会以为防伪码就是随机生成一串数字印上去，消费者输进去显示“正品”就完了。实际上，一个能被市场接受的防伪系统至少要解决三件事：防伪码不能被批量猜出来、同一个码第一次查和第二次查要有不同的反馈、后台得有数据记录让品牌方知道哪些区域在大量验真。
先说防伪码被猜的问题。如果防伪码只是简单的流水号，或者用日期加随机数拼接，攻击者完全可以写脚本批量遍历，把所有有效码捞出来做成假码数据库。这套系统里我用的是“随机字符串加校验位”的方案，校验位不是简单的把所有字符加起来取模，而是混入了加权因子。这样一来，即便有人拿到部分明文码，也无法反推出算法生成其他有效码。
再说查询反馈。正品查询系统的核心逻辑是“首次查询显示正品，重复查询给出警示”。这个逻辑背后其实是防伪行业的通行规则：正品码只有第一次被查询时才算有效验真，后续查询都要标记为风险行为。这个需求看似简单，但要注意并发场景下怎么保证“首次”判断的原子性，后面我会讲具体实现。
最后是后台数据。品牌方真正关心的不只是“这个码是不是真的”，还有“哪个批次出货量多少”“哪个区域的查询量异常高”，后者往往意味着窜货或者假货流通。所以管理后台除了增删改查商品和码批次，还要有查询日志的统计视图，最好能用简单的图表展示日查询趋势和地域分布。
这套系统的整体架构不复杂：PHP处理业务逻辑，MySQL存数据，Nginx做Web服务。核心表就三张——商品表、防伪码表、查询日志表，再加一个批次表用来做码管理。没有任何中间件依赖，部署起来门槛很低，也方便二次改造。
2. 整体设计与核心流程拆解
动手写代码之前，先把整个系统的数据流理清楚是值得的。我见过不少半路接手防伪系统的开发者，最容易犯的错就是把查询记录直接堆在防伪码表里，字段越加越多，最后一张表几百个字段，查询性能烂得一塌糊涂。防伪系统的数据流核心是“码的生命周期”和“查询事件的记录”两条线，必须分开建模。
2.1 防伪码从生成到使用的全生命周期
一个防伪码在系统里要经历这些状态：已生成（未关联商品）、已激活（关联到具体商品批次）、已查询（消费者验真过）、已作废（质量问题或误印需要回收）。我在库里用一个status字段来管理，配合查询日志表里的查询时间、IP、UA、查询次数来判断当前码处于什么阶段。
生成阶段要注意的细节是，批量生成时不能一次性把所有码都塞进库里。假设一个品牌要生产10万件商品，直接生成10万条记录，插入耗时不说，内存占用也很夸张。我处理的方式是“分批生成，每批5000条”，并且在码生成时就带上批次号前缀，方便后续按批次导出印刷。印刷厂拿到的文件里，码和批次是一一对应的，这样出了问题能追溯。
当防伪码关联商品批次时，系统会记录activation_time，从这一刻起消费者查询才会走“有效验真”的逻辑。未激活的码如果被查询，系统应该提示“该防伪码尚未激活，请联系销售方核实”，而不是直接判假。这个细节很多初版系统会忽略，导致测试阶段自己查自己都报错。
2.2 表结构设计：三张核心表和一张辅助表
防伪码表的设计决定了整套系统的查询性能和扩展空间。我最终采用的表结构大致是这样的：id、code（防伪码，唯一索引）、batch_id（关联批次）、status（1激活，2已查询，3作废，0未激活）、product_id（关联商品）、first_query_time、first_query_ip、query_count、create_time。这里第一版踩过一个坑，就是没给code加唯一索引，生成码时并发插入直接飙了一堆重复，后来补了唯一索引加上INSERT IGNORE才彻底解决。
查询日志表单独建一张，字段包括id、code_id、query_time、ip、user_agent、query_result。为什么要单独建表而不是在防伪码表里加字段？因为一个码可能被查询很多次，每次查询的IP、时间都要留痕。如果都塞在防伪码表里，一个热点码被刷几千次，光这个字段就爆炸了。日志表走写入为主、查询为辅的路子，目前看压力不大。
批次表和商品表就比较简单了。批次表记录批次号、生成数量、激活数量、创建时间；商品表记录商品名称、型号、所属品牌。商品和批次是多对多的关系，一个商品可能对应多个批次，一个批次也可能包含不同商品，我做了一个中间关联表来解耦。这样后续要加“按商品维度统计查询量”的功能，SQL写起来很顺。
2.3 查询接口的关键判断逻辑
查询接口是这套系统的门面，逻辑上要处理的情况比想象中多。消费者输入的码可能是大写的也可能是小写的，可能带了空格或者横线，甚至可能印刷时把O和0搞混了。所以查询接口的第一步不是先查库，而是做输入归一化：转大写、去空格、去连字符，然后校验格式是否合法。
格式校验通过后，第一步查询按照code字段走唯一索引拿记录。如果记录不存在，直接返回“该防伪码不存在，请核对后重新输入”。如果存在，判断status。这里有一个容易被忽略的细节：首次查询和重复查询的判定不能只靠query_count字段，因为并发下两个请求同时读到了query_count=0，就会都走首次查询的逻辑。我最终用UPDATE语句来做原子自增，同时用受影响行数来判断是不是真的第一次。
具体做法是这样：先UPDATE防伪码表SET query_count = query_count + 1, first_query_time = IF(query_count = 0, NOW(), first_query_time), first_query_ip = IF(query_count = 0, '当前IP', first_query_ip) WHERE code = 'xxx'。然后SELECT回来，判断update之后query_count是不是1。如果是1，那就是真正的首次查询，返回正品信息；如果大于1，就返回“该码已被查询过，首次查询时间是xxx，请谨慎判断”。这套逻辑在MySQL的InnoDB下默认行锁会保证同一时刻只有一个请求能更新这一行，并发安全问题就解决了。
3. 防伪码生成算法与核心逻辑实现
防伪码本身是系统的安全核心，生成策略直接决定了整个系统的防伪强度。我见过不少系统直接用rand()加时间戳拼一个字符串当防伪码，这种码在安全性上约等于裸奔。PHP的rand()和mt_rand()产生的随机数都是可预测的，只要拿到一批样本就能推算出规律。真正安全的防伪码必须用密码学安全的随机源来生成。
3.1 防伪码格式设计
在设计格式时我参考了市面上药监码和化妆品防伪码的通用形态。常见的有纯数字18位、数字加字母混合16位、分组带横线的形式。考虑到消费者手动输入的场景，我最终选了“4位-4位-4位-4位”的16位混合编码，去掉容易混淆的字符（0/O、1/I），保留大写字母和数字。
格式上还有一个细节：防伪码必须带上批次信息或者生成批次可以通过码反查。我的做法不是在码里直接拼批次号，而是通过批次表和码表的关系来关联。码里面只包含随机部分和校验位，这样即便黑客拿到了码，也推不出你的批次规则。
关于码的可读性，我建议不要用纯小写字母。印刷在包装上的码，消费者手动输入时经常分不清大小写，所以查询系统里输入归一化这一步就很重要。统一转大写处理，消费者无论输小写还是大写都能查到。这个很小的设计决定，能帮你省一大半的客服成本。
3.2 使用random_bytes生成高强度随机码
PHP 7以上推荐用random_bytes()来生成安全随机数，这个函数底层会读取操作系统的熵源，生成的随机数不可预测。我这里的实现逻辑是：循环生成随机字节，映射到去除了易混字符的字符集里，直到凑够需要的长度。
/** * 生成防伪码 * @param int $length 码长度 * @return string */ function generateCode(int $length = 16): string { $characters = 'ABCDEFGHJKMNPQRSTUVWXYZ23456789'; $charLen = strlen($characters); $code = ''; for ($i = 0; $i < $length; $i++) { $randomByte = random_int(0, $charLen - 1); $code .= $characters[$randomByte]; } return $code; }这里用random_int()而不是random_bytes()，是因为random_int()可以直接生成指定范围内的均匀随机整数，映射到字符集索引时不需要额外处理偏差问题。如果直接用random_bytes()再模运算符，会有modulo bias，也就是某些字符出现概率略高，虽然实际影响不大，但做安全相关的功能还是要用最稳妥的方案。
批量生成时，我会在循环外先准备好字符集和长度，循环内只做拼接和数组访问，尽量减少函数调用开销。实测生成10万个16位码，耗时在2秒以内，完全能接受。
3.3 校验位算法：让无效码在输入阶段就被拦下
防伪码要防的不仅是随机猜测，还有批量遍历。如果攻击者写脚本把16位字符所有组合都试一遍，虽然组合空间很大（32的16次方），但每个码都要走一次数据库查询，有缓存的情况下数据库压力能扛住，但对系统日志和反作弊会造成干扰。所以我在码尾加了一位校验位，格式上快速拦截明显无效的码。
校验位算法用的是ISO 7064的MOD 31-3变体，本质上是把码字符映射为数值，然后逐位加权求和，再用31取模得到一个校验字符。计算过程和银行卡号校验的Luhn算法思路类似，都是用一个固定规则让码在结构上自洽。
/** * 计算校验位 * @param string $code 不含校验位的码 * @return string */ function calcCheckChar(string $code): string { $charset = 'ABCDEFGHJKMNPQRSTUVWXYZ23456789'; $map = array_flip(str_split($charset)); $total = 0; $weight = 2; $len = strlen($code); for ($i = 0; $i < $len; $i++) { $total += ($map[$code[$i]] ?? 0) * $weight; $weight++; if ($weight > 7) { $weight = 2; } } $mod = $total % 31; return $charset[$mod]; }格式校验时先查码长度是否为16位（15位随机加1位校验），然后调用校验函数对比最后一位是否匹配。不匹配的直接返回“防伪码格式不正确”，完全不用查数据库。这个前置校验看起来多余，实际上能把无效请求量减少80%以上，对保护数据库很有价值。
3.4 批量生成和导出：避免一次性写入引发的性能问题
真实业务中一次性生成几万几十万个码是常有的事。直接在循环里逐条INSERT效率极低，我采用的是“每5000条拼一个批量INSERT，用一条SQL插入”。在ThinkPHP框架里可以用addAll()，原生PHP就手动拼SQL，注意拼完后用implode()连接值字符串。
另一个容易被忽略的问题是导出。印刷厂要的码文件通常是Excel或者TXT，TXT最简单，一行一个码。导出的时候如果一次性SELECT全部记录再写文件，内存会爆。正确做法是每次取1000条写入文件，然后继续取下一批，用生成器或者循环分段查询都可以。
$batchSize = 1000; $lastId = 0; while (true) { $rows = query("SELECT code FROM anti_fake_code WHERE batch_id = {$batchId} AND id > {$lastId} ORDER BY id ASC LIMIT {$batchSize}"); if (empty($rows)) { break; } foreach ($rows as $row) { fwrite($fp, $row['code'] . PHP_EOL); } $lastId = end($rows)['id']; }这种分段拉取的方式无论表多大都能稳定导出，不会因为数据量增长出现内存溢出。导出后还要生成一个同名的校验文件（通常是MD5），方便和印刷厂对码的时候核对文件完整性。
4. 查询端实现细节：从输入到反馈的完整链路
查询端是消费者唯一接触到的功能模块，体验好不好直接影响品牌形象。我的实现里把查询端分成三个层级：前端页面、查询处理器、数据层。前端页面的核心是一个输入框加一个查询按钮，支持扫码自动填充。查询处理器负责输入归一化、格式校验、调用核心查询逻辑、拼装返回结果。数据层就是上一节讲的表结构和SQL。
4.1 输入归一化：你以为用户输对了，其实并没有
消费者的输入千奇百怪。有人会连着一串小写字母输入，有人会加空格，有人会把印刷体里的O看成0，有人会输入全角字符。我在查询接口的第一步统一做了一次清洗：先转大写，然后去除所有非字母数字字符，再校验长度。这个清洗影响面很大，曾经统计过，做不做归一化，查询失败率能差出15%。
$input = strtoupper(trim($_POST['code'] ?? '')); $input = preg_replace('/[^A-Z0-9]/', '', $input); if (strlen($input) !== 16) { return json_encode(['code' => 400, 'msg' => '防伪码格式不正确，请核对后重新输入']); }归一化之后紧接着做校验位检查。注意这里不能把校验位检查放在数据库查询后，否则无效码还是打到了数据库。格式校验和校验位校验都过了，才进入数据库查询流程。这个顺序是我踩过坑总结出来的，之前先查库再校验，日志里全是无效码的查询记录，看着心烦。
4.2 首次查询与重复查询的并发安全问题
前面提过用UPDATE加SELECT的方式解决并发问题，我把它完整拆开说一下。核心是先执行一个原子UPDATE，让MySQL锁住这一行，然后用UPDATE之后的值来判断是不是首次。关键点是UPDATE里用IF(query_count = 0, 当前时间, first_query_time)，这样即使第二次第三次查询，首次查询时间也不会被覆盖。
$now = date('Y-m-d H:i:s'); $ip = getClientIp(); $updateSql = "UPDATE anti_fake_code SET query_count = query_count + 1, first_query_time = IF(query_count = 0, '{$now}', first_query_time), first_query_ip = IF(query_count = 0, '{$ip}', first_query_ip) WHERE code = '{$code}'"; $affected = execute($updateSql); if ($affected === 0) { // 码不存在 } $row = queryOne("SELECT product_name, query_count, first_query_time FROM anti_fake_code WHERE code = '{$code}'"); if ($row['query_count'] == 1) { // 首次查询，返回正品验证信息 } else { // 重复查询，提示用户注意风险 }用UPDATE做原子操作有个额外好处：查询日志表里不需要单独搞一个“是否首次”的状态，直接通过防伪码表的状态就能推导。写日志的时候记录一下本次查询是第几次，做数据分析的时候非常有用。我还有一个建议是，重复查询时不要直接说“假货”，而是用中性措辞“该防伪码已被查询过，请确认商品来源”，这样既尽到告知义务，也避免误伤正品用户。
4.3 防止恶意刷码：验证码、限流和黑名单
防伪查询系统天生会被羊毛党盯上。有人想批量跑码捞有效码，有人想频繁查询某个码把查询次数顶爆。我在查询接口做了三层防护。
第一层是图形验证码。首次查询时必须填写验证码，虽然增加了一点用户操作成本，但能挡住大部分脚本。我用的是一张内置的验证码类，生成干扰线加噪点，PHP的GD库就能画，不需要额外组件。考虑到移动端体验，我后来又加了滑动验证的方案，轻量级，不需要SDK。
第二层是IP频率限制。记录每个IP最近一分钟的查询次数，超过10次就强制要求等待60秒或者直接拒绝。这个阈值是经验值，正常消费者一分钟内不可能查十几次码，只有脚本会这么干。实现上可以用文件缓存或者Redis，单机场景用APCu或文件就行了，为了一个限流上Redis有点杀鸡用牛刀。
第三层是热门码保护。如果一个码被查询超过50次，系统会把这个码标记为风险状态，后续查询一律提示“该码存在异常查询记录，请联系官方客服核实”。这么做防止了黑客通过疯狂查询某个码来干扰正常用户的验真流程。同时后台会把风险码列表推送给管理员，人工介入判断是真被仿冒了还是有人在恶意攻击。
4.4 扫码查询：给传统商品加上数字化入口
现在做防伪系统基本绕不开扫码查真伪。印刷在包装上的二维码内容是普通URL，比如https://yourdomain.com/verify?code=XXXX，消费者扫码后自动跳转到查询页面，URL参数里的码自动填充到输入框。注意二维码里塞的码不能是完整防伪码本身吗？其实可以，但要做好URL参数加密，或者至少签个名。
我建议在URL里不放明文码，而是放一个一次性token，token和防伪码在服务端做映射。这样即使二维码被恶意扫描，攻击者拿到的也不是直接可用的防伪码；而且token可以设置有效期，过期后扫码要重新进入查询页手动输入。这个方案在货架陈列和海报场景下很实用，毕竟海报上的二维码谁都能扫。
不过要提醒的是，一次性token也有代价：印刷二维码的时候就必须预生成token和防伪码的映射关系，相当于多一张表。如果码量特别大，存储和生成的成本要算上去。小型项目直接放明文码也能接受，只要后面加个请求频率限制就行。
5. 管理后台功能迭代与数据统计实现
管理后台是整个系统的中枢，没有后台的防伪系统就像汽车没有方向盘。我用一套简单的RBAC权限模型做了管理员登录，然后分了商品管理、批次管理、码管理、查询日志、数据报表五个模块。这里挑几个重要功能讲讲细节。
5.1 商品管理：品牌方维护产品库
商品表最基本的字段是product_name、product_model、brand_id。我在做的时候加了一个“验真话术”字段，也就是消费者查询成功时展示的一段话，比如“您查询的是某某品牌经典款XX，生产日期xxxx，请放心使用”。这个字段的好处是品牌方可以针对不同商品定制验真体验，而不是所有商品都用一句通用的话。
商品管理的操作界面就是常规的列表加表单，列表支持按品牌筛选、按状态筛选、关键字搜索。改动记录做一次日志审计，谁改了什么字段、什么时候改的，都记录到操作日志表里。这个功能一开始觉得是浪费，后来老板要求排查一次误操作才意识到审计日志有多重要。
5.2 批次管理：从生成到激活的全流程
批次管理的核心操作是“生成新批次”和“激活批次”。生成新批次时填写商品、数量、有效期，系统自动调用生成函数创建防伪码并写入数据库。生成后码的状态是“未激活”，此时可以导出印刷。印刷完成、商品入库后，管理员在后台激活整个批次，激活后码才可以被正常查询。
激活操作有一个前置条件：批次下的码必须全部生成成功且没有重复。我的代码里激活前会先跑一遍查重SQL，把重复码揪出来。这个防重操作其实是在生成阶段就做了，但激活前再跑一次相当于双保险。如果一个批次里发现少量重复码（概率极低），系统会标红提示，管理员可以选择重新生成这部分码。
批量激活还有一种场景是“按码段激活”，比如只激活某个批次前1000个码，用于小批量试销。实现上就是在激活表单里加一个“只激活前N个码”的选项，SQL用LIMIT控制更新范围。这个功能一开始觉得鸡肋，后来有个客户做小规模市场测试，专门打电话要求加这个功能，才明白不同业务对批次管理的需求差异很大。
5.3 查询日志和异常监控：数据价值往往比验真本身更大
查询日志表在系统上线最初看起来只是记录数据，但随着数据积累它的价值会越来越大。我做了三个维度的统计：一是按日维度的查询量趋势，可以看出一个商品的市场热度；二是按地域维度的查询量分布（通过IP解析粗略定位），可以辅助发现窜货问题；三是按商品维度的首次查询率，首次查询率越高说明正品流通越健康。
异常监控这块，我的实现是后台每10分钟跑一次定时脚本，检查近10分钟内的查询曲线。如果某个商品的查询量突然暴增到日常均值的5倍以上，系统自动发警告邮件给管理员。这个逻辑在第一版用的是固定阈值，后来发现不同商品的日常查询量差异很大，固定阈值会造成大量误报，改成了动态阈值：以近7天同一时间段的均值为基准，超过3倍标准差才报警。
$avg = getAvgQueryCount($productId, date('Y-m-d H:i', strtotime('-7 days')), date('Y-m-d H:i', strtotime('-10 minutes'))); $std = getStdQueryCount($productId, date('Y-m-d H:i', strtotime('-7 days')), date('Y-m-d H:i', strtotime('-10 minutes'))); $current = getQueryCount($productId, date('Y-m-d H:i', strtotime('-10 minutes')), date('Y-m-d H:i')); if ($current > $avg + 3 * $std) { sendAlertEmail($productId, $current, $avg); }动态阈值方案上线后误报少了非常多。使用标准差的逻辑稍微复杂，但理解起来并不难：正常波动应该在均值附近，超过3倍标准差的小概率事件才值得关注。这套监控逻辑不仅适用于防伪系统，其他做流量异常检测的场景也能直接借鉴。
5.4 导出报表：给运营部门一个能看懂的数据出口
管理后台最后还要考虑数据出口。运营和市场部门不会用SQL，他们要的是Excel报表。我做了一个“按日汇总”的导出功能，格式是：日期、商品名称、查询总量、首次查询量、重复查询量、风险码数量。用PHP的fputcsv()直接输出CSV，Excel打开不乱码的方法是输出BOM头。
还有防伪码使用率报表，它的计算逻辑是“已激活码中被查询过的比例”。这个数字对品牌方太重要了——如果一批货上市一个月使用率只有5%，说明要么出货渠道不顺畅，要么包装上的防伪入口没有触达消费者。我用一个简单的SQL就能算出来，然后在后台用柱状图展示。PHPlot或者Chart.js都能画，我是直接用Chart.js，前端写一个接口返回JSON，图形渲染交给浏览器。
6. 部署与上线：几个值得注意的坑
系统开发完不等于上线就能跑，部署阶段往往会暴露一堆只在生产环境才会出现的问题。我分PHP配置、MySQL配置、Web服务器配置三个方面来讲。
6.1 PHP环境要求与常用配置
代码要在PHP 7.4以上环境跑，建议PHP 8.0或8.1。核心扩展需要PDO和GD库。安装时记得开启pdo_mysql，GD库用于生成验证码图片。fileinfo扩展也建议开启，处理上传校验的时候会用到。
生产环境有几个配置项要调整：display_errors设为Off，错误日志打开，error_reporting设为E_ALL。防伪系统面向公网，错误信息暴露给用户是安全隐患。另外max_execution_time建议改成300秒，因为批量生成码的时候如果码量大，单次请求可能超过默认的30秒限制。这里更好的做法是用CLI脚本跑批量生成，命令行不限制执行时间。
6.2 MySQL表结构优化与索引策略
表结构章节已经讲过了，这里补充索引策略。防伪码表的主键是自增id，但业务查询都走code字段，所以必须给code建唯一索引。实测在100万条码数据下，通过code查询单条记录在2毫秒以内。查询日志表按code_id和时间建联合索引，方便按码查询历史记录。
运行一段时间后要定期清理过期日志。防伪查询日志是持续增长的，三个月前的数据基本没人看，但占用空间不小。我用一个定时任务在每月的1号凌晨把三个月前的日志归档到备份表，原表只保留近三个月的数据。这样查询日志表的体积始终可控，统计接口的性能不会越来越差。
6.3 服务器安全与上线自检清单
上线前我把安全清单列了一个Excel表，逐项打勾确认。这里挑几个关键的说：首先确认PHP错误信息不暴露，访问不存在的路径返回404而不是报错堆栈。其次确认防伪码查询接口有权限制，至少要有基础的频率限制。再次是后台登录地址不要用admin.php这种默认命名，改成随机字符串，配合IP白名单更稳。最后是数据库连接密码不要明文写在PHP文件里，用环境变量或者同目录下的config.php做include，同时确保web目录不能直接访问config文件。
HTTPS是必须的。防伪查询页面如果不走HTTPS，消费者的查询行为和码信息等于在公网明文传输，中间人攻击可以直接截获。配置免费的Let's Encrypt证书就能解决，部署Nginx时把HTTP请求301跳到HTTPS就行。这个不做的话，后续品牌方审核会直接被否掉。
7. 常见问题与排查技巧实录
开发这套系统的过程里，有几类问题出现的频率特别高，我整理了排查思路和解决方案。这里的内容基本是实战记录，网上文档很少把这些坑写全。
7.1 批量生成防伪码时出现了重复码
出现重复码最可能的原因是没有给code表加唯一索引，或者生成算法用了不带随机种子的rand()。我在第一版测试时就发现了这个问题，排查思路是先看重复码的分布，如果在同一批次内重复，说明生成函数有问题；如果跨批次重复，说明库表缺少唯一约束。最终解决方案是双管齐下：生成函数用random_int()保证随机性，同时给code字段加唯一索引，即便极端情况下生成了重复码，INSERT时也会直接报错而不是静默写入。
还有一个隐藏较深的重复原因：多进程并发生成。如果你用多个PHP进程同时跑生成脚本，没有加互斥锁，两个进程可能拿到相同的随机数（虽然概率极低但存在）。解决办法是给生成脚本加一个锁文件，用flock()阻止并发执行。
7.2 首次查询就提示“已被查询过”
这个问题排查了半天，最后发现是逻辑里判断二次查询时用query_count > 1而不是query_count != 1。因为UPDATE之后有一个查询日志的写入操作，如果这个操作也更新了query_count字段，就会把1变成2。换句话说，是写入日志和业务查询逻辑互相干扰了。
定位问题的思路是看查询日志表，发现每次首次查询都会产生两条日志，第二条日志的写入时间比第一条晚了不到1秒。原来是把日志写入逻辑放在了防伪码表更新之后，重新查了一次防伪码表结果把query_count又加了一次。改成日志表独立写入后问题消失。
7.3 查询接口响应慢，数据库CPU飙高
一次业务高峰期，查询接口从原本的100毫秒变成了2秒，数据库CPU接近100%。排查后发现是有人用脚本批量遍历16位纯数字的组合码，因为代码里没有校验位的前置校验，所有无效请求都查到了数据库，直接把MySQL打满。
解决方案就是我前面讲的，在查询接口最前面加上校验位检查，无效码根本不会进入数据库SQL。同时加上了IP频率限制。上线后数据库CPU从100%降到10%以内，查询响应恢复到了50毫秒左右。这个案例说明，前置校验不只是为了用户体验，更是保护后端资源的关键手段。
7.4 二维码扫码后跳转404
二维码里的URL如果是相对路径，或者编码时用了短链，扫码跳转就可能404。排查这类问题有几个方向：首先看URL是否包含完整域名，其次看服务器伪静态规则是否配置正确，最后看码中是否包含特殊字符，导致URL解析错误。
我在一个客户那里遇到过扫码后码被截断的问题，最后发现是二维码生成库默认的容错率太低，包装上的折痕让扫码识别少了一位。方案是把二维码容错级别调高一级（M调到Q），同时把URL参数里的码做了校验处理，少一位也能提示“格式不正确”而不是跳转404。
7.5 查询页在手机上样式错乱
防伪查询页被大量消费者用微信内置浏览器打开，前端样式必须做移动端适配。我最初做的是PC版页面，在手机上显示特别小，按钮点不到。后来引入了Bootstrap框架，用栅格系统适配不同屏幕尺寸。关键是查询按钮的点击区域至少要44px高，输入框字体大小不要低于16px，否则iOS浏览器会自动放大，反而干扰输入。
另一个细节是页面加载速度。扫码场景下用户没有耐心等太久，页面体积优化很重要。我把CSS和JS合并压缩，背景图转成Base64内联，少量必要的图标用SVG。实测PC页面压缩前300KB，压缩后80KB，移动网络的加载体验改善明显。
8. 这套系统后续还能怎么扩展
防伪系统的核心价值在数据，不在代码。目前这套系统跑通了“生成-印刷-查询-统计”的完整链路，但后续可扩展的方向还有很多。我这里列几个我认为值得探索的场景，就当给拿到源码的朋友指个方向。
第一个方向是结合区块链做去中心化验真。目前所有数据都在自己的数据库里，消费者只能无条件信任品牌方。如果把每次查询的哈希写入区块链，消费者就能自行验证数据没有被篡改。实现上不用太复杂，查询日志表里加一列hash字段，定时把一批日志打包计算Merkle根，上链存证即可。这个方向对高端品牌尤其有吸引力。
第二个方向是接入微信小程序。现在很多消费者不太愿意在浏览器里输码，更习惯打开小程序拍照扫码。小程序端做好授权登录和扫码解锁，体验比H5好很多。后端接口不用大改，查询逻辑已经做好了，加一个小程序端的适配层就行。
第三个方向是基于查询数据做精准营销。消费者查询防伪码的时候，意味着他刚拿到商品，这是品牌和消费者建立连接的最佳时机。查询结果页可以展示商品使用教程、售后入口、会员注册引导，甚至根据IP归属地推荐线下门店。这些在技术层面都只是加字段和改前端展示的问题。
我在做完这套系统后最大的体会是：防伪查询不只是技术问题，更是品牌运营问题。技术层面的生成算法、数据库设计、防刷机制，都只是为业务服务的底座，真正有价值的是让每一次查询都给消费者带来信任，给品牌方带来数据。这套源码的基础功能现在很稳定，扩展性也不错，如果有朋友在类似的项目上遇到问题，欢迎在评论区聊聊你的场景，我可以针对性地分享一些细节。
本文还有配套的精品资源，点击获取
