企业官网建设流程全解析

前阵帮朋友做了一套库存盘点工具，最先解决的问题不是数据库也不是Excel对接，而是怎么把快递单和货架上的条码准确读出来。本来想直接买一把扫码枪，后来发现扫码枪只能当键盘用，遇到屏幕上显示的小码、打印得模糊的物流标签就一肚子火。最后干脆用Python把二维码、条形码解析这整条链路打通了，效果反而比扫码枪稳得多。这篇把我在项目里踩过、试过、优化过的思路完整讲一遍，适合正在做扫码工具、图像识别，或者想给自己的业务流程加自动解析能力的人参考。

现在扫二维码、条形码的应用场景早就铺开了：仓库入库、快递分拣、超市结账、图书管理、门票核销，甚至工厂产线上的物料追溯。很多场景并不是简单“扫一下出个结果”就完事，而是要把扫描结果喂给后台系统进一步处理。这时候用现成的App和扫码枪反而处处别扭，用Python自己写一套解析方案反而是最省事的路径。下面直接进入正题，把这套方案的选型、代码、坑位和落地细节全部掰开讲。

1. 为什么偏要自己写解析逻辑：扫码枪和现成App的短板

很多人一听“解析二维码、条形码”，第一反应是“这还用写？扫码枪不就行了吗”。我自己一开始也这么想，但真上手之后发现，扫码枪和手机App在一些关键场景里根本扛不住。先说清楚它们的局限，你才知道自建方案到底解决了什么问题。

1.1 扫码枪的“键盘模拟”模式局限在哪

市面上绝大多数扫码枪走的是HID键盘协议，插上电脑以后，它扫出来的内容会模拟键盘输入，焦点在哪，字符就往哪跑。听起来很方便，实际用起来有几个很头疼的问题：

• 联动逻辑没法做。扫码枪只是“输入工具”，它不知道这一扫代表“出库”“入库”还是“盘点”，真要做业务联动，还得靠额外的脚本监听键盘事件，解析前缀后缀来区分指令。
• 屏幕码扫不了。那种电脑或手机屏幕上显示得比较小的码，普通扫码枪经常扫不出来，尤其是低端枪，对高分辨率屏幕上的码几乎无解。
• 模糊条码完全看运气。打印质量差的面单，或者被水渍蹭过的标签，扫码枪十次有七次没反应，剩下三次出的可能还是错码。
• 批量场景根本没法做。一次要识别几十张图片里的条码，扫码枪得一张张对着扫，效率和人工录入差不了多少。

扫码枪只适合“有操作员、一次一台、码干净清楚”的传统结账场景。一旦你面对的是自动化、批量化、图片分析这类需求，它的短板就是致命的。

1.2 手机App在批量场景下根本忙不过来

手机端扫码App的问题是没法定制。扫码、核验、联动库存、导出结果这些功能，App大多不开放。就算用现成的扫码框架二次开发，也绕不开手机摄像头本身的两大问题：一是后台不能稳定连续扫码，二是不同机型摄像头自动对焦策略差异大，同一张码在某些手机上就是识别慢。

而且，你自己写Python方案的时候，可以自由控制预处理参数、扩展解码类型、对接业务数据库，甚至把解码逻辑嵌入到一个更大的图像处理管道里。手机App把所有逻辑封死在界面层，你想做二次处理就非常被动。

1.3 自建解析管线的真正优势：可调试、可批量、可自动化

用Python建扫码解析管线，真正的价值在于三点：

1. 可调试：哪张图解析失败，失败的原因是什么（模糊、反光、倾斜、码型不支持），每一步都能打印出来分析。扫码枪只给你一个“哔”或不响的结果，不告诉你为什么。
2. 可批量：1000张面单图片甩进去，脚本后台跑，几十秒出结果，还能按目录输出识别失败的清单。这在仓库批量盘点、快递分拣复核、票据归档这些场景里太实用了。
3. 可自动化：解析代码可以作为一个函数库嵌入任何业务系统，也可以包装成命令行工具或HTTP服务，让ERP、WMS直接调用。扫码枪做不到这个级别的集成。

所以，如果你只是柜台结账偶尔扫两下，扫码枪确实够用；但只要涉及图片分析、批量识别、系统集成，用Python自建解析管线是唯一能同时兼顾灵活性和稳定性的选择。

