WebSocket日志不能用默认logging配置，因其同步写入会阻塞事件循环、导致连接吞吐量崩溃；必须改用异步日志库（如loguru+enqueue）、分层采样、结构化绑定上下文。
高并发 WebSocket 场景下，全量同步日志会直接拖垮连接吞吐量——不是“可能慢”，而是必然导致线程阻塞、内存暴涨、日志系统反成故障源。
为什么 WebSocket 日志不能用默认 logging 配置
WebSocket 连接生命周期长、事件密集（open/message/close/ping/pong/error），每秒数千连接时，logging.info() 这类调用在 Python 中默认是同步写入的。哪怕只是 logger.info("message received")，也会触发：
• 字符串格式化（即使日志级别被关闭，f-string 或 % 拼接仍执行）
• LogRecord 构造与序列化
• 文件 I/O 或网络写入（阻塞 event loop）
结果就是：asyncio 事件循环卡顿，新连接排队，心跳超时批量断连。
Python websockets 库的异步日志接入点
websockets 库本身不强制绑定日志器，但通过 LoggerAdapter 可注入上下文，且必须配合异步日志后端使用：
• 不要用 logging.basicConfig() —— 它注册的是同步 handler
• 必须用支持 asyncio 的日志库，如 structlog + aiologger，或 loguru（内置异步 sink）
• 关键：把日志写入操作交由 asyncio.to_thread() 或专用线程池执行
示例（loguru）：
from loguru import logger
import asyncio
<p>logger.remove()
logger.add(
"ws.log",
format="{time} | {level} | {message} | {extra}",
enqueue=True, # 启用异步队列
backtrace=True,
diagnose=True
)</p><h1>在 WebSocket handler 中直接调用</h1><p>async def echo(websocket, path):
logger.bind(connection_id=id(websocket), client_ip=websocket.remote_address[0]).info("connection opened")
try:
async for message in websocket:
await websocket.send(message)
except Exception as e:
logger.exception("error in echo handler")
按事件类型+采样率分层控制日志密度
盲目降低日志级别（如全切到 WARNING）会丢失关键调试线索。更有效的是分层采样：
• "connection_open" / "connection_close"：全量记录（必要审计）
• "message_received" / "message_sent"：按连接 ID 哈希采样，例如 hash(client_ip) % 100 == 0（保留 1% 流量全链路追踪）
• "ping" / "pong"：仅记录异常（超时、缺失、频率超标），正常心跳完全不记
• "error"：ERROR 级别全量，DEBUG 级别加采样（如每 10 次同类错误只记 1 次堆栈）
注意：采样逻辑必须在日志构造前判断，避免无意义的对象序列化开销。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
结构化日志 + 上下文绑定才是高并发友好型实践
字符串日志在日志平台中无法高效过滤和聚合。必须让每条日志自带结构：
• 使用 logger.bind() 注入 connection_id、client_ip、path、user_id（若已认证）
• 错误日志必须包含 exc_info=True 或显式 logger.exception()
• 避免在日志消息里拼接 JSON 字符串（破坏结构化），而应通过 logger.info("msg", user_id=123, bytes=len(data)) 传参
最终输出是机器可解析的 JSON 行，而非人类可读的混合文本。这点在日志量破万条/秒时，直接影响 ELK 查询延迟和告警准确率。
最容易被忽略的一点：日志采样的“分母”不能是全局计数器——它在多进程部署下会失效；必须基于连接标识（IP + 端口）或请求唯一 ID 做哈希，才能保证采样行为可重现、可对比。否则你以为在看 1% 的流量，实际可能是某几个客户端被反复采样，其余全漏掉。
