简介：这份资源是面向工业自动化与上位机开发者的扫码枪网口TCP通讯示例工程，针对基恩士扫码枪设计，解决计算机与扫码枪之间稳定数据交互的问题。项目以计算机作为服务端、扫码枪作为客户端，涵盖连接建立、指令下发触发扫码、条码数据回传等流程，并封装了通用的TCP连接管理基类，便于继承扩展数据解析与业务逻辑；异步重连机制可在网络中断后自动恢复连接，提升工业现场通讯的健壮性。压缩包共51个文件，约291KB，以C#源码文件为主，辅以项目工程配置、资源文件及少量可执行与动态库文件，结构完整、可直接运行测试。目前已有3999人学习下载，适合需要快速实现扫码数据实时采集或参考TCP通讯与断线重连实现的开发者借鉴。

1. 扫码枪网口TCP通讯demo：从一根网线到稳定收码的落地实践

产线上新到一批网口扫码枪，插上网线、配好 IP，电脑端却迟迟收不到条码数据——这种场景在仓储、分拣、装配线上太常见了。扫码枪走网口 TCP 通讯，本质是把枪当成一个 TCP 服务端或客户端，上位机连上去后持续读取它推送的条码字符串。这份 demo 及源码要解决的就是这件事：把「扫码枪 → 网线 → 上位机」这条链路跑通，给出可复用的连接、收码、断线重连骨架。适合正在做产线采集、WMS 对接、工位终端的开发者，尤其是第一次接触网口扫码枪、被 IP 和端口绕晕的人。下面按「它是什么 → 怎么跑起来 → 核心代码怎么读 → 怎么改」的顺序拆。

2. 项目定位与技术栈：一个最小可用的 TCP 收码骨架

2.1 这个 demo 到底在做什么

网口扫码枪和 USB 扫码枪最大的区别在于数据出口。USB 枪模拟键盘输入，扫一下等于敲了一串字符；网口枪则把条码通过 TCP 报文发出去，上位机必须主动建立连接、持续监听。这份 demo 的核心工作就三件：建立 TCP 连接、循环读取字节流、把字节流还原成一条条完整条码。它不涉及数据库、不涉及界面美化，是一个纯粹的通讯层样例，方便你直接嵌进自己的采集程序里。

从工程角度看，它更像一块「通讯积木」。真实项目里，你会在它上面加日志、加去重、加业务回调、加断线告警，但底层那套 socket 连接和粘包处理逻辑，基本就是这份源码里的样子。所以读它的正确姿势不是当成成品软件，而是当成一个可以拆开改的起点。

2.2 技术栈与运行环境

源码走的是最朴素的 TCP Socket 路线，没有引入第三方通讯框架。这种选择的理由很实际：扫码枪协议简单，就是纯文本或带结束符的字节流，上 MQTT、上 WebSocket 反而增加部署负担。常见做法是用语言自带的 socket 库直接开干，Windows 下用 .NET 的TcpClient，跨平台或脚本场景用 Python 的socket模块，C++ 则直接调 Winsock 或 POSIX socket。

需要提醒的是，不同品牌扫码枪出厂默认角色不一样。有的枪是 TCP Server，等你来连；有的枪是 TCP Client，配置好目标 IP 后主动往上位机推。demo 里通常两种模式都留了入口，跑之前先翻一眼枪的配置手册，确认它到底是「等连」还是「去连」，这一步搞反了，后面代码再对也收不到数据。

2.3 目录结构与模块划分

一份典型的网口扫码枪 demo 源码，目录不会太深，大致是这么组织的：

scanner-tcp-demo/ ├── config/ # 枪的 IP、端口、结束符配置 │ └── scanner.json ├── src/ │ ├── connection.* # TCP 连接建立与重连 │ ├── receiver.* # 字节流读取与粘包拆分 │ ├── parser.* # 条码解析与校验 │ └── main.* # 启动入口、回调注册 ├── logs/ # 运行日志输出 └── README.md # 配置与运行说明

connection负责 socket 生命周期，receiver负责把 recv 到的碎片拼成完整帧，parser负责去掉结束符、做长度或前缀校验，main把三者串起来并注册「收到一条码」的回调。这种分层的好处是：换枪型只改 config，换解析规则只动 parser，连接逻辑几乎不用碰。二次开发时优先在这三个边界上做扩展，别把业务代码塞进 receiver 里，否则后面粘包一出问题，排查范围会失控。