2. 主流的四条解析路线：pyzbar、OpenCV、zxing-cpp、quirc怎么选

确定自建之后，第一个要解决的问题就是库的选型。市面上打着“Python扫码”旗号的东西不少，但真正核心的没有几个。我实际对比过四条路线，各有脾气，不能只看README就上手。

2.1 四者的核心机制差异

pyzbar是对开源库ZBar的Python封装。ZBar在Linux生态里很有名，扫码枪方案里经常拿它做后台识别引擎。pyzbar的好处是API极其简单：喂一张图片，解出码来就是数组，没解出来就是空。它对一维码的支持比较齐全，EAN-13、UPC-A、Code128、Code39、ITF这些主流类型都能认。弱点也很明显：二维码遇到高版本、密集、残缺的情况，经常解不出；对经过透视变形的码，处理能力也比较弱。

OpenCV并不是专门的条码识别库，但它从4.x版本开始内置了cv2.QRCodeDetector，能直接检测和解码二维码。好处是OpenCV你大概率已经装了，而且它自带的图像预处理能力（灰度化、滤波、阈值、形态学）本身就是扫码识别的前置步骤，整合起来非常顺。缺点是它对条形码（一维码）没有内置解码能力，你最多用cv2.barcode模块（部分版本才带）辅助检测。

zxing-cpp是Java版ZXing库的C++移植版，后来有了Python绑定（zxingcpp）。ZXing家族在条码解码界的口碑一向很好，对模糊、畸变、破损码的鲁棒性明显强于ZBar。尤其二维码解码这块，zxing-cpp比pyzbar要高一个档次。缺陷是安装包比较大，部分精简版Linux环境装起来稍微麻烦，而且官方示例偏少，很多参数需要自己翻源码。

quirc是个轻量级二维码识别库，专为嵌入式场景设计。Python里有个合格的第三方封装，识别速度非常快，但它基本只认二维码，一维码支持约等于零。普通桌面场景用它有点大材小用，更适合跑在树莓派、板卡这类资源受限的设备上。

2.2 用一张对比表看清楚各自的定位

2.3 我的选型结论和组合方案

我最后采用的是pyzbar + zxing-cpp 双引擎组合：先拿pyzbar跑一维码（它对这个太熟了），再用zxing-cpp兜底解码失败的二维码和其他复杂场景。OpenCV只用来做图像预处理和实时显示的容器，不承担最终解码任务。这样既发挥各家所长，又避免单纯押注一个库导致某些码型直接没辙。

这套组合在我的实测里，二维码解码成功率比单独用pyzbar提升了差不多20个百分点，尤其是在处理被折过角的物流面单和低对比度打印码时，提升非常明显。

3. 静态图片解析：预处理做对了，识别率才谈得上

很多人拿到一张图片直接丢给解码库，发现经常解不出来，就觉得是库不行。其实大部分失败都死在预处理上。解码库不是人眼，它对图像质量极端敏感，而打印模糊、光照不均、背景杂乱这些物理世界的问题，必须靠预处理先解决。

3.1 从一张模糊的物流面单说起

我调试时经常用一张真实的快递面单图片：深灰底、小五号字、条码区域还有一层塑料反光。直接丢给pyzbar，结果返回空。后来我把预处理流程加上去，同一个库，三行代码的解码结果就出来了。问题不在库，而在“喂进去的图像根本不适合解码库的胃口”。

解码库内部其实在找“模块的边界”和“黑白切换的序列”。如果图像噪声太多、对比度太低、目标码区域又小，算法很难找到稳定的边界，自然就解码失败。预处理的目标就是把图像调整到“黑白边界清晰、目标区域放得足够大、背景噪声被压下去”的状态。

3.2 预处理管线的每一步都有目的

我常用的预处理管线分这几步，每一步都有明确指向：

