纯Python写的WebSocket连接小工具，开箱即用的命令行客户端

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

简介：client1.py 是一个轻量、无GUI的Python WebSocket客户端脚本，直接运行就能连服务器收发消息。它不依赖复杂框架，主要靠标准库或 websocket-client 这类常见包，省去环境配置麻烦。使用时只需在命令行指定目标地址（如 ws://localhost:8080）、端口和协议参数，支持手动触发连接、发送文本消息、实时打印服务端返回内容。内置基础异常捕获，比如连接失败、网络中断或协议错误时会给出明确提示，方便快速定位问题。适合开发者做接口联调、后端服务通信验证、自动化测试中的WebSocket环节，也适用于教学演示或临时调试场景。代码结构扁平易读，没有后台常驻逻辑、不带Web界面、不集成日志系统或配置文件，所有功能聚焦在建立连接、收发帧、反馈状态这三件事上。

1. 项目概述：为什么一个“只干三件事”的脚本，反而成了我每天打开次数最多的Python文件

你有没有过这种经历：后端同事刚推了一版WebSocket服务，接口文档写得挺全，但你手头没有现成的调试工具——Postman不支持WS、浏览器控制台只能看不能发、临时搭个前端页面又太重？或者自动化测试跑着跑着，发现某个实时通知通道突然哑火，想快速确认是服务端崩了还是客户端心跳没续上，却要翻半天旧项目里那个藏在tests/integration/目录下的半成品连接脚本？再或者，带新人做实时聊天模块教学，想现场演示“连接→发消息→收回包”这个最朴素的闭环，结果被一堆框架初始化代码绕晕了，连ws://和wss://的区别都来不及讲清楚？

client1.py就是为这些“就现在、就这一步、就试一下”场景生的。它不是WebSocket协议栈的完整实现，也不追求功能大全；它就是一个命令行里的瑞士军刀小刀片：没有鞘、没镀铬、刀柄上甚至没刻品牌，但拔出来就能削苹果、开罐头、拧螺丝。核心就三件事：建立连接、发送文本帧、打印接收帧。所有其他东西——GUI界面、配置文件、日志轮转、多连接管理、SSL证书自动加载、消息序列化封装——全被砍掉。不是不能加，而是加了就违背它的存在逻辑。

我把它放在项目根目录下，命名故意带数字1，意思是“这是你能拿到的最原始、最接近协议本质的第一版”。它依赖的只有两样东西：Python 3.7+（标准库足够支撑基础网络层），以及一个极轻量的第三方包websocket-client（注意不是websockets，后者更现代但依赖更多，而websocket-client专注同步阻塞式交互，正适合命令行这种单次任务流）。整个脚本不到200行，函数不超过5个，没有类继承、没有装饰器、没有异步协程——你用cat client1.py扫一眼，30秒内就能看懂它在干什么。关键词里反复出现的“client1.py”，不是随便起的文件名，而是它的身份标识：它是你本地环境里那个永远在线、永不崩溃、不抢资源、不写日志、不弹窗口的“第一个人形终端代理”。

它解决的不是“如何构建一个企业级WebSocket网关”这种宏大命题，而是“我现在就想敲一行命令，看看这个ws://echo.websocket.org到底通不通”。这种需求看似琐碎，但在真实开发节奏里，它高频、刚需、不可替代。就像你不会为了拧一颗螺丝去买套液压扳手组，client1.py就是那把随身揣着的十字螺丝刀——便宜、可靠、用完就放回口袋，下次需要时，它还在老地方。

2. 整体设计与思路拆解：为什么选同步阻塞模型？为什么不用asyncio？

2.1 核心架构选择：同步阻塞，而非异步非阻塞

看到“WebSocket客户端”，很多人第一反应是asyncio+websockets库。这没错，生产环境里高并发长连接确实该这么干。但client1.py的设计起点完全不同：它面向的是单次、短时、交互式的调试行为。你运行它，输入地址，按回车，连上，发几条消息，看几行返回，Ctrl+C退出——整个生命周期可能就30秒。在这种场景下，引入asyncio带来的复杂度远超收益：

• 首先，你需要理解事件循环、await语法、async def定义，对新手或临时使用者构成认知门槛；
• 其次，命令行交互本身是线性的：用户输入地址 → 程序连接 → 用户输入消息 → 程序发送 → 程序等待接收 → 打印 → 循环。强行用asyncio去模拟这种线性流，反而要写一堆loop.run_until_complete()包装，代码更绕；
• 最关键的是，websocket-client提供的create_connection()接口本身就是同步阻塞的，它底层用socket直接操作，连接建立、帧收发都是明确的函数调用，错误也直接抛异常。这种“所见即所得”的调试体验，比在asyncio里追Future状态要直观十倍。

