★ FEATURED ARTICLE 前段时间把一个用 Python 写的客户端脚本交出去逻辑本身没什么问题命令行里跑得好好的结果对方第一句话是“这东西怎么点”。那一刻我才意识到前几篇里折腾的 socket 连接、数据收发、协议解析对一个不写代码的人来说等于不存在——他没有终端也不打算学怎么敲参数。问题不在功能在于入口。这篇就聊聊 Python 因特网客户端编程里绕不过去的一层GUIGraphical User Interface图形用户界面。GUI 这三个字母拆开看很朴素就是让程序有窗口、有按钮、有输入框能被人用鼠标操作。但放到网络客户端这个场景里它要解决的事情比“好看”复杂得多网络是异步的、不确定的、随时可能卡住的而界面是同步的、要即时响应的。这两件事天生别扭。下面我会从“为什么非要有界面”讲到工具选型再落到一个真能跑的 TCP 客户端界面上中间把主线程阻塞、跨线程更新控件这些必踩的坑一个个拆开。1. 命令行跑通之后再套界面网络客户端为什么绕不开 GUI1.1 从“能用”到“有人愿意用”的分水岭我见过太多半途而废的小工具功能其实已经齐了连接能建立、数据能收发、异常也能打印出来但最终只活在自己的电脑里。原因很统一它的使用方式是“打开终端记住参数顺序敲一行命令看一屏滚动的文本”。写代码的人觉得这很高效不写代码的人觉得这不可理喻。GUI 在这一层起的作用本质是把参数变成控件把输出变成可读的区域。主机地址从一个命令行参数变成输入框端口从一个数字变成另一个输入框连接和断开从两条不同的命令变成同一个按钮的两种状态返回的数据从标准输出变成一块可滚动、可复制、带时间戳的文本区。功能一行没多加但可用性完全不是一个量级。这件事在网络客户端上尤其明显。网络客户端有一个特点它的状态是持续变化的。刚打开时是“未连接”点了连接之后是“连接中”连上了是“已连接”对端断开是“已断开”出错是“连接失败”。命令行程序表达状态的方式只有一种——打印一行字然后结束进程。而界面上这个状态可以直接体现在按钮文字、颜色、是否可点击上用户不用读日志就知道现在能不能发数据。这就是 GUI 在客户端场景里最朴素也最核心的价值。1.2 GUI 在这一层解决了哪几件具体的事把范围收窄到“因特网客户端”图形界面实际承担的工作大概有这么几类每一类都对应着命令行难以处理的问题。第一是持续输出的呈现。一个聊天客户端、一个日志订阅客户端、一个长连接的心跳监控它们的共同点是数据会源源不断地来。命令行里你要么让它一直滚屏要么重定向到文件再去看交互体验很差。文本控件天然适合做这件事还能加自动滚动、加行数上限、加关键词高亮。第二是并发操作的入口。网络客户端往往需要在连接保持的同时做别的事——边收数据边发数据边连接边取消。命令行程序是很难“取消”的按 CtrlC 之后进程就没了连接也跟着断。界面上可以有一个“断开”按钮一个“重连”按钮它们和后台的连接状态一一对应用户知道自己按下去会发生什么。第三是错误的第一时间反馈。网络错误在命令行里的表现形式是异常栈在界面上应该是一句人话比如“目标主机拒绝连接请确认服务端是否已启动”。这不是美化是降低理解成本。异常栈对开发者有用对使用者是噪音。一点提醒不要为了 GUI 而 GUI。如果这个客户端只有你自己用或者它是被另一个程序调用的中间件界面纯属负担。GUI 的适用边界是“有非开发者的真人要操作它”。2. Python 桌面界面工具选型的取舍账2.1 几个主流方案的真实差异Python 做桌面界面的方案不少选型的时候容易被各种对比表绕晕。我的经验是别看功能列表看三个维度要不要额外装东西、打包出来多大、以及遇到问题时能不能搜到答案。按这三条排一下结论会比较清楚。方案依赖情况上手成本打包体积增量适合的场景tkinter标准库自带低很小工具类客户端、内部使用、教学演示PySide / PyQt需单独安装中较大几十 MB界面复杂、需要专业控件、要商用交付wxPython需单独安装中中等想要原生外观的桌面程序Kivy需单独安装中偏高中等触屏、跨移动端pywebview需单独安装低会前端即可中等界面想用 HTML 写Dear PyGui需单独安装中中等高频刷新的数据可视化面板这张表里最值得说的一句是tkinter 的唯一优势是“不用装”但这个优势在客户端工具这个场景下权重极高。因为这类程序通常是要分发给别人用的依赖越少打包越省心出问题的概率越低。2.2 为什么这一系列文章仍然从 tkinter 起步有人会说 tkinter 界面丑、控件少。这话对但要看你在做什么。一个 TCP 客户端、一个 HTTP 调试工具、一个文件上传下载器它们需要的控件无非是输入框、按钮、标签、文本区、下拉框、进度条、文件选择对话框。这些东西 tkinter 全都有而且用法统一、文档稳定、搜出来的答案基本都能跑。更实际的一点是调试路径短。tkinter 是标准库你的代码在别人的机器上不会因为“没装某个包”或者“装的版本不对”而崩掉。我遇到过用第三方界面库做的工具在一台老机器上因为底层库版本不匹配直接起不来排查了两个小时最后换成 tkinter 十分钟搞定。工具的可靠性优先级永远高于美观。当然如果你的客户端界面需要表格、树形结构、复杂的多标签布局、图表绘制tkinter 会开始难受那时候再换 PySide 是合理的。选型的正确姿势不是一次选到位而是先用最低成本跑通等界面复杂度真的顶到天花板了再迁移——只要你的业务逻辑和界面代码是分开的迁移成本就可控这一点后面会讲。3. tkinter 的最小骨架控件、布局和那个永不停歇的事件循环3.1 十行代码背后的运行模型先看一个能显示窗口的最小例子然后逐行拆它到底在干什么。import tkinter as tk root tk.Tk() # 创建顶层窗口也是整个程序的根 root.title(客户端) # 窗口标题 root.geometry(480x320) # 初始尺寸宽x高 label tk.Label(root, text未连接) label.pack(pady20) btn tk.Button(root, text连接, commandlambda: label.config(text已连接)) btn.pack() root.mainloop() # 进入事件循环程序在这里停住关键在最后一行。mainloop()不是“显示窗口”这么简单它是一个阻塞的死循环不断从系统的事件队列里取出事件鼠标点击、键盘输入、窗口重绘、定时器到期找到对应的回调函数在当前线程里同步执行完再回去取下一个事件。程序之所以能在窗口开着的时候“不结束”就是因为卡在这个循环里。这个模型决定了一件必须记住的事任何在回调函数里执行的耗时操作都会让整个循环停摆。循环停了窗口就不重绘、按钮就不响应、标题栏就会变成“未响应”。后面第 4 节所有的坑根源都在这里。3.2 几何管理器选 pack 还是 gridtkinter 有三种布局方式pack、grid、place。place是绝对坐标定位除非你在做自绘或者需要像素级对齐否则不建议用窗口一拉伸就全乱。pack是按顺序堆叠适合“顶部一行工具栏中间一大块文本区底部一行输入框”这种线性结构配fill和expand能做出不错的自适应效果。grid是网格布局适合表单式的界面比如左侧一列标签、右侧一列输入框。这里有一个必须知道的红线同一个父容器里不能混用pack和grid。混用的时候 Tk 会抛TclError: cannot use geometry manager pack inside . which already has slaves managed by grid或者界面直接卡住不显示而且不报错非常难查。正确做法是分层——外层用pack分成上中下三块Frame每个Frame内部再用grid排自己的控件互不干扰。我的习惯是顶层结构一律用pack因为它对窗口缩放的响应最自然表单区域一律用grid因为它对齐最省事。两者通过Frame隔开永远不会打架。3.3 事件绑定与回调的执行时机除了command这种按钮专用参数tkinter 更通用的机制是bind。比如给输入框绑定回车键entry.bind(Return, lambda event: send_message())这里有个细节command绑定的回调不带参数而bind绑定的回调会收到一个 event 对象。所以如果你写commandself.send_message而send_message定义成接收self和event两个参数点击按钮时就会报参数数量不对。这个错误新手几乎必踩记住“command 无参、bind 有参”就避开了。另一个容易忽略的点是回调的执行上下文。不管是按钮点击还是键盘事件回调全部在主线程里执行。这意味着在回调里time.sleep(3)或者发一个阻塞的 socket 请求界面就冻三秒。很多人第一反应是“那我加个进度条不就行了”但只要进度条也要靠主线程重绘它一样会冻住。唯一的出路是把耗时活儿挪出去。4. 把网络请求塞进界面主线程阻塞的坑从这里开始4.1 一个“点一下就假死”的复现先复现问题知道它长什么样后面才好判断自己是不是踩上了。import socket import tkinter as tk from tkinter import messagebox def on_connect(): try: s socket.create_connection((127.0.0.1, 9000), timeout5) status.config(text已连接) s.close() except OSError as e: messagebox.showerror(连接失败, str(e)) root tk.Tk() status tk.Label(root, text未连接) status.pack(pady10) tk.Button(root, text连接, commandon_connect).pack() root.mainloop()如果服务端在监听这段代码看起来毫无问题点一下状态变了。但如果服务端没有启动或者目标地址是一个会丢包的网络create_connection就会一直卡到超时。这几秒里窗口完全僵住拖不动、按钮灰不掉、状态标签不更新Windows 上标题栏直接显示“未响应”macOS 上是转圈彩虹球。用户看到“未响应”的第一反应是再点一次然后程序里就多了一条卡住的连接。连点几次界面要等好几倍的时间才能活过来。这不是 bug这是模型决定的必然结果。4.2 方案一工作线程 队列 after 轮询最通用也最稳的做法是把网络操作扔到后台线程主线程只负责“取结果、更新界面”。两者之间用queue.Queue传数据主线程用after定期去队列里捞。import queue import socket import threading import tkinter as tk msg_queue queue.Queue() def worker_connect(host, port): try: s socket.create_connection((host, port), timeout5) msg_queue.put((ok, s)) except OSError as e: msg_queue.put((error, str(e))) def drain_queue(): try: while True: kind, payload msg_queue.get_nowait() if kind ok: status.config(text已连接) else: status.config(text连接失败) except queue.Empty: pass root.after(100, drain_queue) # 100 毫秒后自己再调自己 # 启动时挂上轮询 root.after(100, drain_queue) # 按钮回调里只起线程不干活 tk.Button(root, text连接, commandlambda: threading.Thread( targetworker_connect, args(127.0.0.1, 9000), daemonTrue ).start()).pack()这个模式有三个要点每个都不是可有可无的。一是daemonTrue。不加这个主窗口关掉之后后台线程如果还阻塞在 socket 上整个进程就退不出去任务管理器里留着个僵尸。加了它主线程一结束守护线程跟着被回收。二是after自轮询。root.after(100, drain_queue)的意思是“100 毫秒后调用 drain_queue”而 drain_queue 的末尾又调用了自己于是形成一个在主线程里跑的、非阻塞的定时循环。它和mainloop是协作关系不是竞争关系。三是队列里只放数据不放操作。有个常见的错误做法是把lambda: status.config(...)塞进队列让主线程去执行这个闭包。这在简单场景下能跑但它埋了个隐患——闭包捕获的变量状态在入队和出队之间可能已经变了而且这种写法很容易演变成在后台线程里直接调用控件方法。4.3 方案二非阻塞 socket 配合 after 自轮询如果客户端需要同时管理多个连接或者对延迟敏感起一堆线程会变得难以管理。这时候可以把 socket 设成非阻塞用after单线程轮询整个程序只有主线程天然没有竞态问题。import selectors import socket import tkinter as tk sel selectors.DefaultSelector() buf bytearray() def connect_async(host, port): s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setblocking(False) try: s.connect((host, port)) except BlockingIOError: pass # 非阻塞连接必然先抛这个属正常 sel.register(s, selectors.EVENT_WRITE | selectors.EVENT_READ, conn) poll() def poll(): for key, mask in sel.select(timeout0): # 关键timeout0绝不阻塞 sock key.fileobj if mask selectors.EVENT_WRITE: err sock.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR) sel.modify(sock, selectors.EVENT_READ, conn) status.config(text已连接 if err 0 else 连接失败) if mask selectors.EVENT_READ: data sock.recv(4096) if data: buf.extend(data) render(buf.decode(utf-8, errorsreplace)) else: sel.unregister(sock) sock.close() root.after(50, poll)sel.select(timeout0)这句是整个方案的核心。把超时设成 0 意味着它只做一次“有就绪事件吗”的检查就立刻返回绝不等待。检查完立刻交出控制权然后用after在 50 毫秒后再来一轮。整个过程是主线程里的一段短平快的代码界面始终能重绘。代价是延迟。最坏情况下数据到达和界面更新之间会差 50 毫秒对聊天、日志、状态监控这类场景完全够用对实时音视频就不行了。50 毫秒这个数字也不是随便定的设成 10 毫秒CPU 占用会明显上去设成 200 毫秒操作手感发滞。4.4 跨线程动控件的后果这里必须单独强调一遍因为它是 tkinter 里最容易出事、又最难复现的问题Tk 不是线程安全的。在后台线程里直接写label.config(textxx)大多数时候看起来没事偶尔会抛RuntimeError: main thread is not in main loop极少数情况下会让整个进程直接崩掉连异常都抓不到。更讨厌的是这种崩溃的触发依赖于操作系统的调度时机本地测试跑一万次不崩到用户机器上第一次就崩。判断标准很简单只要这行代码在主线程之外执行就不能碰控件。包括config、insert、delete、pack、destroy一个都不行。要改界面一律走队列让主线程去改。上面方案一的drain_queue就是这道闸门。5. 一个能跑的网络客户端界面从骨架到可用5.1 界面结构拆解把前面的零件拼起来做一个完整的 TCP 客户端顶部是主机、端口输入和连接按钮中间是收发的日志区底部是发送输入框和发送按钮。这个结构适用面很广稍微改改就能变成 HTTP 调试工具或者日志监控面板。界面分三块用三个Frame上下堆叠每个内部各自布局import queue import socket import threading import tkinter as tk from tkinter import scrolledtext, messagebox class TcpClientApp: def __init__(self, root): self.root root self.root.title(TCP 客户端) self.root.geometry(680x460) self.root.minsize(520, 360) self.sock None self.reader None self.running False self.msg_queue queue.Queue() self._build_top() self._build_middle() self._build_bottom() self.root.protocol(WM_DELETE_WINDOW, self.on_close) self.root.after(100, self._drain) def _build_top(self): top tk.Frame(self.root) top.pack(filltk.X, padx10, pady8) tk.Label(top, text主机).pack(sidetk.LEFT) self.host_var tk.StringVar(value127.0.0.1) tk.Entry(top, textvariableself.host_var, width16).pack(sidetk.LEFT, padx(4, 12)) tk.Label(top, text端口).pack(sidetk.LEFT) self.port_var tk.StringVar(value9000) tk.Entry(top, textvariableself.port_var, width7).pack(sidetk.LEFT, padx(4, 12)) self.conn_btn tk.Button(top, text连接, width8, commandself.toggle_connect) self.conn_btn.pack(sidetk.LEFT) self.status_var tk.StringVar(value未连接) tk.Label(top, textvariableself.status_var, fg#666).pack(sidetk.RIGHT)顶部这一行信息密度高但不拥挤。把状态标签放右边靠sidetk.RIGHT和左边一组输入形成视觉上的两端对齐用户扫一眼就知道当前是连着的还是断着的。5.2 收发逻辑与主线程分工中间是日志区底部是发送区。日志区用ScrolledText注意它的state要在“可写”和“只读”之间切换直接写只读控件是不生效的这是个高频坑。def _build_middle(self): self.log scrolledtext.ScrolledText(self.root, height18, statetk.DISABLED, wraptk.WORD, font(Consolas, 10)) self.log.pack(filltk.BOTH, expandTrue, padx10) self.log.tag_config(sys, foreground#888888) self.log.tag_config(err, foreground#c0392b) def _build_bottom(self): bottom tk.Frame(self.root) bottom.pack(filltk.X, padx10, pady10) self.input_var tk.StringVar() entry tk.Entry(bottom, textvariableself.input_var) entry.pack(sidetk.LEFT, filltk.X, expandTrue) entry.bind(Return, lambda e: self.send()) self.send_btn tk.Button(bottom, text发送, width8, statetk.DISABLED, commandself.send) self.send_btn.pack(sidetk.LEFT, padx(8, 0)) def append_log(self, text, tagNone): self.log.configure(statetk.NORMAL) # 先解锁 self.log.insert(tk.END, text \n, tag) # 控制行数防止长时间运行后内存和渲染压力 lines int(self.log.index(end-1c).split(.)[0]) if lines 2000: self.log.delete(1.0, f{lines - 2000}.0) self.log.configure(statetk.DISABLED) # 再锁回去 self.log.see(tk.END) # 自动滚到底append_log这个函数值得多看两眼。statetk.NORMAL和statetk.DISABLED的来回切换不是啰嗦是必需的行数裁剪也不是过度设计一个跑一晚上的客户端如果日志无上限界面会越用越卡因为Text控件的内容是真的全部渲染的。连接和收发的实现严格遵守“网络在网络线程、界面在主线程”的分工def toggle_connect(self): if self.running: self.disconnect() else: self.connect() def connect(self): host self.host_var.get().strip() try: port int(self.port_var.get().strip()) except ValueError: messagebox.showwarning(参数错误, 端口必须是数字) return self.conn_btn.config(statetk.DISABLED, text连接中) self.status_var.set(连接中) def worker(): try: s socket.create_connection((host, port), timeout5) s.settimeout(None) self.msg_queue.put((connected, s)) except OSError as e: self.msg_queue.put((failed, str(e))) threading.Thread(targetworker, daemonTrue).start() def _reader_loop(self, sock): while self.running: try: data sock.recv(4096) except OSError: break if not data: break self.msg_queue.put((data, data.decode(utf-8, errorsreplace))) self.msg_queue.put((closed, None)) def send(self): if not self.sock: return text self.input_var.get() if not text: return payload (text \n).encode(utf-8) try: self.sock.sendall(payload) except OSError as e: self.append_log(f[发送失败] {e}, err) return self.append_log(f {text}) self.input_var.set()sendall放在主线程里是可以接受的因为它通常瞬间返回而且数据量小。但如果你的客户端要发大文件sendall一样会阻塞那就得把发送也挪到线程里去并且用send循环加偏移量来跟踪进度。这个区别值得提前想清楚。5.3 状态机与队列消费最后的收口是把队列里的消息翻译成界面变化。这里用一个小小的状态判断把按钮文字、可点击状态、状态标签一起改掉保证三者永不同步错乱。def _drain(self): try: while True: kind, payload self.msg_queue.get_nowait() if kind connected: self.sock payload self.running True self.status_var.set(已连接) self.conn_btn.config(statetk.NORMAL, text断开) self.send_btn.config(statetk.NORMAL) self.append_log([系统] 连接已建立, sys) self.reader threading.Thread( targetself._reader_loop, args(payload,), daemonTrue) self.reader.start() elif kind failed: self.status_var.set(连接失败) self.conn_btn.config(statetk.NORMAL, text连接) self.append_log(f[错误] {payload}, err) elif kind data: self.append_log(payload.rstrip(\n)) elif kind closed: self._reset_state() self.append_log([系统] 连接已断开, sys) except queue.Empty: pass self.root.after(100, self._drain) def _reset_state(self): self.running False self.sock None self.status_var.set(未连接) self.conn_btn.config(statetk.NORMAL, text连接) self.send_btn.config(statetk.DISABLED) def disconnect(self): self.running False if self.sock: try: self.sock.shutdown(socket.SHUT_RDWR) except OSError: pass self.sock.close() self._reset_state()disconnect里先shutdown再close是有讲究的。只调close()在有的系统上读线程会卡在recv里不返回因为它感知不到连接已经没了。先shutdown(SHUT_RDWR)会让阻塞中的recv立刻返回空或者抛异常读线程才能干净退出。还有个容易漏的收尾窗口关闭。默认点叉只是销毁root后台线程和 socket 都还在。要显式接管def on_close(self): self.running False if self.sock: try: self.sock.shutdown(socket.SHUT_RDWR) self.sock.close() except OSError: pass self.root.destroy()这段代码看着平淡但它决定了你的程序关掉之后任务管理器里是不是还留着一个进程。6. 实战中反复踩到的六个问题6.1 关掉窗口进程不退任务管理器里还有残影现象是窗口没了但进程还在再次启动时端口被占用或者文件被锁。原因几乎都是非守护线程还活着。排查顺序先看是不是有线程没设daemonTrue再看 socket 是不是没关最后检查有没有after循环在自我续命。第三点特别隐蔽。after是挂在root上的root.destroy()之后理论上会一起清掉但如果drain函数里捕获了异常然后仍然调用了self.root.after就会在已销毁的窗口上继续挂定时器抛TclError: cant invoke after command: application has been destroyed。稳妥的写法是在_drain开头加一句if not self.root.winfo_exists(): return。6.2 中文乱码编码要在一开始就定死socket 收发的都是字节编解码位置错了就是一堆问号或者UnicodeDecodeError。我的做法是在边界上统一 UTF-8中间层全是字节发送前text.encode(utf-8)收到后data.decode(utf-8, errorsreplace)。加errorsreplace很重要。网络对面如果发来的不是合法 UTF-8默认的strict会整段抛异常你的日志区瞬间少一条用replace会显示成替换字符虽然难看但至少你能看到“这里有问题”而不是数据凭空消失。还有一种情况是 TCP 粘包导致一次recv拿到半个汉字这时候按 UTF-8 解码会失败正确做法是用codecs.getincrementaldecoder(utf-8)()做增量解码把不完整的字节留到下一轮。6.3 高 DPI 屏幕下界面糊成一团在缩放 150% 的显示器上tkinter 默认渲染出来的界面要么模糊要么字小得看不清。Windows 上的处理方式是在创建Tk()之前声明 DPI 感知import ctypes def enable_hidpi(): try: ctypes.windll.shcore.SetProcessDpiAwareness(1) except (AttributeError, OSError): pass enable_hidpi()注意必须在tk.Tk()之前调用之后调用无效。另外还可以用root.tk.call(tk, scaling, 1.5)手动调缩放系数但更推荐用系统的 DPI 感知让 Tk 自己算。字体也别写死像素用点数比如(Consolas, 10)它会跟着系统缩放走。6.4 打包之后的体积和启动速度用打包工具把脚本变成可执行文件时两个参数影响巨大。--onefile会生成单个文件看起来干净但每次启动都要把内容解压到临时目录冷启动可能要好几秒--onedir生成一个目录启动快得多分发的时候压缩成包一样方便。体积方面先把不需要的模块排除掉能省不少。一个只有 tkinter 和 socket 的客户端正常应该在十几 MB 量级。如果你打出来上百 MB多半是把用不到的依赖一并扫进去了检查一下打包配置里的隐藏导入和排除列表。6.5 日志越滚越多界面越来越卡前面代码里的 2000 行裁剪是必须的。如果不裁跑几个小时后Text控件里有几十万行每次insert和see都要重排卡顿会非常明显而且内存一直涨。裁剪的策略也有讲究。一条一条delete(1.0, 2.0)太慢批量删更划算我一般是一次删掉超出部分的前 500 行让删除操作的频率降下来。另外see(tk.END)在用户手动往上翻日志的时候会导致视图被强行拽回底部体验很差可以加个判断只有当滚动条已经在底部时才自动滚动。6.6 按钮连点导致的重复连接网络请求还没返回用户又点了一次按钮于是起了两个线程、建了两条连接。这个问题的根源是界面上没有“进行中”这个状态。解法就是在发起请求的瞬间把按钮置灰并改文字等结果回来再恢复。上面代码里self.conn_btn.config(statetk.DISABLED, text连接中)这一行就是干这个的。同时最好再加一个内部的self.pending标志做双重保险因为有些场景下按钮放在别的地方也会被触发比如回车键绑定。这里有个细节如果连接超时是 5 秒用户会盯着“连接中”的按钮等 5 秒体验很差。所以超时值不要设太大3 到 5 秒对局域网和内网服务足够真要连远端该走重试而不是拖长超时。给个“取消”能力会更好但那需要额外的取消标志属于进阶内容。我个人在写这类带界面的网络工具时有一个习惯一直保持着先把纯逻辑部分写成不依赖任何界面库的模块比如连接管理、协议解析、重连策略这些东西单独能跑、能测然后再套一层薄薄的界面去调用它。这样做的好处是哪天界面库想换、或者要加一个命令行版本、或者要给别人当库引用都不用重写。前面那个TcpClientApp里其实已经体现了这个思路的雏形——网络相关的东西都在线程函数里界面只负责把队列里的结果摆出来。把这条线划清楚后面无论界面怎么膨胀都不会影响到真正干活的那部分。
阅读完成 · 觉得有帮助？