3. 跑起来：从配置 IP 到收到第一条码

3.1 扫码枪侧的配置要点

动手写代码前，先把枪配明白。网口扫码枪一般通过扫描配置码或配套工具设置网络参数，关键项有四个：IP 地址、子网掩码、端口号、工作模式。IP 要和上位机在同一网段，比如上位机是192.168.1.10，枪配192.168.1.20；端口常见默认9004、5000、8000不等，以手册为准。工作模式选 Server 还是 Client，决定了你代码里是connect还是listen。

配置完先别急着写程序，用系统自带工具验一下链路。Windows 下开命令行 ping 一下枪的 IP，通了说明物理层和网络层没问题；再用 telnet 或 nc 连一下端口，能连上并看到扫码头数据，说明枪已经在正常推流。这一步是血泪经验：很多人代码调半天，最后发现是枪根本没配好或者网线接在错误的网口上。

# 先确认网络可达 ping 192.168.1.20 # 再确认端口在监听（Linux/macOS 用 nc，Windows 可用 telnet） nc -v 192.168.1.20 9004

ping通只代表 IP 层可达，不代表端口开着；nc能连上并打印出扫码内容，才说明 TCP 服务真的在跑。如果nc连不上，回头查枪的模式和端口，别在代码里找原因。

3.2 最小可运行代码：建立连接并收码

下面这段 Python 实现是 demo 里最核心的骨架，负责连上扫码枪并循环读取。选 Python 是因为它把 socket 细节藏得少，读起来直观，换成其他语言逻辑完全一致。

import socket HOST = "192.168.1.20" # 扫码枪 IP PORT = 9004 # 扫码枪监听端口 TERMINATOR = b"\r\n" # 条码结束符，按枪的实际配置改 def run(): # 创建 TCP socket，超时设 5 秒避免永久阻塞 sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(5) sock.connect((HOST, PORT)) print("connected") buffer = b"" while True: try: chunk = sock.recv(1024) # 一次最多读 1024 字节 except socket.timeout: continue # 超时不算错，继续等 if not chunk: print("peer closed") break # 对端关闭，退出循环 buffer += chunk # 按结束符切分，处理一次收到多条或半条的情况 while TERMINATOR in buffer: line, buffer = buffer.split(TERMINATOR, 1) if line: print("barcode:", line.decode("ascii", errors="ignore")) if __name__ == "__main__": run()

逐段说明：socket.socket(AF_INET, SOCK_STREAM)创建的是 IPv4 的 TCP 套接字；settimeout(5)让recv不会无限挂起，产线上偶尔网络抖动时程序还能继续跑；connect是客户端模式，对应枪配成 Server 的情况。循环里recv(1024)的 1024 是单次读取上限，条码通常几十字节，够用；返回空字节串代表对端关闭连接，必须break，否则会死循环空转。

最关键的是buffer那段。TCP 是字节流协议，没有消息边界，一次recv可能拿到半条码，也可能一次拿到三条码拼在一起，这就是常说的粘包。用结束符切分是处理它的标准手法：把新数据追加到缓冲区，只要缓冲区里出现结束符就切一条出来，剩下的留着等下次。split(TERMINATOR, 1)的第二个参数1表示只切一刀，保证一次只取一条，循环直到缓冲区里没有结束符为止。

3.3 换成服务端模式：枪主动来连

如果枪被配成 Client，角色就反过来了，上位机要bind端口并listen，等枪连进来。代码结构变化不大，只是连接建立部分不同：

import socket LISTEN_PORT = 9004 TERMINATOR = b"\r\n" def serve(): server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) # 端口复用，避免重启报占用 server.bind(("0.0.0.0", LISTEN_PORT)) # 监听所有网卡 server.listen(1) print("listening on", LISTEN_PORT) conn, addr = server.accept() # 阻塞等待扫码枪接入 print("scanner connected:", addr) buffer = b"" while True: chunk = conn.recv(1024) if not chunk: break buffer += chunk while TERMINATOR in buffer: line, buffer = buffer.split(TERMINATOR, 1) if line: print("barcode:", line.decode("ascii", errors="ignore")) if __name__ == "__main__": serve()