我试过两种实现：一个是纯asyncio+websockets，另一个就是现在的websocket-client同步版。前者在连接超时处理上需要手动设置asyncio.wait_for()，在用户中断（Ctrl+C）时要额外处理CancelledError，还要确保连接对象被正确close()；后者一行ws.close()搞定，try/except直接捕获ConnectionRefusedError、WebSocketConnectionClosedException等具体异常，错误信息直白到能当调试日志用。实测下来，同步版本在响应速度上毫无感知差异——毕竟你不是在压测百万连接，而是在验证一个端口是否开放。

2.2 依赖精简策略：“标准库能干的，绝不假手第三方”

client1.py的依赖声明只有这一行：

import websocket

背后是经过权衡的取舍。Python标准库中没有原生WebSocket支持（http.client只管HTTP，socket只管TCP），所以必须引入第三方。但选哪个？当时摆在桌面上的有三个候选：

• websockets：功能最强，异步原生，协议支持最全，但安装需pip install websockets，且依赖asyncio和aiohttp，体积不小；
• websocket-client：同步接口，轻量（单文件核心逻辑），安装只需pip install websocket-client，依赖仅six（Python2/3兼容库，现代环境基本无感），GitHub Star数超8k，社区维护活跃；
• 自己用socket+ssl手撸：理论上可行，但WebSocket握手涉及Sec-WebSocket-Key生成、Base64编码、SHA-1哈希、HTTP头解析等细节，出错概率极高，调试成本爆炸，完全违背“开箱即用”初衷。

最终选websocket-client，理由很务实：它把所有协议细节封装进一个create_connection()调用里，你传入ws://或wss://地址，它自动处理HTTP升级请求、密钥交换、帧解析。你关心的只是“连没连上”和“收没收到”，而不是“Sec-WebSocket-Accept值对不对”。而且它的错误类型极其友好——比如连接拒绝会抛ConnectionRefusedError，证书错误抛SSLError，协议不匹配抛WebSocketBadStatusException，每个异常名字都在告诉你问题出在哪一层。这种“错误即文档”的设计，让调试过程变成阅读异常信息的线性流程，而不是在协议规范里大海捞针。

2.3 功能边界划定：为什么坚决不加日志、配置文件和多连接？

client1.py的代码里找不到logging.basicConfig()，没有config.ini读取逻辑，也没有connections = {}这样的字典管理多个会话。这不是功能缺失，而是主动克制。我们来算一笔账：

• 加日志系统：意味着要决定日志级别（DEBUG/INFO/WARNING）、输出位置（console/file）、格式（时间戳、模块名、行号）、轮转策略……这些配置项对“临时调试”毫无意义，反而让用户困惑“为什么我的消息被记到/tmp/ws.log里了？”；
• 加配置文件：用户就得先创建config.yaml，填host: localhost, port: 8080，再运行python client1.py --config config.yaml。而现实是，95%的调试场景，用户只想敲python client1.py ws://localhost:8080/chat——地址就是参数，参数就是地址，中间不该有任何抽象层；
• 加多连接管理：意味着要设计连接池、ID分配、切换命令（/switch 2）、状态查询（/list）……但当你需要同时连5个服务端时，你真正该做的是开5个终端窗口，每个跑一个client1.py实例。Unix哲学说得好：“让每个程序只做好一件事”。

这种克制带来的好处是惊人的：整个脚本可以被完整复制粘贴进任何Python环境（Docker容器、CI流水线、新同事的笔记本），无需修改任何一行代码，pip install websocket-client后立刻可用。它不试图成为平台，它甘愿做一把螺丝刀——你不需要理解螺丝刀的冶金工艺，只要知道拧哪颗螺丝、用多大扭矩就行。

3. 核心细节解析与实操要点：从命令行参数到帧级控制

3.1 命令行参数设计：地址即一切，其余皆可选

client1.py的启动方式极其简单：

python client1.py ws://localhost:8080/echo

这是它的黄金法则：URL地址是唯一必需参数，其他所有配置都通过URL自身或可选参数覆盖。我们来拆解这个URL的每个部分如何被解析：

