简介电子科技大学通信与信息工程学院网络软件设计项目是一项面向计算机专业学生的课程设计资源聚焦网络软件系统开发完整覆盖需求分析、系统设计、编码实现与测试等关键环节适合课程实践或毕业设计参考。压缩包共50个文件约4.99MB包含12个C#源码文件、XAML界面文件、Word/PPT设计文档、配置文件及数据库文件等代码与文档相互对应便于对照学习。已有86人学习浏览。项目中的源代码体现了实际工程的编码风格与模块划分同时附有测试报告、软件设计方案和过程性文档可帮助学习者理解模块化设计、代码复用、版本控制等工程实践。通过阅读和扩展源码读者还能接触网络通信、数据处理和界面交互等真实开发场景对提升系统开发与文档撰写能力均有帮助。1. 网络软件设计课设到底在考什么从协议设计到工程落地我调过多次通信学院的网络软件设计课设项目最典型的一种翻车是界面做得像模像样但传一个 40MB 的文件跑到 60% 就开始乱码。打开工程一看协议字段就一个length data没有帧头标识没有序列号断点续传更是想都没想。这类课程项目表面上是让你写一个“能用的网络软件”实际考的是三件事协议设计是否严谨、并发模型是否经得起压力、异常边界有没有做兜底。这篇笔记就按这个思路把一个常见的文件传输项目从协议定义到实现、再到调试的完整路径拆给你。如果你正在做课设或者刚接触 socket 编程想补网络工程底子这篇能帮你少走至少三周的弯路。2. 先定协议再做界面帧格式、消息类型与状态机很多同学一上来就写server.py和client.py用sendall(bhello)传字符串测通了就以为完事。真正的网络软件设计第一步是画协议图。你需要回答这么几个问题数据到达对端之后怎么知道一个包结束、下一个包开始如果包丢了对方怎么发现如果网络延迟很高连接是否还活着这些问题都由协议来回答。常见做法是自定义一个二进制协议。二进制比 JSON 更适合文件传输因为帧头固定、解析快、没有字符串转义问题。我这里用一个典型设计做例子一个带魔数、版本、类型、序列号、长度的帧头再加上可选的校验字段。2.1 为什么协议要自己定TCP 流边界与粘包拆包TCP 是一个字节流协议它只能保证「发送顺序」和「可靠到达」但不保证你每次recv到的数据就是你send出去的一个完整包。比如你连续发送两个文件块接收方可能在一次recv里同时收到两块也可能一块被拆成几次recv才收全。这就是粘包和拆包。如果不做协议封装你根本无法判断当前 buffer 里的数据到底属于哪个业务包。所以协议的第一个任务是给数据“画格子”。最简单可靠的格子方案是「定长帧头 变长帧体」。帧头里必须有一个长度字段告诉接收方这个帧体有多少字节。接收方先用固定字节数读取帧头解析出长度再循环读取直到收满那么多字节这样就恢复了一个完整的逻辑包。有人问为什么不能用固定长度的帧体比如每块都定成 4096 字节最后一块不够就补零。这样确实能避免长度字段但会浪费带宽而且补零后接收方很难区分「真正的零」和「补的零」。所以「定长头变长体」是工程里最通用的方案。你还要在帧头里加魔数Magic Number和版本号用来快速识别「这是不是我的包」以及在协议演进时做兼容。2.2 帧格式设计魔数、序列号与长度字段我习惯用 Python 的struct模块来定义帧格式因为它可以精确控制字节布局也能方便地在 C/C/Java 之间互相解析。下面是一个 12 字节帧头的定义import struct MAGIC 0x1A2B3C4D VERSION 1 # 帧头结构magic(4) version(1) type(1) seq(2) length(4) 12 字节 HEADER_FORMAT !IBBHI # 网络字节序大端 # 消息类型 MSG_DATA 1 MSG_ACK 2 MSG_FIN 3 MSG_HB 4 # 心跳 def pack_header(msg_type, seq, body_length): return struct.pack(HEADER_FORMAT, MAGIC, VERSION, msg_type, seq, body_length) def unpack_header(header_bytes): magic, version, msg_type, seq, body_length struct.unpack(HEADER_FORMAT, header_bytes) if magic ! MAGIC: raise ValueError(Bad magic: %s % magic) return version, msg_type, seq, body_length上面代码中!IBBHI的含义是!表示网络字节序大端I是 4 字节无符号整数B是 1 字节无符号整数H是 2 字节无符号整数。组合起来正好 4112412 字节。为什么用大端因为 TCP/IP 协议族本身就是大端和系统无关方便排查。seq是序列号用于给每个数据块编号接收方据此检测丢包和重排乱序。length是帧体的字节数不是整帧长度注意计算时别把帧头也算进去这是新手最容易搞混的地方。如果length正好为 0说明这个帧是纯控制帧比如 ACK 或心跳。这个帧头没有加校验字段因为在文件传输场景里数据块的完整性校验我选择放在帧体里——每块数据后面跟一个 4 字节 CRC32或者直接对整个块做 SHA256而不是在帧头加一个对全帧的校验。原因很简单帧头出错会导致长度解析错乱但概率极低而数据内容在传输过程中可能被网卡或内核修改罕见但发生过所以对帧体做校验更有意义。协议设计要遵循“哪个字段错误代价高就给哪个字段更强的保护”。2.3 接收缓冲与状态机从拆包到会话迁移有了帧头定义接收方还需要一个「先收满帧头再按长度收帧体」的循环。这里有一个很经典的坑recv只能保证返回你指定的最大字节数以内但不保证一次性返回完整帧头。所以你要封装一个recv_exact循环读取直到收满指定长度为止def recv_exact(sock, n): 从 socket 中精确读取 n 字节返回 bytes。读取不到完整数据会阻塞。 buf b while len(buf) n: chunk sock.recv(n - len(buf)) if not chunk: raise ConnectionError(socket closed by peer) buf chunk return buf def recv_frame(sock): header recv_exact(sock, 12) version, msg_type, seq, body_length unpack_header(header) body recv_exact(sock, body_length) if body_length 0 else b return msg_type, seq, body这段代码逻辑很简单先精确读 12 字节帧头然后根据长度字段再精确读帧体。如果对端断开recv返回空字节我们立刻抛异常避免死循环。注意recv_exact里的sock.recv(n - len(buf))这个参数是「剩余需要读取的字节数」不是每次都要recv(1024)。否则会多读数据把下一个帧的字节提前读进 buf造成帧错位。接下来我们在这个基础上定义会话状态机。状态机不是纸上谈兵它直接决定你处理异常的逻辑。比如在TRANSFERRING阶段收到对端发来的心跳超时你应该回退到IDLE或者重新握手而不是继续死等。用实际代码表达状态机我一般会定义一个枚举变量并在主循环里用if/elif分支这比引入复杂的状态模式更清晰class SessionState: IDLE 0 SYN_SENT 1 ESTABLISHED 2 TRANSFERRING 3 FIN_SENT 4 CLOSED 5 def on_event(session, event): if session.state SessionState.IDLE and event connect: session.state SessionState.SYN_SENT elif session.state SessionState.SYN_SENT and event ack: session.state SessionState.ESTABLISHED elif session.state SessionState.ESTABLISHED and event start: session.state SessionState.TRANSFERRING # ... 其他迁移这个状态机模型要结合你的协议类型一起写。比如控制消息MSG_FIN只能在TRANSFERRING状态被接受如果在IDLE收到MSG_FIN那要么是包异常要么是会话被重放攻击你应该直接丢弃并记日志。把状态机写清楚后面加断点续传、心跳重连都是在这些状态上补充迁移路径而不是打补丁。有了状态机你还需要定义什么事件触发状态迁移。比如客户端在 ESTABLISHED 状态下发送一个包含文件名的 START 帧服务端返回 START_ACK然后进入 TRANSFERRING。每收到一个数据块服务端发送一个带相同 seq 的 ACK客户端根据 ACK 的 seq 知道下一块该发哪个。这一来一回的“请求-确认”模型是整个可靠传输的核心。3. 把 Socket 用对阻塞/非阻塞、多线程模型与三个关键参数协议画好后实现就进入 socket 编程。很多人的第一版代码是这样的服务端accept一个连接然后在一个while循环里recv客户端发完文件就退出。这个模型只能服务一个客户端第二个客户端来的时候直接卡死。所以你要决定并发模型。3.1 阻塞式多线程 vs 事件驱动课设该用哪种常见的选择有两个一是「阻塞式 socket 每连接一线程」二是「非阻塞 socket epoll 事件循环」。前者代码简单逻辑是线性的每个线程里面可以放心地顺序调用recv_exact、解析协议、返回 ACK不需要关注并发。后者把所有连接的读写事件注册到 epoll 上由单线程统一分发能支撑上万连接但状态机复杂度会翻倍因为你必须把「读到一半的帧」保存到每个连接上下文里不能让事件之间相互覆盖。我的建议是如果这是课程项目选阻塞式多线程就对了。理由有两点第一你会花大量时间在协议调试和边界处理上事件循环会额外引入「半包状态管理」的复杂度这对新手很不友好第二课程验收通常只模拟局域网内的几个并发客户端阻塞式线程完全可以胜任。如果你以后做 C10K 级服务再去补 epoll 那套也不迟。这里有个常见误解Python 因为有 GIL多线程不能利用多核所以网络不用多线程。实际上 socket 的recv和send在等待 IO 时会释放 GIL多线程用于处理并发连接没有问题只是 CPU 密集计算不能并行而已。文件传输场景下瓶颈在网卡和磁盘GIL 的影响可以忽略。模型并发上限代码量调试难度课程项目适用性阻塞 每连接线程数百低低推荐非阻塞 epoll数万高高不推荐3.2 服务端骨架线程池与连接管理器我会用一个连接管理器来统一维护所有活跃连接而不是让 accept 循环直接往线程里抛。这样做的好处是后续要加入断点续传、会话恢复需要按会话 ID 找到对应的连接对象有一个管理器就很顺手。下面是一个极简的实现import socket import threading import struct class SessionManager: def __init__(self): self._sessions {} self._lock threading.Lock() def add(self, session_id, conn): with self._lock: self._sessions[session_id] conn def get(self, session_id): with self._lock: return self._sessions.get(session_id) def remove(self, session_id): with self._lock: self._sessions.pop(session_id, None) def handle_client(conn, addr, manager): session_id addr[1] # 就用端口做 session id实际可以换成握手时协商的 ID manager.add(session_id, conn) try: while True: msg_type, seq, body recv_frame(conn) if msg_type MSG_DATA: # 处理数据块 pass elif msg_type MSG_FIN: send_frame(conn, MSG_ACK, seq, b) break except ConnectionError: pass finally: manager.remove(session_id) conn.close() def server_main(host0.0.0.0, port12000): sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.bind((host, port)) sock.listen(128) manager SessionManager() while True: conn, addr sock.accept() t threading.Thread(targethandle_client, args(conn, addr, manager)) t.daemon True t.start()上面server_main里的listen(128)表示 TCP 三次握手后内核协议栈里最多缓存 128 个未处理的连接超过之后新的连接会被拒绝。这个值不是越大越好它只影响未 accept 的连接排队数真正并发处理靠线程。每个连接一个线程当连接数到几百个时线程切换开销会比较大但课设场景足够。注意handle_client里的recv_frame是我们在第 2 章自定义的精确接收函数这里直接复用。ConnectionError捕获的是对端关闭导致的读取异常你还要捕获TimeoutError如果你给 socket 设置了超时。每个线程在finally里清理连接避免资源泄漏。3.3 必调的三个 Socket 参数NODELAY、REUSEADDR、SNDBUF/RCVBUFsocket 默认参数不是为「小包、高频交互」设计的直接拿来跑文件传输会有几个玄学问题。第一个是 Nagle 算法。为了减少小包数量内核会把小数据包合并到更大包一起发送但代价是额外延迟你发一个 ACK要等 200ms 才被发出去这在交互式协议里会导致每次确认都慢一拍。解决方法是在连接建立后设置TCP_NODELAYsock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)第二个是SO_REUSEADDR。服务器程序调试时经常会 CtrlC 中断然后立刻重启此时端口可能还处于TIME_WAIT状态导致bind失败报Address already in use。在bind之前设置sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)注意这个选项要放到bind前面而且不要在客户端 socket 上设置因为客户端一般不需要主动 bind。第三个是收发缓冲区大小。Linux 默认的SO_SNDBUF/SO_RCVBUF通常是几十 KB 到几百 KB。对于大文件传输调大缓冲区可以减少系统调用次数提升吞吐。但也不要盲目设成几十 MB因为内核实际会翻倍分配也可能超过自动调优的上限。我一般这样设sock.setsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF, 512 * 1024) sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 512 * 1024)设完之后可以用getsockopt读一下实际值你会发现可能比设置值大。这是内核的算法导致的属正常。还有一个应用层保活参数TCP_KEEPALIVE但它的探测间隔默认是 2 小时不适合做会话失效检测。我建议在协议层做心跳每 30 秒发一个MSG_HB如果连续 3 个心跳没有收到回应就认为连接已死。这个比依赖 TCP 保活可靠得多。4. 断点续传与完整性校验偏移量、分块哈希与重传策略协议和并发骨架有了接下来是文件传输本身。很多课设版本的实现是with open(file, rb) as f: sock.sendall(f.read())。这个写法传小文件没问题传一个 2GB 的文本文档读进内存直接吃掉 2GB 内存还不说如果中间断线全部重传。这一章把文件传输拆成可恢复的分块模型。4.1 为什么不能一次 read 整个文件内存与粘包直接f.read()有两个坏处。第一内存峰值等于文件大小服务端和客户端各自同时持有一份完整数据2GB 文件就是 4GB 内存很容易 OOM。第二TCP 层会把一次大 send 拆分成多个 MSS最大段长但对端收到的是连续的字节流你无法知道哪一段属于哪个逻辑块一旦发生丢包重传你也没办法精确定位要重传哪一段。所以要把文件切成固定大小的块。块大小的选择是权衡太小则协议头开销占比高ACK 数量爆炸太大则重传代价高进度更新粗糙。我一般选择 256KB 到 1MB。局域网环境用 512KB 比较平衡这个尺寸下帧头 12 字节的开销可以忽略重传一个块的代价也只在几十 ms 级别。分块的另外一个好处是你能在每块上做独立的完整性校验。发送方在把块送入 socket 之前计算块的哈希接收方每收到一块就校验发现不一致就要求重传这样错误影响被限制在一个块内。4.2 分块与哈希每块独立校验校验字段我放在数据帧的帧体里帧体结构为[offset(8字节)] [payload] [hash(4字节CRC32)]然后整体作为 body 长度算进帧头。当然你也可以把偏移放在帧头但那样帧头会多 8 字节。这里用 CRC32 还是 SHA256如果只是检测传输错误CRC32 就够它只有 2^32 的碰撞空间局域网传输错误概率低如果你要对抗恶意篡改必须用 SHA256。课设场景用 CRC32 更高效但为了展示我也写了 SHA256 的选项。发送一个块的伪代码import zlib import struct CHUNK_SIZE 512 * 1024 def make_data_frame(seq, offset, payload): hash_value zlib.crc32(payload) 0xffffffff body struct.pack(!Q, offset) payload struct.pack(!I, hash_value) header pack_header(MSG_DATA, seq, len(body)) return header body接收方在recv_frame之后从 body 中先取前 8 字节得到offset再取最后 4 字节得到hash_value中间的payload就是文件数据。校验逻辑def parse_data_frame(body): offset struct.unpack(!Q, body[:8])[0] payload body[8:-4] hash_value struct.unpack(!I, body[-4:])[0] if zlib.crc32(payload) 0xffffffff ! hash_value: raise ValueError(CRC mismatch at offset %d % offset) return offset, payload注意这里有一个字节序细节struct.pack(!Q, offset)中的Q是 8 字节无符号整数大端。在 Python 3 里字符串和 bytes 要严格区分不要拿 str 去拼接 payload。很多人在分块拼接时用bytes没问题但一旦把payload转成 str 去计算哈希就会出现「本地运行正常换到 Windows 就翻车」的问题因为默认编码不同。4.3 断点续传服务端记录偏移客户端请求从偏移继续断点续传的核心是「客户端记住自己已经写入了多少字节重连后带着这个偏移去请求」。实现上有两种方案服务端保存会话状态客户端断开后服务端保留已经收到的块序号等客户端重连后告诉服务端「我是上次那个会话」服务端返回当前已确认的偏移。客户端保存本地文件大小重连后客户端直接携带本地文件大小作为偏移服务端从该偏移继续发送。我一般用第二种更简单而且不需要服务端持久化状态。握手时客户端在START帧的帧体里带上offset服务端打开文件后seek(offset)只发送后面的部分。接收方则用上写的模式打开文件把新到的块写到偏移位置最后做一次文件级哈希校验。发送端的核心循环def send_file(conn, fp, offset, file_size): fp.seek(offset) seq offset // CHUNK_SIZE while offset file_size: payload fp.read(CHUNK_SIZE) if not payload: break frame make_data_frame(seq, offset, payload) conn.sendall(frame) # 等待 ACK需要带超时和重试 msg_type, ack_seq, _ recv_frame(conn) if msg_type ! MSG_ACK or ack_seq ! seq: # 没有对应当前 seq按协议应丢弃并继续等待 continue offset len(payload) seq 1这里seq是数据块的序号由于固定块大小seq offset // CHUNK_SIZE。接收方收到块后写入对应偏移并回复该块的 ACK。如果发送方在超时时间内没有收到对应 ACK就重传当前块。这种「发送-等待确认-发送下一块」的方式叫做停等协议效率低但逻辑简单对于课设1MB 块 局域网延迟下也能跑满。如果你希望效率高一些可以把停等改成滑动窗口允许连续发送 N 个块然后累计确认。但滑动窗口的 ACK 处理逻辑复杂度会上升你需要管理未确认块队列、处理乱序 ACK 和超时重传。我的建议是先把停等跑通再考虑扩展。最后一块往往不足CHUNK_SIZE这时不要用fp.read(CHUNK_SIZE)得到空字节作为结束标志而应该用总偏移量判断。接收方写文件时要open(..., rb)并且根据实际接收到的 block 长度 seek 到 offset 写入不能一直 append否则中途重传一个旧块会把文件拉长。还有个常见问题文件在传输过程中被覆盖导致文件大小和 offset 对不上最好在握手时把文件大小、总块数、文件哈希一起发给接收方接收方先删掉临时文件再开始。5. 避坑网络软件设计中最容易翻车的五个常见问题课设项目翻车集中在几个地方不是协议不会写而是细节没处理好。下面这五条几乎是我帮人排查时反复遇到的每一条都按「现象 - 原因 - 解决」给出。5.1 传大文件内存暴涨程序直接卡死现象用 500MB 的文件测试程序内存占用接近 1GB传了几个块后界面无响应最后被系统杀掉。原因发送端把整个文件read()进内存接收端又把所有收到的块 append 进一个bytearray最后一次性写入磁盘。两边各持有一份完整文件加上 Python 对象的额外开销内存直接翻三倍。解决把读写改成边收边写。发送端按CHUNK_SIZE循环读取接收端每收到一个块用seek(offset)定位到文件对应位置用write()写入后马上丢弃这块数据。另外临时文件要放到磁盘有足够空间的分区别放在 tmpfs 或者内存盘。5.2 两次 send 的数据在接收端粘成一个包解析错位现象先发一个文件名帧再发数据帧接收端解析出来的文件名多了几个乱码字符或者直接抛出struct.error: unpack requires a buffer of 12 bytes。原因没有考虑 TCP 流的粘包特性。第一次send的字节和第二次send的字节可能在同一批次到达接收方recv(1024)一次性读到了两个帧的内容而你只按照一个帧去解析导致头部错位。解决所有接收都必须走recv_exact精确读取帧头和帧体而且在解析完一帧后剩余的字节要保留在缓冲区中供下一帧使用。最简单的做法是每次只recv需要的长度不要一次读 1024。如果你的收发循环比较复杂建议在连接对象上维护一个recv_buffer每次recv后先尝试从 buffer 拆帧不够再继续读。5.3 客户端重连后断点续传失效服务端当成新会话现象客户端断网后重连重新发送START帧服务端没有返回已传输的进度而是重新从 0 开始发。之前传的一半数据白传了。原因服务端没有把「已确认偏移」和连接对象解耦。连接断开时服务端线程退出管理器把 session 删掉了偏移信息也随之丢失。客户端重连后是全新的 TCP 连接服务端自然认为它是新会话。解决把断点信息持久化到文件或全局字典并让这次握手带上会话 ID 和文件路径。客户端在重连后先读取本地临时文件的大小作为offset放在START帧的帧体里服务端收到后比较该 offset 和文件实际大小如果 offset 在合法范围内直接seek(offset)并从那里继续。保证事件先写临时文件传完再 rename 成正式文件这样即使中途崩溃临时文件也能用来恢复。5.4 本地跑正常换到虚拟机或另一台电脑就连接失败现象项目在自己的电脑上用127.0.0.1测试一切正常拿到实验室另一台电脑上运行客户端报ConnectionRefusedError或者一直卡在连接超时。原因监听地址写的是127.0.0.1这个 IP 只绑定本地回环外部设备访问不到或者防火墙拦截了监听端口。还有一个很隐蔽的问题两台电脑的 MTU 不同导致某些大数据帧在跨网段时被 IP 分片而你的程序假设一个帧永远不分片。解决服务端监听地址改成0.0.0.0表示监听本机所有 IPv4 地址。同时检查防火墙是否放行对应端口。对于 MTU 分片问题把每个数据块的长度控制在 1400 字节以下可以避免但实际文件传输不会这么小所以更靠谱的做法是不要基于「一次 send 对应一次 recv」的假设来设计协议而是用帧头长度字段来正确拆帧。另外跨设备调试时先用ping确认二层三层通再用一个最简单的 echo 程序验证端口。5.5 校验和总是不匹配查了半天不知道哪错现象发送方计算的 CRC32 和接收方计算的 CRC32 不一样而且每次出错的位置不固定。有时候是文件尾部的块错有时候是中间某块错。原因四个常见来源。一是发送方在构造 frame body 时把 offset 字段写成了文本字符串而不是二进制Q二是接收方取 payload 时用body[8:-4]但 if body 长度不对就会切错三是在分块边界上read(CHUNK_SIZE)返回的长度可能小于CHUNK_SIZE你没有用实际长度更新 offset导致下一个块的 offset 重叠四是网络传输本身出错但你没有做重传只是反复打印校验失败。解决先用本地回环 无丢包环境定位是不是代码问题。在收发双方各打印每一帧的seq、offset、hash_value和payload_len用 hexdump 对比。确认代码没问题后再用tc qdisc或客户端软件模拟丢包测试重传逻辑是否正常工作。记住一个原则任何校验失败都必须触发当前块重传不能直接跳过。6. 最后的进阶用本地回环和虚拟网卡做极限测试以及一个调试技巧到了这一步你的程序在局域网里能跑通了。但离「能被验收方挑不出毛病」还差一步在受控环境中模拟异常。我一般会在自己的电脑上建立两种测试环境一是用回环地址127.0.0.1跑吞吐和正确性二是用 Linux 的netem加延迟和丢包。回环测试有个特点数据不走网卡不会有物理丢包速度极快。它能验证你的协议在「理想信道」下是否自洽比如长时间大文件传输会不会内存泄漏、ACK 处理会不会死锁。如果你在回环下都跑不稳定就不要上真机否则你区分不出是网络问题还是代码问题。要模拟真实的网络质量用tc给回环接口添加延迟和丢包sudo tc qdisc add dev lo root netem delay 20ms loss 1%这条命令让本机回环的每个包都增加 20ms 延迟并按 1% 概率随机丢弃。不要怕丢包正是这些测试能逼出你的重传代码里的 bug。测完记得删掉规则sudo tc qdisc del dev lo root另外抓包是验证协议是否按设计实现的最好方式。用 tcpdump 抓取你定义的端口sudo tcpdump -i lo -XX -s 0 -c 20 port 12000-XX会打印每个包的十六进制和 ASCII你能直接看到帧头里的魔数1a2b3c4d以及长度字段是否和帧体匹配。我自己调试时会写一个hexdump函数在收到每一帧后打印原始字节和协议设计文档对照几分钟就能找到错位。最后说一个我自己的血泪教训第一版课设我为了省事协议里没写版本号和魔数结果把文件内容里的一段二进制误判成了帧头导致整个会话错乱。后来我养成了习惯——先写一页协议文档画好帧布局再去敲键盘。现在的每个网络项目我都会把帧头字节和协议状态机放在代码文件最顶部当注释每次改动都同步更新。希望这个习惯也能帮到你。本文还有配套的精品资源点击获取