企业官网建设流程全解析

简介：一套PHP实现的二维码防重防错系统源码包，面向需要为业务二维码加入防重复、防错误管理能力的中小企业开发者、企业信息化人员或个人站长。系统覆盖从生成到扫码验证的完整链路：首页直接作为扫码功能页使用，能按天生成二维码并打印输出，有效避免跨日期编号冲突；后台可统计二维码总数、当天数量、打印数量和扫码次数，方便运营人员掌握发放与使用情况。管理端支持设置二维码前缀（1～8位）、默认日打印量、是否附加年月日序号以及序号位数，规则灵活，安装后先完成基础数据配置即可正常使用。压缩包约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或干脆就是普通PC，PHP的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 lang="zh-CN"> <head> <meta charset="UTF-8"> <title>产线扫码 - 工位#3</title> </head> <body> <form id="scanForm" method="post" action="/index.php?action=scan"> <input type="text" id="codeInput" name="code" autofocus autocomplete="off" placeholder="请扫描二维码" style="font-size:36px;width:100%;text-align:center;padding:20px;"> <input type="hidden" name="work_order_id" value="<?php echo htmlspecialchars($woId); ?>"> <input type="hidden" name="process_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?action=scan_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; charset=utf-8')，PDO连接串加utf8mb4，MySQL表的字符集也用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?action=scan_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:00'，PHP侧的时区也设成一致，同时在表设计时全部用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范围过滤（比如只查某一天），再在这个结果集里关联异常记录，而不是用函数套字段。这也是贯穿整个二维码防重防错系统设计的一个原则：数据和规则都简单，但数据量增长后的性能问题必须在架构上提前留出调整空间——把时间字段建立索引、把解析规则和扫码逻辑解耦、把报表查询和事务写入分隔开。我在项目上线三个月后做的最重要一次优化，就是把所有报表接口改成了只读从库连接，主库专心处理扫码写入，那条血泪经验换来了产线大屏在高峰期不再卡顿。希望这些做法对你的二维码防重防错系统落地能派上用场。

本文还有配套的精品资源，点击获取