• ws:// 或 wss://：协议头直接决定底层是否启用SSL/TLS。wss://会自动触发websocket-client的SSL上下文创建，无需用户指定证书路径；
• localhost:8080：主机名和端口被提取为host和port，用于建立TCP连接。如果URL中未显式写端口（如ws://example.com），则默认使用80（ws）或443（wss）；
• /echo：路径部分作为WebSocket子协议（subprotocol）的暗示，但实际是否生效取决于服务端。client1.py会将其透传给create_connection()，由服务端决定是否协商此协议；
• 查询参数（如?token=abc123）：会被原样拼接到HTTP Upgrade请求的GET路径中，常用于携带认证令牌，服务端可从中解析。

除了URL，还支持两个可选参数：
- -t, --timeout: 连接超时秒数，默认3秒。为什么是3秒？因为局域网内连接通常<100ms，3秒足够覆盖网络抖动，又不至于让用户干等太久。设为0会无限等待，设为30秒则像在等一锅汤煮沸；
- -v, --verbose: 开启详细模式，打印每帧的原始字节长度、方向（→ 发送 / ← 接收）、时间戳。这对协议级调试至关重要——比如你想确认服务端是否真的发了Pong帧，或者消息是否被分片（fragmented），开启-v后能看到← Binary frame (len=4)这样的精确描述。

提示：URL中的特殊字符（如空格、#、?）必须URL编码。例如，要连接带空格的路径/chat room，应写成ws://localhost:8080/chat%20room，否则argparse会将其截断为两个参数，报错unrecognized arguments: room。

3.2 连接建立与状态反馈：从TCP三次握手到WebSocket握手

连接过程被封装在connect_to_server()函数中，其内部逻辑严格遵循WebSocket RFC 6455规范，但对外只暴露三个状态：

1. 连接中（Connecting…）：显示Attempting to connect to {url}...，此时websocket.create_connection()正在执行DNS解析、TCP三次握手、TLS握手（若为wss）、HTTP Upgrade请求发送与响应等待；
2. 已连接（Connected!）：收到服务端返回的HTTP 101 Switching Protocols响应，且Sec-WebSocket-Accept校验通过。此时控制台打印绿色✓ Connected!，并显示连接耗时（如[0.123s]）；
3. 连接失败（Failed）：捕获到任何异常，统一打印红色✗ Connection failed:后跟异常类型和消息。常见组合包括：
   - ConnectionRefusedError: [Errno 61] Connection refused → 目标端口未监听；
   - socket.gaierror: [Errno 8] nodename nor servname provided → DNS解析失败，主机名不存在；
   - websocket._exceptions.WebSocketBadStatusException: Handshake status 404 → URL路径错误，服务端无此endpoint；
   - ssl.SSLCertVerificationError → wss证书无效，此时可加--skip-ssl参数跳过验证（仅限测试环境）。

这个状态机设计的关键在于反馈即时且归因明确。它不像某些GUI工具那样只显示一个旋转图标，然后静默失败；而是让用户清晰知道卡在哪一步：是网络层（DNS/TCP）问题，还是应用层（HTTP Upgrade）问题，抑或协议层（WebSocket Key校验）问题。这种分层诊断能力，是高效调试的基石。

3.3 消息收发机制：文本帧的“所见即所得”交互

消息交互采用经典的命令行REPL（Read-Eval-Print Loop）模式，但做了针对性简化：

• 发送：用户在终端输入任意文本，回车即发送。输入/quit或/exit退出程序；输入/ping发送一个WebSocket Ping帧（服务端应返回Pong）；输入/help显示这些内置命令；
• 接收：服务端发来的每条消息，无论文本帧（Text Frame）还是二进制帧（Binary Frame），都会原样打印在终端，前面加←符号。文本帧直接显示UTF-8解码后的字符串；二进制帧则显示[Binary data, len=N]，避免乱码污染终端；
• 实时性：接收逻辑在独立线程中运行（threading.Thread(target=receive_loop, args=(ws,))），确保发送消息时不会阻塞接收。这意味着你可以连续敲hello、world、/ping，而服务端返回的hello、world、pong会实时混杂在你的输入下方，形成真实的双工通信视图。

这里有个易被忽略的细节：websocket-client默认会对文本帧进行UTF-8解码，但如果服务端发送了非法UTF-8序列（如截断的中文），解码会失败并抛UnicodeDecodeError。client1.py对此做了兜底：捕获该异常后，将原始字节以十六进制形式打印（如[Invalid UTF-8, hex: 0xe4 0xbd 0xa0]），既避免程序崩溃，又保留原始数据供分析。这种“尽力而为”的容错设计，让脚本在面对不规范服务端时依然健壮。