• 灰度化：扔掉彩色信息，减少干扰。解码只关心明暗变化，彩色信息除了增加运算量没别的用处。
• 高斯滤波：平滑掉打印喷墨带来的噪点。这里要注意别把条码的边界也磨花了，所以我一般用3x3或5x5的小核。
• 对比度增强：用cv2.createCLAHE做自适应直方图均衡化，把暗背景上的浅色条码拉出来。
• 二值化：这一步争议比较大，因为条码是黑白的，理论上二值化之后边界更清晰，但很多解码库内部本来就做二值化，你再做一次可能反而误伤。我的做法是：先尝试原图直解，失败之后再做二值化再解一次，不在一棵树上吊死。
• 缩放与裁切：如果图片里码太小，直接放大2～3倍再解；如果图片太大，码又居中，先裁切出中心区域，减少解码器扫描的面积。

3.3 分辨率与缩放：太大会丢码，太小会瞎眼

这里有个容易被忽略的细节：图片分辨率过高，解码器默认的扫描窗口反而可能漏掉小码。它为了控制运算量，通常会限制扫描步长，码太小会被当作噪声跳过。所以你要是拿一张单反拍的高清大图，直接丢进去，识别率可能还不如一张缩放到1000像素宽度的图。

反过来，码太小也是常见的失败原因。我一般先看一下最大轮廓的外接框尺寸，如果二维码的边长小于120像素、一维码的宽度小于300像素，就先对区域做放大再解码。

3.4 完整代码演示：从图片到解码结果

下面这段代码是我静态解析模块的缩略版本，真正能用，直接改文件路径就能跑：

import cv2 import numpy as np from pyzbar import pyzbar import zxingcpp def decode_image(path): img = cv2.imread(path) if img is None: return [] # 先尝试彩色直解 results = try_decode(img) if results: return results # 再走预处理管线 gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) gray = cv2.GaussianBlur(gray, (5, 5), 0) clahe = cv2.createCLAHE(clipLimit=2.0, tileGridSize=(8, 8)) gray = clahe.apply(gray) results = try_decode(gray) if results: return results # 最后尝试二值化版本 binary = cv2.adaptiveThreshold(gray, 255, cv2.ADAPTIVE_THRESH_GAUSSIAN_C, cv2.THRESH_BINARY, 31, 7) return try_decode(binary) def try_decode(img): # 统一转成灰度再分别喂给两个库 if len(img.shape) == 3: gray = cv2.cvtColor(img, cv2.COLOR_BGR2GRAY) else: gray = img output = [] for res in pyzbar.decode(gray): output.append({ "type": "barcode", "data": res.data.decode("utf-8", errors="replace"), "kind": res.type }) zx_res = zxingcpp.read_barcodes(gray) for zr in zx_res: output.append({ "type": "barcode", "data": zr.text, "kind": str(zr.format) }) return output

这个函数对大多数日常图片的识别率已经不错，但要注意一个细节：zxingcpp.read_barcodes返回对象自带position信息，如果你要做画框显示，可以取出四个角点坐标，比pyzbar的rect更贴合码的真实轮廓。我的建议是优先用zxingcpp的坐标做可视化，它的定位更准。

4. 摄像头实时扫码：取流、解码、事件响应的完整链路

静态图片解析只是第一步。很多业务场景需要的是“拿着设备对准码，实时出结果”，这时候就要处理摄像头取流和实时解码的问题。实时扫码的复杂度比静态图高一个量级，不只是跑一个解码函数那么简单。

4.1 摄像头参数和取流帧率怎么权衡

摄像头取流时，最容易踩的坑是分辨率设置过高。默认cv2.VideoCapture(0)的分辨率可能是1280x720，识别一张720P的图，单次解码大概需要30到80毫秒，听着不慢，但叠加取流、显示、业务逻辑之后，帧率就掉到个位数。更稳的做法是把分辨率压到640x480，甚至320x240，对扫码来说完全够用，反而因为像素少，解码速度更快。

关键参数这么设：

cap = cv2.VideoCapture(0, cv2.CAP_DSHOW) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) cap.set(cv2.CAP_PROP_FPS, 30) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) # 减小缓冲延迟

CAP_PROP_BUFFERSIZE设成1很关键。默认情况下摄像头会缓存几帧，结果你取到的frame永远是几百毫秒前的画面，手都停稳了，识别框里还在晃。把这个值压到1以后，延迟明显降低，扫码体验会灵动很多。

4.2 单线程会卡，多线程也要控制节拍