SO_REUSEADDR这行是踩坑换来的：程序重启时旧连接可能还处于 TIME_WAIT，不加这行bind会报「地址已被占用」。bind(("0.0.0.0", PORT))表示监听本机所有网卡，如果只想收某个网段，可以换成具体 IP。accept()是阻塞的，枪没连进来之前程序停在这里，这是正常行为，不是卡死。实际产线里往往有多把枪，那就把accept放进循环，每来一个连接开一个线程或协程处理，别用单连接硬扛。

4. 核心模块拆解：连接、收码、解析三段链路

4.1 连接管理：断线重连不能省

demo 里最容易被忽略、上线后最容易翻车的就是重连。产线网络不是实验室，交换机重启、枪断电、网线松动都会导致连接断开，如果程序只连一次，断了就彻底哑了。合格的做法是把「连接」包成一个可重试的函数，外层套一个带退避的循环。

import time import socket def connect_with_retry(host, port, max_backoff=30): backoff = 1 while True: try: sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.settimeout(5) sock.connect((host, port)) print("connected to", host, port) return sock except (socket.timeout, ConnectionRefusedError, OSError) as e: print("connect failed:", e, "retry in", backoff, "s") time.sleep(backoff) backoff = min(backoff * 2, max_backoff) # 指数退避，封顶 30 秒

backoff从 1 秒开始翻倍，封顶 30 秒，避免枪长时间离线时程序疯狂重连把日志刷爆。捕获的异常里ConnectionRefusedError表示端口没开，socket.timeout表示网络不通或对端没响应，OSError兜底其他网络错误。返回的sock交给收码循环用，收码循环里一旦recv返回空或抛异常，就跳出重新走这个函数。这套「连接-收码-断开-重连」的闭环，是网口采集程序能长期稳定运行的基础。

4.2 收码与粘包处理：结束符是生命线

粘包处理前面已经露了一手，这里把它讲透。TCP 只保证字节顺序，不保证消息边界，扫码枪连续扫两下，两个条码可能在网络层被合并成一个报文，也可能被拆成两个。判断一条码是否完整的唯一依据，就是枪配置的结束符。常见结束符有\r\n（CRLF）、\r（CR）、\n（LF），也有枪用固定长度或特殊前缀。结束符必须和枪的实际配置严格一致，差一个字节，切分就永远对不上。

def feed(buffer: bytes, chunk: bytes, terminator: bytes): """把新数据喂进缓冲区，返回本次切出的完整条码列表""" buffer += chunk frames = [] while terminator in buffer: line, buffer = buffer.split(terminator, 1) if line: frames.append(line) return buffer, frames

这个feed函数把「追加 + 切分」抽成纯函数，好处是可测试：你可以构造buffer=b"ABC\r\nDE"、chunk=b"F\r\n"，断言切出[b"ABC", b"DEF"]、剩余为空。二次开发时，如果枪的结束符不是标准换行，只改terminator参数即可，切分逻辑不用动。注意if line:这层过滤，是为了丢掉连续结束符产生的空帧，否则业务层会收到空条码。

4.3 解析与业务回调：把字节变成可用数据

切出来的还是字节串，要转成字符串、做校验、再交给业务。解析层通常做三件事：编码转换、去空白、合法性校验。条码一般是 ASCII，但少数场景含中文或特殊字符，编码用ascii加errors="ignore"比较稳，避免一条脏数据把整个循环搞崩。

def parse_frame(raw: bytes) -> str | None: text = raw.decode("ascii", errors="ignore").strip() if not text: return None if len(text) < 4 or len(text) > 128: # 长度兜底，过滤明显异常 return None return text def on_barcode(code: str): # 业务回调：入库、比对、打印，按项目需要替换 print("got barcode:", code)

strip()去掉可能残留的空白，长度区间4~128是经验值，太短可能是噪声，太长可能是粘包没切干净。on_barcode就是业务入口，真实项目里这里会写数据库、发消息、触发分拣动作。把解析和业务分开的意义在于：解析规则变了不影响业务，业务逻辑改了也不碰通讯层，职责清晰，出问题好定位。

5. 避坑与排查：网口扫码枪最常见的五个坑

5.1 现象：程序连上了但一条数据都收不到

原因通常是枪的工作模式配反了。枪配成 Server，你代码也listen，两边都在等对方连，自然没数据。或者枪配成 Client 但目标 IP 填错，连到了别的机器。解决方法是先用nc或 telnet 直连枪的端口，确认枪在主动推流；再核对代码里是connect还是accept，和枪的模式一一对应。这一步别偷懒，模式对不上，代码写得再漂亮也是空转。