注意：不要在消息中输入控制字符（如\x03 Ctrl+C），这会直接终止Python进程。如需发送原始字节，应改用/send-binary命令（需自行扩展，当前版本未内置，但代码结构已预留钩子）。

4. 实操过程与核心环节实现：从零开始运行一个完整调试会话

4.1 环境准备与首次运行

假设你刚克隆了项目仓库，目录下有client1.py。第一步永远是安装依赖：

pip install websocket-client

websocket-client安装极快，因为它只有一个核心模块websocket，没有编译步骤。验证是否成功：

python -c "import websocket; print('OK')"

输出OK即表示环境就绪。

现在，我们用业界公认的WebSocket回显服务wss://echo.websocket.org做首次测试（注意：该服务有时不稳定，备用地址为ws://demos.kaazing.com/echo）：

python client1.py wss://echo.websocket.org

你会看到：

Attempting to connect to wss://echo.websocket.org...
✓ Connected! [0.456s]
← Connected to echo service!

连接成功！此时你已经站在了WebSocket世界的门口。接下来，输入几条消息试试：

Hello from client1.py!
How are you doing?
/test 123

每按一次回车，服务端都会原样返回相同内容，终端显示：

← Hello from client1.py!
← How are you doing?
← /test 123

这就是最纯粹的WebSocket通信：你发什么，它回什么，没有JSON封装、没有消息头、没有业务逻辑，只有裸帧在飞。

4.2 调试真实后端服务：连接本地Spring Boot WebSocket