实时扫码最忌讳在主循环里同步做解码。取流、解码、画框、显示如果全挤在同一线程，解码一慢，整个预览就开始卡顿，严重影响操作员对准目标码的手感。正确方案是生产者-消费者模型：主线程负责取流和显示，解码线程负责从队列里拿帧跑识别。

但这里有个思路一定要纠正：解码线程不是越快越好。如果解码线程跑得太快，它会把大量CPU花在“重复识别同一帧”上，而且同一帧连续解出多次，业务逻辑会被刷屏触发。我处理的办法是加节拍控制：解码线程每次取到帧后，如果距离上次处理不到0.15秒就丢弃当前帧。这样既能保证实时性，又不会把资源浪费在无意义的重复扫描上。

4.3 把识别结果叠加到视频帧上的实战写法

下面是一段精简但完整可用的实时扫码代码，包含取流、解码线程、结果去重和画面叠加：

import threading import queue import cv2 import numpy as np from pyzbar import pyzbar import zxingcpp frame_queue = queue.Queue(maxsize=2) result_queue = queue.Queue() def decode_worker(): while True: frame = frame_queue.get() if frame is None: break gray = cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) detected = [] for res in pyzbar.decode(gray): detected.append((res.type, res.data.decode("utf-8", "ignore"), res.rect)) for zr in zxingcpp.read_barcodes(gray): pts = zr.position detected.append((str(zr.format), zr.text, pts)) if detected: result_queue.put(detected) threading.Thread(target=decode_worker, daemon=True).start() cap = cv2.VideoCapture(0, cv2.CAP_DSHOW) cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) last_show = None while True: ret, frame = cap.read() if not ret: break if frame_queue.qsize() < 2: frame_queue.put(frame.copy()) # 展示最新的识别结果，避免频繁刷新闪屏 if not result_queue.empty(): last_show = result_queue.get() if last_show: for kind, data, pos in last_show: if isinstance(pos, tuple): x, y, w, h = pos cv2.rectangle(frame, (x, y), (x + w, y + h), (0, 255, 0), 2) cv2.putText(frame, data, (x, y - 8), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 255, 0), 2) else: pts = np.array(pos, dtype=np.int32).reshape((-1, 1, 2)) cv2.polylines(frame, [pts], True, (255, 0, 0), 2) cv2.imshow("scan", frame) if cv2.waitKey(1) & 0xFF == ord("q"): break

这套结构最大的特点是取流和解码完全解耦，即使某一次解码卡了100毫秒，预览画面也不会卡顿，只有识别框稍微慢半拍更新。手感和商用扫码App已经很接近了。

5. 常见翻车现场：这些条码类型和场景最容易解析失败

如果你直接拿上面的代码去跑各种复杂码，肯定会遇到一批解不出来的情况。这里重点讲讲我在实际项目中总结出的翻车因素，每一条都是踩过的。

5.1 一维码绝不是“一横条”，类型区分很关键

一维码不是一个笼统的“条”，它内部有大量细分类型：EAN-13、EAN-8、UPC-A、Code128、Code39、Codebar、ITF-14等等。每个类型的编码规则、校验方式、模块宽度都不一样。pyzbar对不同类型一维码的支持度不同，其中Code128和EAN-13识别率最高，Code39其次，ITF-14这种条码如果模块间隙比较大，识别率就会明显下降。

更麻烦的是，同一条码可能被不同解码库识别成不同内容。这个在Code128里尤其常见，因为Code128有三种字符集（A/B/C），解码库如果字符集判定错了，解出来的字符串会差之千里。我的经验是：关键业务场景，同一个码要让两个解码库都识别一次，结果一致才认为是可信的。

5.2 反光、模糊、倾斜、形变：物理世界的解析难题

这些物理因素统称“图像噪声”，每一种对应不同的预处理策略：

• 反光：塑料面单和覆膜标签的高光区域，会把码的局部变成一片白板。应对方法是调整二值化阈值，或者对高光区域做局部直方图均衡化。我用CLAHE之后，反光区域的解码成功率能提升一半以上。
• 倾斜：码贴在圆柱包装上，或者拍摄角度太斜，会产生透视形变。pyzbar对倾斜30度以上的码几乎没辙，先做透视校正能救回来一部分。不过透视校正需要先找到四个角点，本身也是个检测任务，我一般只在确认码是大面积居中的情况下去做。
• 模糊：失焦和运动模糊通常是叠加出现的，先用拉普拉斯算子检测一下图像的清晰度，如果模糊严重就先拒绝识别，而不是硬解。因为硬解不仅慢，还可能解出错误内容。

