简介一套PHP实现的二维码防重防错系统源码包面向需要为业务二维码加入防重复、防错误管理能力的中小企业开发者、企业信息化人员或个人站长。系统覆盖从生成到扫码验证的完整链路首页直接作为扫码功能页使用能按天生成二维码并打印输出有效避免跨日期编号冲突后台可统计二维码总数、当天数量、打印数量和扫码次数方便运营人员掌握发放与使用情况。管理端支持设置二维码前缀18位、默认日打印量、是否附加年月日序号以及序号位数规则灵活安装后先完成基础数据配置即可正常使用。压缩包约5.24MB整体以PHP源码和相关配置为主解压后即可部署调试。目前已有232人参与学习/下载适合需要快速上线二维码防重防错功能并有意在此基础上进行二次开发或集成的开发者。1. 二维码防重防错系统为什么PHP方案依然是工厂流水线的首选在生产车间里二维码贴错、扫重、漏扫带来的损失往往不是一张标签的成本而是一整批产品流向错误、追溯链条断裂的连锁反应。很多团队一上来就想到用手机扫码加Excel记录结果在产线节拍面前完全撑不住扫码枪连点两下就重复记录不同工位的IPQC制程检验各自维护一张表到了出货前对账发现数据对不上只能让人趴在包装线上一箱箱翻。所谓二维码防重防错系统本质上是把「扫一次、验一次、记一次」变成一个不可跳过的闭环码本身要有唯一性校验扫到的码要和当前工单、工序、物料绑定重复扫码直接拦截错扫立刻告警。而PHP在这个场景里被大量选用不是因为它是性能最强的语言而是因为它在中小型工厂里部署成本最低、和现有ERP/进销存系统的对接最省事——一台Windows旧电脑加Apache就能跑起来产线上的扫码枪本身就是一个键盘输入设备页面轮询或WebSocket推送就能实现工位大屏的实时刷新。这套方案的落地难点从来不是PHP本身而是防重逻辑怎么写、防错规则怎么配、数据一致性怎么保证。本文就沿着一条实际可复现的路径把从建表到上线的完整做法拆开来讲。2. 防重防错的底层逻辑先搞清要拦截哪两类脏数据2.1 防重是物理层面的拦截同一码在限定范围内只能成功登记一次二维码防重的核心不是让码本身不可复制而是让同一个码在业务规则限定的范围内只能产生一条有效记录。常见的错误认知是「码唯一就够了」但实际产线里码可能是供应商印的、内部重复打印的、甚至回收周转箱上反复使用的旧码码本身不唯一的情况大量存在。因此防重要同时做两层校验第一层是码格式与校验位检查拦截那些明显不合规的扫描值第二层是业务唯一性检查在登记时按「码 工单号 工序号」或「码 批次号」的组合去查重。// 防重登记核心逻辑先查重再插入全程在同一事务里 public function checkAndRegister($code, $workOrder, $processId) { $pdo-beginTransaction(); try { // 锁定查询避免并发下两条请求同时通过检查 $stmt $pdo-prepare( SELECT id FROM scan_record WHERE code :code AND work_order :wo AND process_id :pid FOR UPDATE ); $stmt-execute([:code$code, :wo$workOrder, :pid$processId]); $exists $stmt-fetch(); if ($exists) { $pdo-rollBack(); return [status duplicate, message 该码在当前工单已扫描过]; } // 插入记录并提交 $insert $pdo-prepare( INSERT INTO scan_record (code, work_order, process_id, scanned_at, scanner) VALUES (:code, :wo, :pid, NOW(), :scanner) ); $insert-execute([:code$code, :wo$workOrder, :pid$processId, :scanner$scanner]); $pdo-commit(); return [status success]; } catch (Exception $e) { $pdo-rollBack(); throw $e; } }这段代码里最关键的是FOR UPDATE行级锁。如果去掉这个锁两个工位同时扫同一个码时两个请求可能都通过SELECT检查然后各自插入一条记录防重就失效了。事务的意义也在于此查重和插入必须是原子的中间任何一步失败都不能留下半条脏数据。生产环境里还要在数据库层面加唯一索引兜底哪怕PHP逻辑出了问题数据库也会拒绝重复插入。-- 数据库层面的兜底唯一索引 ALTER TABLE scan_record ADD UNIQUE INDEX uniq_code_wo_process (code, work_order, process_id);这个唯一索引是防重的最后一道防线。PHP逻辑负责给出友好提示数据库负责强制约束两层缺一不可。如果只依赖PHP查重在高并发或扫码枪连按的情况下总有机会漏过去如果只依赖数据库索引用户看到的就是一条冰冷的SQL报错体验太差。两者配合才能既堵住数据漏洞又给出能直接展示在工位屏上的中文提示。2.2 防错是业务层面的校验码必须匹配工单、物料和工序状态防错和防重是两回事。防重解决的是「同一个码被扫了两遍」防错解决的是「扫进来的码根本不属于当前这单生产任务」。典型的场景是装配线上正在做A型号的产品操作工不小心扫到了旁边B型号的物料码或者仓库送来的原料批次和当前工单要求的批次不一致。防错校验要在扫码登记的瞬间把码的内容解析出来和当前工单的物料编码、工艺路线进行比对。// 防错校验解析码内容并与工单绑定信息比对 public function validateAgainstWorkOrder($rawCode, $workOrderId) { // 假设码规则前缀表示物料编码中间是日期末尾是流水号 // 例如MAT-100234-20250610-000123 $pattern /^([A-Z])-(\d)-(\d{8})-(\d)$/; if (!preg_match($pattern, $rawCode, $m)) { return [status invalid_format, message 二维码格式不符合规则]; } $materialCode $m[1] . - . $m[2]; // MAT-100234 $wo WorkOrder::find($workOrderId); if ($materialCode ! $wo-material_code) { return [ status material_mismatch, message 物料不匹配当前工单要求 . $wo-material_code . 扫入的是 . $materialCode ]; } // 再校验工序状态当前工序是否已经是扫码完成状态 if ($wo-current_process_status completed) { return [status process_closed, message 当前工序已完成禁止补扫]; } return [status ok]; }这里有两个容易踩的坑。第一码规则的正则一定要和实际印刷的码严格对齐很多工厂用的是GS1编码或Code 128解析规则完全不同不能想当然。第二工序状态校验必须放在插入之前有些系统只在界面层做按钮禁用操作工刷新页面或换个入口就能绕过。防错逻辑最忌讳「只挡君子不挡小人」它要挡的是生产现场的随机误操作而不是应对恶意绕过但即便如此所有校验都要在服务端完成前端禁用只是体验优化不是安全边界。2.3 选型理由PHP在这个场景里的边界在哪里聊完逻辑再看选型。PHP做二维码防重防错系统的优势在于中小工厂的IT环境几乎都是Windows Server或干脆就是普通PCPHP的WAMP/LAMP一键部署太成熟了扫码枪模拟键盘输入PHP接收表单提交的延迟在本地网络下是毫秒级完全够用工厂后续要对接用友、金蝶这类ERP时PHP的SOAP和REST客户端库都很成熟。它的边界也很明确如果产线并发超过每秒几十次扫码或者扫码枪要通过TCP/IP直连而非键盘模拟PHP这种传统请求-响应模型就会吃力需要引入队列或换成常驻内存服务。但绝大多数中小工厂的产线节拍是每几分钟才扫一次PHP的性能余量绰绰有余硬上Java或Go反而是给自己找麻烦——没人维护、招人困难、改个页面都要重新编译。3. 从零搭建最小可用系统数据库设计、扫码接入与实时看板3.1 数据库设计四张核心表撑起整套防重防错规则防重防错系统的数据库设计不能只围绕「扫码记录」这一张表来想否则后面加规则、加报表都会被动。我一般会设计四张核心表工单表work_order维护生产任务及其物料、工序状态二维码规则表qr_rule维护每种码的解析正则、物料编码位置、校验逻辑扫码记录表scan_record存储每一次成功登记录入异常记录表scan_exception记录拦截下来的重复码、错码、格式异常码方便后续追溯和产线对账。-- 工单表一个工单对应一个物料编码记录当前所处工序状态 CREATE TABLE work_order ( id INT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(50) NOT NULL UNIQUE, material_code VARCHAR(50) NOT NULL, current_process_id INT NOT NULL, current_process_status VARCHAR(20) DEFAULT pending, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 二维码规则表不同码制用不同解析规则 CREATE TABLE qr_rule ( id INT AUTO_INCREMENT PRIMARY KEY, rule_name VARCHAR(50) NOT NULL, pattern VARCHAR(255) NOT NULL COMMENT 正则表达式, material_code_pos INT NOT NULL COMMENT 物料代码在第几个捕获组, enabled TINYINT DEFAULT 1 ); -- 扫码记录表防重防错的最终落库 CREATE TABLE scan_record ( id INT AUTO_INCREMENT PRIMARY KEY, code VARCHAR(128) NOT NULL, work_order_id INT NOT NULL, process_id INT NOT NULL, scanned_at DATETIME DEFAULT CURRENT_TIMESTAMP, scanner VARCHAR(50) NOT NULL, UNIQUE KEY uniq_wo_process_code (work_order_id, process_id, code) ); -- 异常记录表拦截动作也要留痕 CREATE TABLE scan_exception ( id INT AUTO_INCREMENT PRIMARY KEY, code VARCHAR(128) NOT NULL, work_order_id INT, reject_type VARCHAR(30) NOT NULL COMMENT duplicate/material_mismatch/invalid_format, reject_message VARCHAR(255) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );扫码记录表里的唯一索引用的是work_order_id process_id code组合而不是单独的code唯一。原因很实际同一个产品码在出厂后可能经过返修重新上线如果按码全局唯一返修流程就永远走不通。组合唯一索引既保证了在同一个工序里码不会被重复扫又给返修、重工留了口子。异常记录表很多人会忽略但它其实是工厂最需要的——生产主管要的不是「你拦了多少」而是「拦下来的都是什么原因」这张表就是给管理看的数据依据。3.2 扫码终端接入把扫码枪变成不需要培训的输入设备扫码枪接入是这套系统里最简单也最容易出问题的环节。市面上绝大多数USB扫码枪默认模拟键盘输入扫一下等于在焦点输入框里快速敲一串字符再加回车所以PHP端只需要一个普通的表单输入框autofocus加上回车提交就够了。这里的关键是输入框的失焦处理如果操作工点了页面其他地方再回来扫码焦点不在输入框里扫码枪敲的字符会丢到页面空白处。!-- 扫码输入框自动聚焦 回车提交禁止手动输入 -- !DOCTYPE html html langzh-CN head meta charsetUTF-8 title产线扫码 - 工位#3/title /head body form idscanForm methodpost action/index.php?actionscan input typetext idcodeInput namecode autofocus autocompleteoff placeholder请扫描二维码 stylefont-size:36px;width:100%;text-align:center;padding:20px; input typehidden namework_order_id value?php echo htmlspecialchars($woId); ? input typehidden nameprocess_id value?php echo htmlspecialchars($processId); ? /form script // 扫码枪输入完成后一般是回车直接提交表单 document.getElementById(codeInput).addEventListener(keydown, function(e) { if (e.key Enter) { e.preventDefault(); this.form.submit(); } }); // 点击页面空白处后点击这个区域重新聚焦扫码框 document.body.addEventListener(click, function() { document.getElementById(codeInput).focus(); }); /script /body /html这个页面的坑在于提交后的页面跳转。如果提交后返回一个「成功」或「失败」的整页响应操作工扫完一个码要等页面刷新完成才能扫下一个在节拍快的产线上就会有人不耐烦地连点提交按钮从而触发防重校验——本来只是网络延迟结果被系统当成重复扫码拦截了。更好的做法是改用AJAX提交页面不跳转扫码框始终保持聚焦成功时清空并提示失败时保留输入框内容并给红色警示音。扫码枪一般能配置后缀字符常见的默认后缀是回车但也有些枪出厂是Tab键如果发现表单提交不了或焦点跳走第一件事就是查扫码枪说明书设置后缀。// AJAX 提交页面不刷新适合快速连续扫码 document.getElementById(scanForm).addEventListener(submit, function(e) { e.preventDefault(); var formData new FormData(this); fetch(/index.php?actionscan_ajax, { method: POST, body: formData }) .then(response response.json()) .then(data { if (data.status success) { document.getElementById(codeInput).value ; showMessage(✅ data.message, success); } else { showMessage(⛔ data.message, error); // 失败时不清空方便用扫码枪重新扫同一个码覆盖 } document.getElementById(codeInput).focus(); }) .catch(err { showMessage(网络错误 err.message, error); document.getElementById(codeInput).focus(); }); });这里失败的场景做了「不清空」处理是产线上很实用的细节。常见的情况是操作工扫了一个错误的码系统弹窗提示物料不匹配然后操作工换了正确的物料重新扫——如果刚才的错误码还留在输入框里新扫的码会覆盖它这没问题但如果系统自动清空了操作工扫到一半发现不对又扫下一个中间的空档期也可能产生误操作。所以保留错误码在输入框中让新扫码自然覆盖比清空更符合实际操作习惯。3.3 工位大屏与后台管理用轮询还是WebSocket工位大屏的本质是「扫码结果的集体可见」。一个车间里可能有十来个工位工位上的小屏要显示当前工单进度车间接上方的电视大屏要显示各工位的产量和异常数。实现方式有两种轮询和WebSocket。PHP原生环境下用轮询更务实——每隔2秒请求一次最新统计数据通过JSON返回前端用setInterval刷新。这种方式在几十个工位的规模下完全够用而且部署简单不需要额外维护常驻进程。真的到了几百个工位、数据要实时汇总的规模再用Workerman或Swoole做WebSocket推送。// 工位大屏轮询接口返回当前工单的统计信息 public function dashboardStats($workOrderId) { $stats $pdo-prepare( SELECT COUNT(*) AS scanned_count, SUM(CASE WHEN process_id :current_process THEN 1 ELSE 0 END) AS process_scanned, (SELECT COUNT(*) FROM scan_record WHERE work_order_id :wo) AS total_scanned FROM scan_record WHERE work_order_id :wo ); // 实际项目里上面的SQL语句会分开写得更清晰这里合并示意 echo json_encode($stats-fetch(PDO::FETCH_ASSOC)); }轮询的间隔不是越小越好。2秒的间隔在大屏上人眼感知不到卡顿但服务器压力是0.5秒间隔的四分之一。扫码枪的录入本身是一次POST请求轮询是若干GET请求两者混在一起时要注意PHP-FPM的进程数上限——如果开了50个PHP-FPM子进程扫码请求被轮询请求占满就会出现扫码页面转圈、大屏却是正常刷新的诡异现象。避坑的方法是给轮询接口单独设置更短的超时时间并且在Nginx层限制这个接口的并发或者直接启用OPcache减少PHP脚本编译开销。4. 参数配置与规则管理正则解析、唯一性范围、放行策略的取舍4.1 二维码解析规则把「一串字符」变成「有意义的业务字段」二维码防错的前提是能从码里解析出业务字段。不同工厂的码规则千差万别常见的有几种纯流水号直接查数据库前缀区分物料类型GS1应用标识符AI格式比如(01)16901234567896(10)ABC123或者自定义的分隔符格式如MAT|100234|20250610|000123。在PHP里实现解析规则时我建议把正则和字段位置做成数据库可配置的而不是硬编码在代码里。这样供应商换码规则时不需要改代码发版在后台管理里改一条记录就行。// 按配置的正则解析二维码 public function parseCode($rawCode, $rule) { preg_match($rule[pattern], $rawCode, $matches); if (empty($matches)) { return [status invalid, message 不符合码规则]; } return [ status ok, material_code $matches[$rule[material_code_pos]], batch_no $matches[$rule[batch_pos]] ?? null, serial $matches[$rule[serial_pos]] ?? null ]; }正则里的捕获组位置是易错点。比如/^([A-Z])-(\d)-(\d{8})-(\d)$/material_code_pos设为1但如果在正则前加了转义的(?:前缀)非捕获组位置就变了。后台配置时必须提供「测试解析」功能让管理员粘贴一条真实扫码数据立刻看到解析出的字段结果否则改错一个位置号整个产线扫码就会全部提示物料不匹配——这种事故在工厂里出过不止一次。4.2 唯一性范围的设定全局唯一、工单内唯一还是工序内唯一唯一性范围的设定直接决定防重的严格程度这是需要和工厂生产主管坐下来谈的地方。三种常见设定各有适用场景一是全局唯一适用于产品码本身包含序列号且序列号终身唯一的情况比如医疗器械单品追溯。实现最简单对code字段建唯一索引即可。但遇到返修重工、退货重上线的场景就会误伤。二是工单内唯一适用于同一个码不会在两个工单里出现的情况。这里的问题是返修工单和原生产工单如果都扫同一个码就会冲突。解决办法是返修走单独的返修登记流程而不是复用正常生产扫码入口。三是工单工序内唯一适用于生产流程长、一个产品要经过多道工序、每道工序都要扫码确认的情况。这也是我在3.1里选择这个组合的原因。它允许同一码在不同工序重复扫入但同一工序重复扫就会被拦截。缺点是工序ID的管理必须严格不同工序之间不能共用同一个扫码入口页面。在配置唯一性范围时还有一类需要特判周转箱码、托盘码。这些码是循环使用的同一箱码每周都在不同工单里重复出现。如果按工单内唯一去限制第二次使用就会报警。处理方式是把周转箱码和产品码分开管理——周转箱码走单独的登记表不参与产品防重逻辑或者只做状态校验是否已绑定当前工单而不做历史唯一校验。4.3 放行策略与白名单什么时候防错要「让路」防错系统最怕的是「一刀切」——设置太严正常生产被频繁阻断主管烦了直接让人关掉系统设置太松错料上线没人发现。合理的做法是设计分级放行策略并配套人工授权记录。常见策略有三种严格模式默认拦截所有错料、宽松模式非关键工序只提示不拦截、以及白名单放行特定批次、特定供应商不被拦截。// 放行策略按工序和物料类型决定是否强制拦截 public function decidePassOrBlock($parsedCode, $workOrder, $processId) { // 规则查询该工序是否允许物料不匹配时放行 $rule ProcessRule::where([ process_id $processId, material_code $parsedCode[material_code] ])-first(); if ($rule $rule-tolerance_level warn_only) { return [status warn, message 物料不匹配但当前工序允许放行]; } // 白名单理由备注后放行记录操作人 if ($rule $rule-tolerance_level whitelist) { // 记录放行日志必须填写理由 return [status ok, message 白名单放行]; } return [status block, message 物料不匹配已拦截]; }放行策略里最容易被滥用的就是「备注理由后放行」。如果理由是一个自由文本框操作工会图省事输入「ok」「yes」就提交那这个放行记录就失去了追溯价值。我经手的项目里有一种做法值得参考放行理由必须从预设的选项里选比如「已换料」「紧急插单」「供应商批次变更」且选择后系统自动记录操作人工号。这样日后审计时每一笔放行都有明确的原因分类而不是一地鸡毛。4.4 扫码连续性与超时处理重扫、补扫、误扫的边界产线扫码还有个高频问题扫完一个码系统提示成功但操作工发现手里这个产品和当前工单不对想撤销刚才的记录。如果系统没有撤销机制这个错误记录就留在数据库里可能导致整批对账差异。所以在设计时要留一个「作废登记」入口但必须严格控制权限——只有班组长及以上能作废且作废时必须填写原因。另一个边界是「补扫」产品到了最后一道工序前一道工序漏扫了怎么办严格流程是退回上一道工序重新扫但这在物理上经常做不到产品已包装。常见做法是允许在末道工序补扫但补扫会触发一个「前序缺失」告警由主管确认后放行同时记录异常。这个逻辑必须在防错校验里提前写好// 补扫场景允许扫码但提示前序工序缺失 public function checkPreviousProcess($workOrderId, $productSerial, $currentProcessId) { $prevProcessId getPrevProcessId($currentProcessId); $stmt $pdo-prepare( SELECT id FROM scan_record WHERE work_order_id :wo AND code :code AND process_id :prev ); $stmt-execute([:wo$workOrderId, :code$productSerial, :prev$prevProcessId]); $exists $stmt-fetch(); if (!$exists) { return [status missing_prev, message 前序工序未扫码确认是否补扫]; } return [status ok]; }补扫的逻辑一定要放在防错校验之后、插入记录之前并且补扫确认操作要单独再扫一次码或者输入主管密码绝对不能直接点一下「确认」就通过否则会出现流水线上有人专门替人补扫的漏洞。这一节的内容本质上是从「纯技术防重」延伸到「流程防错」后者才是工厂真正离不开系统的原因。5. 上线避坑指南扫码枪识别、并发插入、浏览器兼容的现实问题5.1 扫码枪输入乱码或截断先排查编码和后缀设置扫码枪扫出来乱码常见的表现是中文变成问号、英文字母和数字正常但偶尔少几位、URL里出现%转义错误。大部分情况下问题出在扫码枪的字符编码设置和操作系统的键盘布局不一致。国产扫码枪默认通常是UTF-8但很多工厂老电脑上的Windows系统区域设置为GBK导致PHP接收到的POST数据里中文码的内容错乱。解决方法是先在扫码枪配置里把输出格式设为英文数字禁止扫码枪翻译中文很多码枪默认带中文输入法模拟功能。如果码的内容必须含中文则要统一PHP端和数据库连接的字符集PHP侧header(Content-Type: text/html; charsetutf-8)PDO连接串加utf8mb4MySQL表的字符集也用utf8mb4。最排除法的方式是拿一个普通键盘手动输入同样的码内容如果手动输入正常而扫码乱码基本就是扫码枪的配置问题。5.2 并发插入导致唯一索引报错PHP端要做友好兜底本章开始说的SQL唯一索引兜底在生产环境会带来一个现实问题两个工位几乎同时扫同一个码两个请求都通过了PHP的SELECT查重检查然后先后执行INSERT后执行的那个会触发SQL唯一索引冲突而抛出一个500异常。虽然数据是防住了但操作工看到的是白屏或错误页面这不是好的体验。// 唯一索引冲突的捕获与友好提示 try { $insert-execute([...]); } catch (PDOException $e) { // 23000 是唯一约束冲突的 SQLSTATE 码 if ($e-getCode() 23000) { return [status duplicate, message 该码已被其他工位扫描请确认]; } throw $e; }这个捕获动作是防重系统的最后一道体验保障。它把数据库层面的冷冰冰错误转换成语义明确的提示而且提示里要写明「其他工位」因为在这种并发场景下操作工自己是刚扫的心里觉得不可能重复看到「其他工位」才知道原来别的工位也在扫同一个周转箱。在二维码防重防错领域用户体验的细节直接影响一线操作工对系统的信任度——失败提示越清楚他们越不会绕过系统。5.3 浏览器兼容性工位电脑的浏览器不能想当然工厂一线的工位电脑大概率是老旧的Windows 7或者更老的系统浏览器可能是IE11或者依赖国产浏览器兼容模式很多在Chrome上正常的功能在IE上会翻车。fetch API在IE里完全不支持Promise也没有如果需要兼容这些环境要么把AJAX请求改成XMLHttpRequest要么引入兼容垫片。更省事的做法是让扫码页面彻底抛弃前端框架后端直接用PHP渲染HTML扫码提交用form的常规POST页面跳转返回结果。// 兼容老旧浏览器的XHR提交方式 var xhr new XMLHttpRequest(); xhr.open(POST, /index.php?actionscan_xhr, true); xhr.setRequestHeader(Content-Type, application/x-www-form-urlencoded); xhr.onreadystatechange function() { if (xhr.readyState 4 xhr.status 200) { var data JSON.parse(xhr.responseText); if (data.status success) { document.getElementById(codeInput).value ; } alert(data.message); document.getElementById(codeInput).focus(); } }; xhr.send(code encodeURIComponent(document.getElementById(codeInput).value));是不是觉得alert很粗暴但在这个场景里实用——工位环境嘈杂浏览器弹窗比页面内提示更醒目而且不会因为页面局部样式被误操作隐藏。等以后换新工位电脑了再平滑升级到fetch和页面内消息条。上线前一定要拿着准备部署的电脑实际扫一遍而不是在开发机上用Chrome测完直接推。5.4 时间不同步导致的对账异常服务器和工位时间要校准这个坑非常隐蔽。扫码记录表里的scanned_at用的是MySQL的NOW()也就是数据库服务器的时间。如果服务器时间慢了5分钟而异常记录表里记录的拦截时间用PHP的date(Y-m-d H:i:s)两者来自不同时钟源对账时就会出现「同一笔扫码扫码时间和异常时间倒挂」的诡异数据。更常见的是生产主管拿扫码记录和工位的打卡记录比对发现两套时间对不上。避坑做法是统一时间来源数据库连接建立后执行SET time_zone 08:00PHP侧的时区也设成一致同时在表设计时全部用DATETIME DEFAULT CURRENT_TIMESTAMP由MySQL生成时间不要在PHP里手动拼时间字符串。部署时还要在定时任务里加一个NTP时间同步确保服务器和工位电脑的时钟差控制在1秒以内。这个细节看起来不起眼但工厂对账差一分钟就可能要重新查半天。5.5 防重逻辑在「跨班次」上的误判夜班交班的扫码冲突工厂是倒班制的白班和夜班共用一个数据库。如果防重的唯一性范围是work_order_id process_id code理论上跨班次不会冲突因为工单还是同一个。但有一个容易被忽略的场景白班扫了一半下班夜班接着扫同一个工单的同一批产品如果白班某个码扫过但没扫完夜班操作工重新拿起这个产品再扫一次就会被判定为重复而实际上白班那次可能是误扫后没有撤销记录。这个问题没有完美的自动化解法我在项目里通常采用的做法是增加「班次」维度的宽容策略——同一工单内如果扫码时间距离上一次记录超过12小时允许重扫并将旧记录标记为「疑似误扫」由主管在后台确认。这里的核心思路是防重是工具不是枷锁当业务上存在合理的重复理由时系统要有释放通道否则操作工会用「删除数据库记录」这种更危险的方式来解决问题。6. 进阶把防重防错数据变成管理报表与追溯链闭环防重防错系统一旦稳定运行沉淀下来的扫码数据其实是工厂最宝贵的追溯资产。有一个非常实用的进阶功能是「反查批次」拿着一个成品的二维码一键查出它经历了哪些工序、每道工序的扫码时间、操作工是谁、用的物料批次是什么。这需要把扫码记录表按产品序列号组装成一条追溯链。在PHP里实现时首先按code查出该产品的所有扫码记录然后按process_id排序再关联工单表获取每道工序的名称和操作工信息。// 产品追溯链查询按码反查所有工序记录 public function traceChain($code) { $stmt $pdo-prepare( SELECT sr.code, sr.process_id, sr.scanned_at, sr.scanner, wo.order_no, wo.material_code FROM scan_record sr INNER JOIN work_order wo ON wo.id sr.work_order_id WHERE sr.code :code ORDER BY sr.process_id ASC, sr.scanned_at ASC ); $stmt-execute([:code $code]); $records $stmt-fetchAll(PDO::FETCH_ASSOC); // 检查工序连续性是否存在跳工序 $expectedProcess 1; foreach ($records as $rec) { if ($rec[process_id] ! $expectedProcess) { return [status broken_chain, data $records]; } $expectedProcess; } return [status complete, data $records]; }这里的工序连续性检查是追溯链价值的关键。如果链断了说明产品跳过了某道重要的检验工序这在质量管理体系里是严重不符合项。系统会把这个链状态直接显示在扫码结果页面上——当一个追溯查询返回broken_chain时质量人员就能立刻知道这个产品需要被扣留复核而不是等到出货后客户投诉再追查。另一个值得投入的进阶功能是「产线效率热力图」统计每小时、每个工位的扫码次数和异常拦截率。防错系统天然掌握着产线节拍数据误拦截率高的工序往往意味着物料配套有问题或者操作工培训不到位。这个报表不需要复杂的BI工具PHP后台写一个按小时分组的SQL查询再配合Chart.js的折线图和热力色块就能可视化数据量几千条时性能完全没问题。-- 每小时扫码量与异常量统计用于效率热力图 SELECT DATE_FORMAT(scanned_at, %Y-%m-%d %H:00) AS hour_slot, COUNT(*) AS total_scans, SUM(CASE WHEN sr.code IN ( SELECT code FROM scan_exception WHERE DATE_FORMAT(created_at, %Y-%m-%d %H:00) DATE_FORMAT(scanned_at, %Y-%m-%d %H:00) ) THEN 1 ELSE 0 END) AS exception_count FROM scan_record sr GROUP BY hour_slot ORDER BY hour_slot DESC;这条SQL有个性能隐患子查询里的DATE_FORMAT会导致全表扫描当扫码记录几百条时无所谓但到了几十万条时就会卡。实际优化做法是先按scanned_at范围过滤比如只查某一天再在这个结果集里关联异常记录而不是用函数套字段。这也是贯穿整个二维码防重防错系统设计的一个原则数据和规则都简单但数据量增长后的性能问题必须在架构上提前留出调整空间——把时间字段建立索引、把解析规则和扫码逻辑解耦、把报表查询和事务写入分隔开。我在项目上线三个月后做的最重要一次优化就是把所有报表接口改成了只读从库连接主库专心处理扫码写入那条血泪经验换来了产线大屏在高峰期不再卡顿。希望这些做法对你的二维码防重防错系统落地能派上用场。本文还有配套的精品资源点击获取
简介一套PHP实现的二维码防重防错系统源码包面向需要为业务二维码加入防重复、防错误管理能力的中小企业开发者、企业信息化人员或个人站长。系统覆盖从生成到扫码验证的完整链路首页直接作为扫码功能页使用能按天生成二维码并打印输出有效避免跨日期编号冲突后台可统计二维码总数、当天数量、打印数量和扫码次数方便运营人员掌握发放与使用情况。管理端支持设置二维码前缀18位、默认日打印量、是否附加年月日序号以及序号位数规则灵活安装后先完成基础数据配置即可正常使用。压缩包约5.24MB整体以PHP源码和相关配置为主解压后即可部署调试。目前已有232人参与学习/下载适合需要快速上线二维码防重防错功能并有意在此基础上进行二次开发或集成的开发者。1. 二维码防重防错系统为什么PHP方案依然是工厂流水线的首选在生产车间里二维码贴错、扫重、漏扫带来的损失往往不是一张标签的成本而是一整批产品流向错误、追溯链条断裂的连锁反应。很多团队一上来就想到用手机扫码加Excel记录结果在产线节拍面前完全撑不住扫码枪连点两下就重复记录不同工位的IPQC制程检验各自维护一张表到了出货前对账发现数据对不上只能让人趴在包装线上一箱箱翻。所谓二维码防重防错系统本质上是把「扫一次、验一次、记一次」变成一个不可跳过的闭环码本身要有唯一性校验扫到的码要和当前工单、工序、物料绑定重复扫码直接拦截错扫立刻告警。而PHP在这个场景里被大量选用不是因为它是性能最强的语言而是因为它在中小型工厂里部署成本最低、和现有ERP/进销存系统的对接最省事——一台Windows旧电脑加Apache就能跑起来产线上的扫码枪本身就是一个键盘输入设备页面轮询或WebSocket推送就能实现工位大屏的实时刷新。这套方案的落地难点从来不是PHP本身而是防重逻辑怎么写、防错规则怎么配、数据一致性怎么保证。本文就沿着一条实际可复现的路径把从建表到上线的完整做法拆开来讲。2. 防重防错的底层逻辑先搞清要拦截哪两类脏数据2.1 防重是物理层面的拦截同一码在限定范围内只能成功登记一次二维码防重的核心不是让码本身不可复制而是让同一个码在业务规则限定的范围内只能产生一条有效记录。常见的错误认知是「码唯一就够了」但实际产线里码可能是供应商印的、内部重复打印的、甚至回收周转箱上反复使用的旧码码本身不唯一的情况大量存在。因此防重要同时做两层校验第一层是码格式与校验位检查拦截那些明显不合规的扫描值第二层是业务唯一性检查在登记时按「码 工单号 工序号」或「码 批次号」的组合去查重。// 防重登记核心逻辑先查重再插入全程在同一事务里 public function checkAndRegister($code, $workOrder, $processId) { $pdo-beginTransaction(); try { // 锁定查询避免并发下两条请求同时通过检查 $stmt $pdo-prepare( SELECT id FROM scan_record WHERE code :code AND work_order :wo AND process_id :pid FOR UPDATE ); $stmt-execute([:code$code, :wo$workOrder, :pid$processId]); $exists $stmt-fetch(); if ($exists) { $pdo-rollBack(); return [status duplicate, message 该码在当前工单已扫描过]; } // 插入记录并提交 $insert $pdo-prepare( INSERT INTO scan_record (code, work_order, process_id, scanned_at, scanner) VALUES (:code, :wo, :pid, NOW(), :scanner) ); $insert-execute([:code$code, :wo$workOrder, :pid$processId, :scanner$scanner]); $pdo-commit(); return [status success]; } catch (Exception $e) { $pdo-rollBack(); throw $e; } }这段代码里最关键的是FOR UPDATE行级锁。如果去掉这个锁两个工位同时扫同一个码时两个请求可能都通过SELECT检查然后各自插入一条记录防重就失效了。事务的意义也在于此查重和插入必须是原子的中间任何一步失败都不能留下半条脏数据。生产环境里还要在数据库层面加唯一索引兜底哪怕PHP逻辑出了问题数据库也会拒绝重复插入。-- 数据库层面的兜底唯一索引 ALTER TABLE scan_record ADD UNIQUE INDEX uniq_code_wo_process (code, work_order, process_id);这个唯一索引是防重的最后一道防线。PHP逻辑负责给出友好提示数据库负责强制约束两层缺一不可。如果只依赖PHP查重在高并发或扫码枪连按的情况下总有机会漏过去如果只依赖数据库索引用户看到的就是一条冰冷的SQL报错体验太差。两者配合才能既堵住数据漏洞又给出能直接展示在工位屏上的中文提示。2.2 防错是业务层面的校验码必须匹配工单、物料和工序状态防错和防重是两回事。防重解决的是「同一个码被扫了两遍」防错解决的是「扫进来的码根本不属于当前这单生产任务」。典型的场景是装配线上正在做A型号的产品操作工不小心扫到了旁边B型号的物料码或者仓库送来的原料批次和当前工单要求的批次不一致。防错校验要在扫码登记的瞬间把码的内容解析出来和当前工单的物料编码、工艺路线进行比对。// 防错校验解析码内容并与工单绑定信息比对 public function validateAgainstWorkOrder($rawCode, $workOrderId) { // 假设码规则前缀表示物料编码中间是日期末尾是流水号 // 例如MAT-100234-20250610-000123 $pattern /^([A-Z])-(\d)-(\d{8})-(\d)$/; if (!preg_match($pattern, $rawCode, $m)) { return [status invalid_format, message 二维码格式不符合规则]; } $materialCode $m[1] . - . $m[2]; // MAT-100234 $wo WorkOrder::find($workOrderId); if ($materialCode ! $wo-material_code) { return [ status material_mismatch, message 物料不匹配当前工单要求 . $wo-material_code . 扫入的是 . $materialCode ]; } // 再校验工序状态当前工序是否已经是扫码完成状态 if ($wo-current_process_status completed) { return [status process_closed, message 当前工序已完成禁止补扫]; } return [status ok]; }这里有两个容易踩的坑。第一码规则的正则一定要和实际印刷的码严格对齐很多工厂用的是GS1编码或Code 128解析规则完全不同不能想当然。第二工序状态校验必须放在插入之前有些系统只在界面层做按钮禁用操作工刷新页面或换个入口就能绕过。防错逻辑最忌讳「只挡君子不挡小人」它要挡的是生产现场的随机误操作而不是应对恶意绕过但即便如此所有校验都要在服务端完成前端禁用只是体验优化不是安全边界。2.3 选型理由PHP在这个场景里的边界在哪里聊完逻辑再看选型。PHP做二维码防重防错系统的优势在于中小工厂的IT环境几乎都是Windows Server或干脆就是普通PCPHP的WAMP/LAMP一键部署太成熟了扫码枪模拟键盘输入PHP接收表单提交的延迟在本地网络下是毫秒级完全够用工厂后续要对接用友、金蝶这类ERP时PHP的SOAP和REST客户端库都很成熟。它的边界也很明确如果产线并发超过每秒几十次扫码或者扫码枪要通过TCP/IP直连而非键盘模拟PHP这种传统请求-响应模型就会吃力需要引入队列或换成常驻内存服务。但绝大多数中小工厂的产线节拍是每几分钟才扫一次PHP的性能余量绰绰有余硬上Java或Go反而是给自己找麻烦——没人维护、招人困难、改个页面都要重新编译。3. 从零搭建最小可用系统数据库设计、扫码接入与实时看板3.1 数据库设计四张核心表撑起整套防重防错规则防重防错系统的数据库设计不能只围绕「扫码记录」这一张表来想否则后面加规则、加报表都会被动。我一般会设计四张核心表工单表work_order维护生产任务及其物料、工序状态二维码规则表qr_rule维护每种码的解析正则、物料编码位置、校验逻辑扫码记录表scan_record存储每一次成功登记录入异常记录表scan_exception记录拦截下来的重复码、错码、格式异常码方便后续追溯和产线对账。-- 工单表一个工单对应一个物料编码记录当前所处工序状态 CREATE TABLE work_order ( id INT AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(50) NOT NULL UNIQUE, material_code VARCHAR(50) NOT NULL, current_process_id INT NOT NULL, current_process_status VARCHAR(20) DEFAULT pending, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 二维码规则表不同码制用不同解析规则 CREATE TABLE qr_rule ( id INT AUTO_INCREMENT PRIMARY KEY, rule_name VARCHAR(50) NOT NULL, pattern VARCHAR(255) NOT NULL COMMENT 正则表达式, material_code_pos INT NOT NULL COMMENT 物料代码在第几个捕获组, enabled TINYINT DEFAULT 1 ); -- 扫码记录表防重防错的最终落库 CREATE TABLE scan_record ( id INT AUTO_INCREMENT PRIMARY KEY, code VARCHAR(128) NOT NULL, work_order_id INT NOT NULL, process_id INT NOT NULL, scanned_at DATETIME DEFAULT CURRENT_TIMESTAMP, scanner VARCHAR(50) NOT NULL, UNIQUE KEY uniq_wo_process_code (work_order_id, process_id, code) ); -- 异常记录表拦截动作也要留痕 CREATE TABLE scan_exception ( id INT AUTO_INCREMENT PRIMARY KEY, code VARCHAR(128) NOT NULL, work_order_id INT, reject_type VARCHAR(30) NOT NULL COMMENT duplicate/material_mismatch/invalid_format, reject_message VARCHAR(255) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );扫码记录表里的唯一索引用的是work_order_id process_id code组合而不是单独的code唯一。原因很实际同一个产品码在出厂后可能经过返修重新上线如果按码全局唯一返修流程就永远走不通。组合唯一索引既保证了在同一个工序里码不会被重复扫又给返修、重工留了口子。异常记录表很多人会忽略但它其实是工厂最需要的——生产主管要的不是「你拦了多少」而是「拦下来的都是什么原因」这张表就是给管理看的数据依据。3.2 扫码终端接入把扫码枪变成不需要培训的输入设备扫码枪接入是这套系统里最简单也最容易出问题的环节。市面上绝大多数USB扫码枪默认模拟键盘输入扫一下等于在焦点输入框里快速敲一串字符再加回车所以PHP端只需要一个普通的表单输入框autofocus加上回车提交就够了。这里的关键是输入框的失焦处理如果操作工点了页面其他地方再回来扫码焦点不在输入框里扫码枪敲的字符会丢到页面空白处。!-- 扫码输入框自动聚焦 回车提交禁止手动输入 -- !DOCTYPE html html langzh-CN head meta charsetUTF-8 title产线扫码 - 工位#3/title /head body form idscanForm methodpost action/index.php?actionscan input typetext idcodeInput namecode autofocus autocompleteoff placeholder请扫描二维码 stylefont-size:36px;width:100%;text-align:center;padding:20px; input typehidden namework_order_id value?php echo htmlspecialchars($woId); ? input typehidden nameprocess_id value?php echo htmlspecialchars($processId); ? /form script // 扫码枪输入完成后一般是回车直接提交表单 document.getElementById(codeInput).addEventListener(keydown, function(e) { if (e.key Enter) { e.preventDefault(); this.form.submit(); } }); // 点击页面空白处后点击这个区域重新聚焦扫码框 document.body.addEventListener(click, function() { document.getElementById(codeInput).focus(); }); /script /body /html这个页面的坑在于提交后的页面跳转。如果提交后返回一个「成功」或「失败」的整页响应操作工扫完一个码要等页面刷新完成才能扫下一个在节拍快的产线上就会有人不耐烦地连点提交按钮从而触发防重校验——本来只是网络延迟结果被系统当成重复扫码拦截了。更好的做法是改用AJAX提交页面不跳转扫码框始终保持聚焦成功时清空并提示失败时保留输入框内容并给红色警示音。扫码枪一般能配置后缀字符常见的默认后缀是回车但也有些枪出厂是Tab键如果发现表单提交不了或焦点跳走第一件事就是查扫码枪说明书设置后缀。// AJAX 提交页面不刷新适合快速连续扫码 document.getElementById(scanForm).addEventListener(submit, function(e) { e.preventDefault(); var formData new FormData(this); fetch(/index.php?actionscan_ajax, { method: POST, body: formData }) .then(response response.json()) .then(data { if (data.status success) { document.getElementById(codeInput).value ; showMessage(✅ data.message, success); } else { showMessage(⛔ data.message, error); // 失败时不清空方便用扫码枪重新扫同一个码覆盖 } document.getElementById(codeInput).focus(); }) .catch(err { showMessage(网络错误 err.message, error); document.getElementById(codeInput).focus(); }); });这里失败的场景做了「不清空」处理是产线上很实用的细节。常见的情况是操作工扫了一个错误的码系统弹窗提示物料不匹配然后操作工换了正确的物料重新扫——如果刚才的错误码还留在输入框里新扫的码会覆盖它这没问题但如果系统自动清空了操作工扫到一半发现不对又扫下一个中间的空档期也可能产生误操作。所以保留错误码在输入框中让新扫码自然覆盖比清空更符合实际操作习惯。3.3 工位大屏与后台管理用轮询还是WebSocket工位大屏的本质是「扫码结果的集体可见」。一个车间里可能有十来个工位工位上的小屏要显示当前工单进度车间接上方的电视大屏要显示各工位的产量和异常数。实现方式有两种轮询和WebSocket。PHP原生环境下用轮询更务实——每隔2秒请求一次最新统计数据通过JSON返回前端用setInterval刷新。这种方式在几十个工位的规模下完全够用而且部署简单不需要额外维护常驻进程。真的到了几百个工位、数据要实时汇总的规模再用Workerman或Swoole做WebSocket推送。// 工位大屏轮询接口返回当前工单的统计信息 public function dashboardStats($workOrderId) { $stats $pdo-prepare( SELECT COUNT(*) AS scanned_count, SUM(CASE WHEN process_id :current_process THEN 1 ELSE 0 END) AS process_scanned, (SELECT COUNT(*) FROM scan_record WHERE work_order_id :wo) AS total_scanned FROM scan_record WHERE work_order_id :wo ); // 实际项目里上面的SQL语句会分开写得更清晰这里合并示意 echo json_encode($stats-fetch(PDO::FETCH_ASSOC)); }轮询的间隔不是越小越好。2秒的间隔在大屏上人眼感知不到卡顿但服务器压力是0.5秒间隔的四分之一。扫码枪的录入本身是一次POST请求轮询是若干GET请求两者混在一起时要注意PHP-FPM的进程数上限——如果开了50个PHP-FPM子进程扫码请求被轮询请求占满就会出现扫码页面转圈、大屏却是正常刷新的诡异现象。避坑的方法是给轮询接口单独设置更短的超时时间并且在Nginx层限制这个接口的并发或者直接启用OPcache减少PHP脚本编译开销。4. 参数配置与规则管理正则解析、唯一性范围、放行策略的取舍4.1 二维码解析规则把「一串字符」变成「有意义的业务字段」二维码防错的前提是能从码里解析出业务字段。不同工厂的码规则千差万别常见的有几种纯流水号直接查数据库前缀区分物料类型GS1应用标识符AI格式比如(01)16901234567896(10)ABC123或者自定义的分隔符格式如MAT|100234|20250610|000123。在PHP里实现解析规则时我建议把正则和字段位置做成数据库可配置的而不是硬编码在代码里。这样供应商换码规则时不需要改代码发版在后台管理里改一条记录就行。// 按配置的正则解析二维码 public function parseCode($rawCode, $rule) { preg_match($rule[pattern], $rawCode, $matches); if (empty($matches)) { return [status invalid, message 不符合码规则]; } return [ status ok, material_code $matches[$rule[material_code_pos]], batch_no $matches[$rule[batch_pos]] ?? null, serial $matches[$rule[serial_pos]] ?? null ]; }正则里的捕获组位置是易错点。比如/^([A-Z])-(\d)-(\d{8})-(\d)$/material_code_pos设为1但如果在正则前加了转义的(?:前缀)非捕获组位置就变了。后台配置时必须提供「测试解析」功能让管理员粘贴一条真实扫码数据立刻看到解析出的字段结果否则改错一个位置号整个产线扫码就会全部提示物料不匹配——这种事故在工厂里出过不止一次。4.2 唯一性范围的设定全局唯一、工单内唯一还是工序内唯一唯一性范围的设定直接决定防重的严格程度这是需要和工厂生产主管坐下来谈的地方。三种常见设定各有适用场景一是全局唯一适用于产品码本身包含序列号且序列号终身唯一的情况比如医疗器械单品追溯。实现最简单对code字段建唯一索引即可。但遇到返修重工、退货重上线的场景就会误伤。二是工单内唯一适用于同一个码不会在两个工单里出现的情况。这里的问题是返修工单和原生产工单如果都扫同一个码就会冲突。解决办法是返修走单独的返修登记流程而不是复用正常生产扫码入口。三是工单工序内唯一适用于生产流程长、一个产品要经过多道工序、每道工序都要扫码确认的情况。这也是我在3.1里选择这个组合的原因。它允许同一码在不同工序重复扫入但同一工序重复扫就会被拦截。缺点是工序ID的管理必须严格不同工序之间不能共用同一个扫码入口页面。在配置唯一性范围时还有一类需要特判周转箱码、托盘码。这些码是循环使用的同一箱码每周都在不同工单里重复出现。如果按工单内唯一去限制第二次使用就会报警。处理方式是把周转箱码和产品码分开管理——周转箱码走单独的登记表不参与产品防重逻辑或者只做状态校验是否已绑定当前工单而不做历史唯一校验。4.3 放行策略与白名单什么时候防错要「让路」防错系统最怕的是「一刀切」——设置太严正常生产被频繁阻断主管烦了直接让人关掉系统设置太松错料上线没人发现。合理的做法是设计分级放行策略并配套人工授权记录。常见策略有三种严格模式默认拦截所有错料、宽松模式非关键工序只提示不拦截、以及白名单放行特定批次、特定供应商不被拦截。// 放行策略按工序和物料类型决定是否强制拦截 public function decidePassOrBlock($parsedCode, $workOrder, $processId) { // 规则查询该工序是否允许物料不匹配时放行 $rule ProcessRule::where([ process_id $processId, material_code $parsedCode[material_code] ])-first(); if ($rule $rule-tolerance_level warn_only) { return [status warn, message 物料不匹配但当前工序允许放行]; } // 白名单理由备注后放行记录操作人 if ($rule $rule-tolerance_level whitelist) { // 记录放行日志必须填写理由 return [status ok, message 白名单放行]; } return [status block, message 物料不匹配已拦截]; }放行策略里最容易被滥用的就是「备注理由后放行」。如果理由是一个自由文本框操作工会图省事输入「ok」「yes」就提交那这个放行记录就失去了追溯价值。我经手的项目里有一种做法值得参考放行理由必须从预设的选项里选比如「已换料」「紧急插单」「供应商批次变更」且选择后系统自动记录操作人工号。这样日后审计时每一笔放行都有明确的原因分类而不是一地鸡毛。4.4 扫码连续性与超时处理重扫、补扫、误扫的边界产线扫码还有个高频问题扫完一个码系统提示成功但操作工发现手里这个产品和当前工单不对想撤销刚才的记录。如果系统没有撤销机制这个错误记录就留在数据库里可能导致整批对账差异。所以在设计时要留一个「作废登记」入口但必须严格控制权限——只有班组长及以上能作废且作废时必须填写原因。另一个边界是「补扫」产品到了最后一道工序前一道工序漏扫了怎么办严格流程是退回上一道工序重新扫但这在物理上经常做不到产品已包装。常见做法是允许在末道工序补扫但补扫会触发一个「前序缺失」告警由主管确认后放行同时记录异常。这个逻辑必须在防错校验里提前写好// 补扫场景允许扫码但提示前序工序缺失 public function checkPreviousProcess($workOrderId, $productSerial, $currentProcessId) { $prevProcessId getPrevProcessId($currentProcessId); $stmt $pdo-prepare( SELECT id FROM scan_record WHERE work_order_id :wo AND code :code AND process_id :prev ); $stmt-execute([:wo$workOrderId, :code$productSerial, :prev$prevProcessId]); $exists $stmt-fetch(); if (!$exists) { return [status missing_prev, message 前序工序未扫码确认是否补扫]; } return [status ok]; }补扫的逻辑一定要放在防错校验之后、插入记录之前并且补扫确认操作要单独再扫一次码或者输入主管密码绝对不能直接点一下「确认」就通过否则会出现流水线上有人专门替人补扫的漏洞。这一节的内容本质上是从「纯技术防重」延伸到「流程防错」后者才是工厂真正离不开系统的原因。5. 上线避坑指南扫码枪识别、并发插入、浏览器兼容的现实问题5.1 扫码枪输入乱码或截断先排查编码和后缀设置扫码枪扫出来乱码常见的表现是中文变成问号、英文字母和数字正常但偶尔少几位、URL里出现%转义错误。大部分情况下问题出在扫码枪的字符编码设置和操作系统的键盘布局不一致。国产扫码枪默认通常是UTF-8但很多工厂老电脑上的Windows系统区域设置为GBK导致PHP接收到的POST数据里中文码的内容错乱。解决方法是先在扫码枪配置里把输出格式设为英文数字禁止扫码枪翻译中文很多码枪默认带中文输入法模拟功能。如果码的内容必须含中文则要统一PHP端和数据库连接的字符集PHP侧header(Content-Type: text/html; charsetutf-8)PDO连接串加utf8mb4MySQL表的字符集也用utf8mb4。最排除法的方式是拿一个普通键盘手动输入同样的码内容如果手动输入正常而扫码乱码基本就是扫码枪的配置问题。5.2 并发插入导致唯一索引报错PHP端要做友好兜底本章开始说的SQL唯一索引兜底在生产环境会带来一个现实问题两个工位几乎同时扫同一个码两个请求都通过了PHP的SELECT查重检查然后先后执行INSERT后执行的那个会触发SQL唯一索引冲突而抛出一个500异常。虽然数据是防住了但操作工看到的是白屏或错误页面这不是好的体验。// 唯一索引冲突的捕获与友好提示 try { $insert-execute([...]); } catch (PDOException $e) { // 23000 是唯一约束冲突的 SQLSTATE 码 if ($e-getCode() 23000) { return [status duplicate, message 该码已被其他工位扫描请确认]; } throw $e; }这个捕获动作是防重系统的最后一道体验保障。它把数据库层面的冷冰冰错误转换成语义明确的提示而且提示里要写明「其他工位」因为在这种并发场景下操作工自己是刚扫的心里觉得不可能重复看到「其他工位」才知道原来别的工位也在扫同一个周转箱。在二维码防重防错领域用户体验的细节直接影响一线操作工对系统的信任度——失败提示越清楚他们越不会绕过系统。5.3 浏览器兼容性工位电脑的浏览器不能想当然工厂一线的工位电脑大概率是老旧的Windows 7或者更老的系统浏览器可能是IE11或者依赖国产浏览器兼容模式很多在Chrome上正常的功能在IE上会翻车。fetch API在IE里完全不支持Promise也没有如果需要兼容这些环境要么把AJAX请求改成XMLHttpRequest要么引入兼容垫片。更省事的做法是让扫码页面彻底抛弃前端框架后端直接用PHP渲染HTML扫码提交用form的常规POST页面跳转返回结果。// 兼容老旧浏览器的XHR提交方式 var xhr new XMLHttpRequest(); xhr.open(POST, /index.php?actionscan_xhr, true); xhr.setRequestHeader(Content-Type, application/x-www-form-urlencoded); xhr.onreadystatechange function() { if (xhr.readyState 4 xhr.status 200) { var data JSON.parse(xhr.responseText); if (data.status success) { document.getElementById(codeInput).value ; } alert(data.message); document.getElementById(codeInput).focus(); } }; xhr.send(code encodeURIComponent(document.getElementById(codeInput).value));是不是觉得alert很粗暴但在这个场景里实用——工位环境嘈杂浏览器弹窗比页面内提示更醒目而且不会因为页面局部样式被误操作隐藏。等以后换新工位电脑了再平滑升级到fetch和页面内消息条。上线前一定要拿着准备部署的电脑实际扫一遍而不是在开发机上用Chrome测完直接推。5.4 时间不同步导致的对账异常服务器和工位时间要校准这个坑非常隐蔽。扫码记录表里的scanned_at用的是MySQL的NOW()也就是数据库服务器的时间。如果服务器时间慢了5分钟而异常记录表里记录的拦截时间用PHP的date(Y-m-d H:i:s)两者来自不同时钟源对账时就会出现「同一笔扫码扫码时间和异常时间倒挂」的诡异数据。更常见的是生产主管拿扫码记录和工位的打卡记录比对发现两套时间对不上。避坑做法是统一时间来源数据库连接建立后执行SET time_zone 08:00PHP侧的时区也设成一致同时在表设计时全部用DATETIME DEFAULT CURRENT_TIMESTAMP由MySQL生成时间不要在PHP里手动拼时间字符串。部署时还要在定时任务里加一个NTP时间同步确保服务器和工位电脑的时钟差控制在1秒以内。这个细节看起来不起眼但工厂对账差一分钟就可能要重新查半天。5.5 防重逻辑在「跨班次」上的误判夜班交班的扫码冲突工厂是倒班制的白班和夜班共用一个数据库。如果防重的唯一性范围是work_order_id process_id code理论上跨班次不会冲突因为工单还是同一个。但有一个容易被忽略的场景白班扫了一半下班夜班接着扫同一个工单的同一批产品如果白班某个码扫过但没扫完夜班操作工重新拿起这个产品再扫一次就会被判定为重复而实际上白班那次可能是误扫后没有撤销记录。这个问题没有完美的自动化解法我在项目里通常采用的做法是增加「班次」维度的宽容策略——同一工单内如果扫码时间距离上一次记录超过12小时允许重扫并将旧记录标记为「疑似误扫」由主管在后台确认。这里的核心思路是防重是工具不是枷锁当业务上存在合理的重复理由时系统要有释放通道否则操作工会用「删除数据库记录」这种更危险的方式来解决问题。6. 进阶把防重防错数据变成管理报表与追溯链闭环防重防错系统一旦稳定运行沉淀下来的扫码数据其实是工厂最宝贵的追溯资产。有一个非常实用的进阶功能是「反查批次」拿着一个成品的二维码一键查出它经历了哪些工序、每道工序的扫码时间、操作工是谁、用的物料批次是什么。这需要把扫码记录表按产品序列号组装成一条追溯链。在PHP里实现时首先按code查出该产品的所有扫码记录然后按process_id排序再关联工单表获取每道工序的名称和操作工信息。// 产品追溯链查询按码反查所有工序记录 public function traceChain($code) { $stmt $pdo-prepare( SELECT sr.code, sr.process_id, sr.scanned_at, sr.scanner, wo.order_no, wo.material_code FROM scan_record sr INNER JOIN work_order wo ON wo.id sr.work_order_id WHERE sr.code :code ORDER BY sr.process_id ASC, sr.scanned_at ASC ); $stmt-execute([:code $code]); $records $stmt-fetchAll(PDO::FETCH_ASSOC); // 检查工序连续性是否存在跳工序 $expectedProcess 1; foreach ($records as $rec) { if ($rec[process_id] ! $expectedProcess) { return [status broken_chain, data $records]; } $expectedProcess; } return [status complete, data $records]; }这里的工序连续性检查是追溯链价值的关键。如果链断了说明产品跳过了某道重要的检验工序这在质量管理体系里是严重不符合项。系统会把这个链状态直接显示在扫码结果页面上——当一个追溯查询返回broken_chain时质量人员就能立刻知道这个产品需要被扣留复核而不是等到出货后客户投诉再追查。另一个值得投入的进阶功能是「产线效率热力图」统计每小时、每个工位的扫码次数和异常拦截率。防错系统天然掌握着产线节拍数据误拦截率高的工序往往意味着物料配套有问题或者操作工培训不到位。这个报表不需要复杂的BI工具PHP后台写一个按小时分组的SQL查询再配合Chart.js的折线图和热力色块就能可视化数据量几千条时性能完全没问题。-- 每小时扫码量与异常量统计用于效率热力图 SELECT DATE_FORMAT(scanned_at, %Y-%m-%d %H:00) AS hour_slot, COUNT(*) AS total_scans, SUM(CASE WHEN sr.code IN ( SELECT code FROM scan_exception WHERE DATE_FORMAT(created_at, %Y-%m-%d %H:00) DATE_FORMAT(scanned_at, %Y-%m-%d %H:00) ) THEN 1 ELSE 0 END) AS exception_count FROM scan_record sr GROUP BY hour_slot ORDER BY hour_slot DESC;这条SQL有个性能隐患子查询里的DATE_FORMAT会导致全表扫描当扫码记录几百条时无所谓但到了几十万条时就会卡。实际优化做法是先按scanned_at范围过滤比如只查某一天再在这个结果集里关联异常记录而不是用函数套字段。这也是贯穿整个二维码防重防错系统设计的一个原则数据和规则都简单但数据量增长后的性能问题必须在架构上提前留出调整空间——把时间字段建立索引、把解析规则和扫码逻辑解耦、把报表查询和事务写入分隔开。我在项目上线三个月后做的最重要一次优化就是把所有报表接口改成了只读从库连接主库专心处理扫码写入那条血泪经验换来了产线大屏在高峰期不再卡顿。希望这些做法对你的二维码防重防错系统落地能派上用场。本文还有配套的精品资源点击获取