假设你正在开发一个Spring Boot应用，@MessageMapping("/chat)`暴露了一个聊天端点。启动应用后，默认端口8080，那么连接命令是：

python client1.py ws://localhost:8080/chat

但很可能第一次就失败，报错：

✗ Connection failed: Handshake status 403

403 Forbidden？这说明服务端启用了STOMP或SockJS代理，或者有CORS/Origin校验。此时你需要告诉服务端“我是合法来源”，方法是在URL中添加Origin头（websocket-client支持通过header参数传递）：

python client1.py ws://localhost:8080/chat --header "Origin: http://localhost:3000"

如果服务端还要求Token认证，可将Token放入查询参数：

python client1.py "ws://localhost:8080/chat?token=eyJhbGciOiJIUzI1NiJ9..."

一旦连上，发送JSON格式消息（Spring Boot默认接受）：

{"type":"MESSAGE","payload":"Hi there!","destination":"/app/chat"}

服务端处理后，可能返回一个确认帧：

{"type":"RECEIPT","receipt-id":"r123"}

你会发现，client1.py对JSON不做任何解析，它只是忠实地打印字符串。这种“不干涉”恰恰是优势——它让你看清服务端真正吐出了什么，而不是被框架封装后的“美化版”响应。

4.3 深度协议调试：用-v参数观察帧细节

当遇到诡异问题，比如“消息发出去了，但服务端没反应”，或者“服务端发了数据，但我收不到”，就需要打开-v开关：

python client1.py ws://localhost:8080/chat -v

此时终端输出会多出帧级信息：

→ Text frame (len=24) [10:23:45.123]
← Text frame (len=32) [10:23:45.125]
→ Ping frame (len=0) [10:23:46.000]
← Pong frame (len=0) [10:23:46.001]

这些信息揭示了底层真相：
- len=24表示你发送的文本UTF-8编码后占24字节；
- 时间戳精确到毫秒，可计算端到端延迟；
- Ping/Pong帧的存在证明连接保活机制正常工作；
- 如果看到→ Text frame但长时间没有←响应，说明消息卡在服务端或网络中；
- 如果看到← Binary frame (len=1024)，而你预期是文本，则服务端可能在发送二进制数据（如图片base64），需检查业务逻辑。

我曾用这个功能定位过一个经典Bug：前端发的消息被服务端接收，但返回的RECEIPT帧里receipt-id字段为空。开启-v后发现，服务端实际发送的是Binary frame而非Text frame，原因是JSON序列化时用了bytes而非str。没有-v，这个问题会陷入“服务端说收到了，客户端说没收到”的死循环。

4.4 错误场景复现与修复验证

client1.py的价值不仅在于“连得上”，更在于“连不上时告诉你为什么”。我们刻意制造几个典型故障：

场景1：端口未开启

python client1.py ws://localhost:9999

输出：

Attempting to connect to ws://localhost:9999...
✗ Connection failed: [Errno 61] Connection refused

结论：检查服务端是否启动，端口是否绑定正确（netstat -an | grep 9999）。

场景2：URL路径错误

python client1.py ws://localhost:8080/wrongpath

输出：

✗ Connection failed: Handshake status 404

结论：核对服务端暴露的WebSocket endpoint路径。

场景3：wss证书问题（自签名）

python client1.py wss://self-signed.example.com:8443

输出：

✗ Connection failed: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed

解决方案：加--skip-ssl参数（仅测试用），或把自签名证书加入系统信任库。

每次故障的错误信息都精准指向问题根源，省去了在Wireshark里抓包分析HTTP状态码的麻烦。这种“错误即答案”的设计，让调试效率提升了一个数量级。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 常见问题速查表

5.2 独家避坑技巧：来自三年踩坑总结

技巧1：用/ping命令诊断连接活性，而非依赖心跳
很多教程强调“WebSocket必须实现心跳”，但client1.py不内置心跳，因为/ping命令就是最轻量的心跳。当你怀疑连接“假死”（TCP连接尚存但WebSocket通道已断），直接输入/ping——如果收到pong，说明通道完好；如果超时无响应，则连接已断。这比等待30秒心跳超时快得多，且无需修改服务端代码。

技巧2：--skip-ssl不是万能钥匙，慎用于生产环境
--skip-ssl参数会禁用SSL证书验证，让wss://连接绕过证书检查。但它同时也会禁用主机名验证（SNI），可能导致连接到错误的服务端。我在一次联调中误用此参数，结果client1.py连到了内网另一台同域名的测试服务器，导致消息全部发错地方。教训是：仅在明确知道目标证书无效（如自签名）且网络环境可信时使用，并在命令中显式注释# TEST ONLY。

技巧3：消息粘包？不存在的——WebSocket是帧协议，不是流协议
新手常问：“为什么我发两条消息，服务端收成一条？” 这源于混淆了TCP流和WebSocket帧。TCP确实会粘包，但WebSocket在TCP之上定义了严格的帧边界（FIN bit、opcode、length字段）。client1.py每次ws.send()都发送一个独立的文本帧，服务端onMessage回调必然按帧触发。如果你观察到“粘包”，真实原因是服务端应用层逻辑把多条消息合并处理了，而非网络层问题。用-v参数确认每条→ Text frame都是独立的，即可排除客户端嫌疑。

技巧4：Windows终端中文乱码终极解法
在Windows PowerShell或CMD中运行client1.py，中文消息可能显示为????。这不是脚本问题，而是终端编码不匹配。解决方案有三：
- 临时：运行chcp 65001将终端编码切为UTF-8；
- 永久（PowerShell）：在$PROFILE中添加$OutputEncoding = [console]::InputEncoding = [console]::OutputEncoding = New-Object System.Text.UTF8Encoding；
- 终极：改用Windows Terminal，它原生支持UTF-8。

技巧5：自动化测试集成——用echo管道喂消息
client1.py支持从标准输入读取消息，便于集成到Shell脚本中。例如，批量发送测试消息：

printf "msg1\nmsg2\nmsg3\n/quit\n" | python client1.py ws://localhost:8080/chat

配合timeout命令可实现超时控制：

timeout 10s bash -c 'printf "ping\n/quit\n" | python client1.py ws://localhost:8080/chat' 2>/dev/null

这使得client1.py能无缝嵌入CI/CD流水线，作为WebSocket健康检查的一环。

6. 代码结构与可扩展性：200行脚本里的工程智慧

6.1 扁平化结构解析：为什么没有类，只有函数？

打开client1.py，你会看到这样的结构：

#!/usr/bin/env python3
"""
client1.py - A minimal WebSocket CLI client.
...
"""

import argparse
import sys
import threading
import time
import websocket

def parse_arguments():
    ...

def connect_to_server(url, timeout):
    ...

def send_loop(ws):
    ...

def receive_loop(ws):
    ...

def main():
    ...

if __name__ == "__main__":
    main()

没有class WebSocketClient，没有__init__构造函数，所有逻辑都落在5个纯函数里。这种设计不是偷懒，而是深思熟虑的结果：

• 降低认知负荷：新手阅读时，不需要理解“实例属性”、“self引用”、“方法绑定”等OOP概念，直接看connect_to_server()就知道这是连接逻辑；
• 提升可测试性：每个函数职责单一，可独立单元测试。例如，parse_arguments()可传入模拟参数列表，断言返回的args.url是否正确；connect_to_server()可mock websocket.create_connection()，验证超时逻辑；
• 便于热替换：如果你想把send_loop()改成支持JSON-RPC格式，只需重写这个函数，其他部分完全不动。没有类继承树的牵连，修改风险极低。

我曾见过一个“企业级”WebSocket客户端，封装了12个类，3层继承，5个Mixin。当需要加一个简单的/ping命令时，我花了2小时理清调用链，最后发现要在BaseConnectionManager的_handle_user_input()里注入逻辑。而client1.py里，/ping的实现就三行：

elif msg.strip() == '/ping':
    ws.ping()
    print('→ Sent ping')

加在哪里？就在send_loop()的if/elif分支里。这就是扁平化的力量。

6.2 预留扩展钩子：如何安全地添加新功能？

尽管client1.py追求极简，但代码中已埋下多个扩展点，确保新增功能不破坏原有逻辑：

• 命令扩展：所有内置命令（/quit, /ping, /help）都集中在send_loop()的一个if/elif链中。添加新命令如/subscribe topic，只需在此处增加分支，调用新函数subscribe_to_topic(ws, topic)；
• 消息预处理：在send_loop()中ws.send(msg)之前，可插入任意预处理逻辑，如自动添加时间戳、JSON封装、Base64编码；
• 接收后处理：receive_loop()中print(f"← {message}")之前，可加入过滤、解析、告警等逻辑；
• 连接后钩子：connect_to_server()返回ws对象后，可在main()中调用ws.set_cookie("auth=token")等websocket-client支持的高级API。

这些钩子的存在，让client1.py成为一个可生长的基座。它不强迫你接受它的全部，而是允许你按需裁剪和增强。就像乐高积木，基础块只有几种形状，但组合起来能搭建任何东西。

6.3 安全边界声明：它不做什么，同样重要

最后，必须明确client1.py的安全边界，避免误用：

• 它不验证服务端证书（除非你显式启用--skip-ssl，但那是绕过验证）；
• 它不加密客户端消息（WebSocket本身不提供端到端加密，wss只保证传输层TLS）；
• 它不存储任何敏感信息（密码、Token、私钥）到磁盘，所有认证凭据都通过URL或内存变量传递；
• 它不处理消息重传（WebSocket协议本身不保证可靠投递，应用层需自行实现ACK机制）；
• 它不防范恶意服务端（如果连接到不可信服务端，对方可发送任意数据，client1.py会原样打印，可能触发终端漏洞）。

这些“不作为”不是缺陷，而是清醒的取舍。client1.py的定位是调试工具，不是生产客户端。生产环境应该使用经过安全审计的SDK，实现完整的认证、加密、重试、监控。而client1.py存在的意义，是让你在生产部署前，用最短路径验证“协议通不通、消息收不收、逻辑对不对”。它是一面镜子，照出服务端的真实面貌，而不是一个画框，替你修饰瑕疵。

我在实际使用中发现，最高效的调试流程往往是：先用client1.py快速验证基础连通性（5分钟），再用Postman或自研UI测试业务逻辑（30分钟），最后用client1.py的-v模式抓帧确认协议细节（10分钟）。这三个阶段环环相扣，而client1.py始终扮演那个最锋利、最直接、最不废话的切入点。它不承诺完美，但承诺诚实——你看到的，就是服务端真正发送的。

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

简介：client1.py 是一个轻量、无GUI的Python WebSocket客户端脚本，直接运行就能连服务器收发消息。它不依赖复杂框架，主要靠标准库或 websocket-client 这类常见包，省去环境配置麻烦。使用时只需在命令行指定目标地址（如 ws://localhost:8080）、端口和协议参数，支持手动触发连接、发送文本消息、实时打印服务端返回内容。内置基础异常捕获，比如连接失败、网络中断或协议错误时会给出明确提示，方便快速定位问题。适合开发者做接口联调、后端服务通信验证、自动化测试中的WebSocket环节，也适用于教学演示或临时调试场景。代码结构扁平易读，没有后台常驻逻辑、不带Web界面、不集成日志系统或配置文件，所有功能聚焦在建立连接、收发帧、反馈状态这三件事上。

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