Python memoryview 如何零拷贝切片二进制协议数据

处理大块二进制报文时，最容易被忽略的成本不是解析本身，而是每次切片都把数据再拷贝一遍。Python 的 memoryview 可以把支持 buffer protocol 的对象包装成视图：固定头部用 struct.unpack_from() 读取，变长载荷用视图切出来，只有要解码、入队或长期保存时才显式转成 bytes。

先把二进制协议的复制边界画出来

下面用一个原创的简单协议说明：第 1 个字节是消息类型，接着 2 个字节以大端序保存载荷长度，余下是载荷。传统写法 packet[3:3 + length] 会得到新的 bytes；当报文大、切片多或消息要经过多层处理时，这个副本会放大内存带宽压力。

memoryview 记录底层对象、起止位置和步长。它更像“带范围的借用”，不是一块新内存。下面这张图是静态结构说明图，不是运行截图：

用 memoryview 建立一条可复用的字节视图

解析前把输入统一成一维字节视图，便于后续偏移计算。struct 模块的格式前缀明确规定大端序和标准大小，避免把本机对齐规则带进外部协议：

import struct

HEADER = struct.Struct(">BH")  # B 是类型，H 是大端无符号短整数

def split_packet(packet):
    # 统一成字节视图；bytes 可读，bytearray 还允许原地修改。
    view = memoryview(packet).cast("B")
    if len(view)  len(view):
        raise ValueError("载荷长度超过当前报文")

    # 这里仍是视图，未复制 payload 的字节。
    payload_view = view[HEADER.size:end]
    return kind, payload_view

packet = bytes([2]) + (5).to_bytes(2, "big") + b"hello"
kind, payload_view = split_packet(packet)
print(kind, payload_view.tobytes())  # 进入打印/传递边界时才复制

关键点有两个。第一，unpack_from() 只要求从偏移位置起有足够字节，因此必须先检查固定头和长度字段，不能把“解析成功”误当成“整包完整”。第二，payload_view 可以交给后续校验、解压或哈希函数；示例最后的 tobytes() 才是明确的拥有一份独立数据。

零拷贝真正的边界是生命周期而不是切片语法

视图省掉了复制，也把底层缓冲区的生命周期带进了业务层。短链路可以让解析函数返回视图；如果要放进异步队列、缓存或对象属性，先问一句：接收缓冲区还会不会被复用？消费者是否需要独立持有数据？答案不确定时，复制反而更安全。

如果输入是 bytearray，视图默认可写，底层修改会反映到视图；如果输入是 bytes，视图只读。不要把“可写”当成便利的共享状态：协议校验阶段通常应只读，确需原地改字段时再单独划出权限。

上线前用四项检查判断是否值得零拷贝

不要仅凭“少一次复制”就改造所有代码。先做一组小基准，分别测完整报文、多个字段切片、解码和队列持有四种路径，关注峰值 RSS、GC 压力和端到端延迟。工程上我会按下面顺序检查：

1. 协议是否有明确的字节序、固定头长度和最大载荷，能否在切片前完成边界检查。
2. 消费者是否只在当前调用栈内使用视图；若会跨线程、跨协程或跨队列，先定义所有权。
3. 是否真的存在大报文或高频切片瓶颈；小消息上增加视图对象可能只增加复杂度。
4. 是否在文本解码、序列化、持久化之前设置唯一复制点，让内存归属可追踪。

释放视图不是性能仪式，而是生命周期信号。手动持有视图时可在消费完成后调用 view.release()；更常见的做法是缩短视图变量作用域，并让拥有数据的副本在明确的位置生成。

相关问题

memoryview 切片真的完全不分配吗？

切片本身得到新的视图对象，通常不会复制被引用的底层字节；视图对象仍有少量元数据开销，bytes(view) 或 view.tobytes() 才会创建内容副本。

为什么不直接用 packet 切片再交给 struct？

短报文这样写很直观。只有在高频、大块或多次切片的路径上，才值得用视图减少中间副本；先用基准确认复制是瓶颈，再引入生命周期规则。

memoryview 能否替代协议校验？

不能。它只改变访问方式，不负责校验魔数、长度、版本、校验和或权限。边界检查和格式校验仍应在解析入口完成。