5.3 多码共存和伪码干扰：优先级机制必须有

一个画面里有多个码是常态，尤其是快递包裹的标签上可能同时有：快递单号一维码、二维码、商品SKU条码，甚至操作员手写的追踪码。解码库默认会把画面里所有能识别的码全部返回，但业务上往往只需要其中一个。

我在项目里的做法是给它一个优先级白名单，比如仓库场景优先取ITF-14，因为它是物流箱体的标准标识；如果画面里没有ITF-14，再取Code128。另一个反直觉的经验是：伪码问题比多码共存更头疼。所谓伪码，就是广告图片里的装饰性条码、低仿真的假二维码，解码库会一本正经地解出一串毫无意义的数据。这类情况过滤的唯一方法是反向校验——按条码类型的结构规则重新算一遍，结果对不上就丢弃。

5.4 校验位利用：先算一遍，能过滤掉一半的脏数据

大部分一维码类型（EAN、UPC、ITF）和二维码内部都带校验机制，但解码库在解出内容之后，并不会验证校验位是否真的合法。它可以解出一串满足编码物理形态但没有通过校验位计算的字符串，这在图像破损、脏污时非常常见。

我写了一个校验位检查函数，在解码结果进入业务系统前先筛一遍。以EAN-13为例，它的校验算法是：奇数位乘以1，偶数位乘以3，累加求和对10取模，如果余数不为0，说明数据有问题。下面这个函数可以直接拿去用：

def check_ean13(code): if len(code) != 13 or not code.isdigit(): return False s = sum(int(code[i]) * (1 if i % 2 == 0 else 3) for i in range(12)) return (10 - s % 10) % 10 == int(code[12])

把这个校验函数套在解码结果上，我大概过滤掉了20%的背景伪码和花屏误识别数据。这类过滤动作极其划算，因为错误数据进到后续系统里，比识别不出来更致命。

6. 批量处理千张图片：吞吐量和稳定性一起抓

静态解析、实时解码都跑通之后，另一个高频需求浮出水面：给一个文件夹里几千张图片，把里面的条码全部提取出来。批量处理的思路和单张处理完全不同，重点是吞吐量和稳定性。

6.1 多进程还是多线程？结论很明确

很多人条件反射地想到多线程，这是错的。Python的GIL决定了多线程在执行纯CPU密集的解码任务时，不仅不加速反而可能变慢。解码是纯粹的CPU计算，没有多少I/O等待，所以必须用多进程。multiprocessing.Pool是这里最合适的选择。

大体流程是：读取所有图片路径，平均分给N个进程，每个进程独立解码，结果汇总回主进程。进程数不必贪多，一般取CPU核心数减1或减2，留出系统余量。我实测在8核机器上跑6个进程，处理1000张720P图片的速度比单进程快了接近五倍，基本做到每张图同时处理。

一个细节是：进程池的初始化不要写在每张图的任务里。解码库的初始化是有开销的，每个子进程启动时先做一次加载，后续解码就省了导入时间。我通常用initializer参数把库导入和必要的全局对象初始化好。

6.2 失败图片单独留档，而不是原地重试

批量处理里最忌讳“发现识别失败就重试三遍”。重试只会浪费CPU，不会提高成功率——失败图片的失败原因往往是物理性的（反光、模糊、码残缺），不是运气问题。正确处理是：识别失败就把它记录下来，单独放到一个unrecognized/文件夹里，同时写一个CSV日志，注明失败原因（模糊、未检测到、校验失败等）。

这样做最大的好处是有一个质量反馈闭环：你观察那一堆失败图片，会发现它们有共同特征，要么是某个打印机打印出的码对比度不够，要么是某个供应商提供的标签用了劣质纸张。定位到根因之后，你甚至不需要优化算法，只需要协调业务方改善打印质量，识别率就直接上去了。