5.2 现象：条码被截断，或者两条码粘成一条

原因几乎都是结束符不匹配或粘包没处理。枪发的是\r\n，代码按\n切，切出来的每条都带个\r；或者代码根本没做缓冲区累积，每次recv直接当一条码用，遇到拆包就截断。解决办法是抓一次原始字节流，用十六进制打印出来看结尾到底是什么，再把terminator改成一致的值，并确保走feed那种「累积 + 循环切分」的逻辑，而不是一次recv当一帧。

5.3 现象：程序跑几小时就卡死不再收码

原因是recv没有超时，或者异常没捕获，某次网络抖动后线程永久阻塞。表现是进程还在、CPU 不高、就是不进新数据。解决办法是给 socket 设settimeout，把recv包在try/except里，超时continue、异常跳出重连。另外检查是不是在收码循环里做了耗时操作（比如同步写数据库），把业务处理挪到队列或独立线程，别堵住收码主循环。

5.4 现象：重启程序报「地址已被占用」

原因是用服务端模式时没设端口复用，旧连接处于 TIME_WAIT 状态占着端口。解决办法是在bind之前加setsockopt(SOL_SOCKET, SO_REUSEADDR, 1)。这个坑在调试阶段特别烦，每次改完代码重启都报错，加一行就解决。注意这行要在bind之前调用，顺序错了不生效。

5.5 现象：多把枪接进来后数据串台

原因是服务端只accept了一次，或者多连接共用了同一个buffer变量。每把枪是独立的 TCP 连接，必须各自维护自己的缓冲区和解析状态。解决办法是把「连接 + 缓冲区 + 收码循环」封装成一个连接对象，accept到新连接就新建一个实例丢进线程池。共享缓冲区会导致 A 枪的半条码和 B 枪的数据拼在一起，这种串台在产线上极难排查，一开始就按连接隔离状态最省心。

6. 二次开发：把 demo 改成能上产线的采集服务

拿到这份源码，多数人不会原样用，而是把它嵌进自己的采集系统。改造的第一刀建议切在「配置外置」上：把 IP、端口、结束符、重连间隔从代码里挪到配置文件，换枪型时只改配置不改代码。第二刀切在「状态可观测」：加连接状态、收码计数、最后收码时间这几个指标，产线出问题时一眼能看出是断连还是没扫码。第三刀切在「业务解耦」：收码回调里只做入队，真正的入库、比对、告警交给独立消费者，避免业务慢拖垮通讯。

验证改造是否到位，我一般用三个动作：拔网线看是否自动重连并恢复收码；连续快速扫 100 次看是否有丢码或粘包；模拟枪断电再上电看程序是否无需人工干预。这三关过了，基本能扛住产线日常。下面这个改造后的结构可以作为参考：

class ScannerClient: def __init__(self, host, port, terminator, on_code): self.host, self.port = host, port self.terminator = terminator self.on_code = on_code self.buffer = b"" self.count = 0 def run_forever(self): while True: sock = connect_with_retry(self.host, self.port) try: while True: chunk = sock.recv(1024) if not chunk: break self.buffer, frames = feed(self.buffer, chunk, self.terminator) for raw in frames: code = parse_frame(raw) if code: self.count += 1 self.on_code(code) # 业务回调，建议只入队 except OSError as e: print("recv error:", e) finally: sock.close()

这个类把连接、缓冲、计数、回调收拢在一起，run_forever外层是重连循环，内层是收码循环，finally保证 socket 一定关闭。on_code传进来的是业务函数，通讯层不关心它干什么。多枪场景就 new 多个实例、各跑各的线程，状态天然隔离。

有个细节值得单独说：self.count这类计数别只放内存，产线排查时经常需要知道「今天收了多少码、最后一次是什么时候」，定期落盘或暴露成接口，比事后翻日志快得多。另外结束符如果枪支持配置，尽量在枪侧统一成\r\n，别让不同批次的枪用不同结束符，否则配置管理会变成噩梦。

从那以后我每次接网口扫码枪，都强制先跑一遍nc直连验证枪在推流，再动代码——这个习惯帮我省掉了至少一半「代码没问题但收不到数据」的排查时间。希望帮到你。

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