6.3 批量导出Excel和JSON的落地做法

批量处理的最终结果需要落到业务系统里。我的导出逻辑分两层：

1. 原始结果层：存JSON，每张图片的路径、解码时间、码类型、码内容、置信度（如果有）、坐标信息全部记录。这一层用于debug和后续算法迭代。
2. 业务层：转成Excel，按业务字段组织，比如“箱号、SKU、数量、时间”。这一层直接对接库存、订单、财务系统。

用pandas把JSON转成DataFrame，再to_excel导出非常顺畅。这里唯一值得提醒的是：Excel的单元格长度默认只有255个字符，二维码内容如果包含长字符串或特殊字符，导出时会被截断或者报错。我一般会在导出前对列设置一下max_col_width，或者直接用CSV保存原始结果，Excel只放人看的汇总信息。

7. 把解析能力接到业务里去：几个可以直接抄作业的集成方式

解析代码本身写得再漂亮，不落地到业务里就是玩具。最后分享一下集成到业务系统里的几种常见方式，都是我实际用过的套路。

7.1 做成命令行工具，一条命令解析一张图

最轻量的集成方式就是把解码管线封装成命令行工具，让运维、质检甚至操作员都能用：

python scan.py --image /path/to/file.png --format json

实现上就是argparse加上一个主函数，把第3章的解码逻辑复用过来。命令行工具有一个额外的好处：可以被定时任务调度。比如每天凌晨2点自动扫描某个目录下的新增图片，把识别结果落库，等到早上业务员来上班，报表已经生成好了。

7.2 本地HTTP接口：让其他系统直接调用

如果多个系统都要用扫码能力，做成HTTP接口是最贴合实际的选择。用Flask或FastAPI起一个本地服务，接收图片文件，返回解析结果。业务系统只要会发HTTP请求，就能调用扫码能力，不用关心底层库怎么装、Python环境怎么配。

接口设计上，强烈建议返回结构化JSON：

{ "success": true, "results": [ {"type": "qrcode", "format": "QRCode", "content": "SN-2024-8891", "position": [...]} ] }

我在实际部署时还加了一层简单的身份鉴权，避免局域网内其他服务随便调用。这个接口用uvicorn部署非常稳，起一个后台进程，整个部门就能共享扫码能力，不需要每个终端都装Python环境。

7.3 一个打印预处理环节：识别率低时先想打印，别先想算法

最后聊一个反直觉的经验：在实际业务里遇到的识别率问题，一半以上不是算法问题，而是打印问题。很多条码是用针式打印机或者热敏打印机打出来的，如果打印浓度设得太低，码的黑色模块发灰，背景纸又发黄，对比度一塌糊涂，什么解码库来了都白搭。

我在某个场景里排查了很久，最后发现打印机驱动默认把浓度设成了“省墨模式”。把打印浓度调到最高、关掉省墨之后，一批原来识别率只有60%的标签，抬到了95%以上。所以如果你在业务里发现识别率低，先拿一张原图用Photoshop看一眼灰度直方图：如果黑白的灰度值拉不开差距，那就是打印侧的问题，别在算法上死磕。

另一个类似的建议是：打印前在条码周围留白至少3毫米，很多打印机边缘墨迹不充分，码在边缘就会花掉。标签纸的尺寸如果太小，条码没有足够安静区，解码器就找不到码的起始位置。这类问题靠换更大规格的标签纸就能解决，比调任何算法参数都直接。

我在实际使用中最大的体会是：Python解析二维码、条形码这套方案，难点从来不在解码库本身，而在从“物理世界的图像”到“解码器能理解的图”之间的那一段预处理和业务适配。把预处理、校验、过滤、集成这些问题一个个理顺之后，解码库倒是成了最省心的环节。

最后再分享一个小技巧：所有解码结果在进入正式业务系统前，一定要保留原始图片的路径和时间戳，哪怕只是存在本地一个目录里。遇到客户反馈“我扫出来的东西不对”时，你能在十秒内调出原始图确认是解码错误还是源头编码错误，这个能力在排查问题时能省下大量沟通成本。扫码解析这件事，看起来是小功能，真正工程化之后，润物细无声地解决的是业务流程里最容易出错、最费人力的一环。