17370845950

memoryview切片不拷贝数据，因其仅持原内存地址与描述，切片仅调整指针偏移和长度；bytes切片则必拷贝。

memoryview 切片为什么不会拷贝数据

因为 memoryview 本身不持有数据，只持有一块已分配内存的地址、长度和格式描述。当你对它切片（比如 m[10:20]），Python 返回的是一个新的 memoryview 对象，指向原缓冲区的子区域，底层 Py_buffer 结构里的 buf 指针偏移、len 重设，没有 memcpy 发生。

这和 bytes[10:20] 有本质区别：后者一定返回新 bytes 对象，触发完整拷贝。

验证方式：用 id() 或 m.obj is original_obj 确认切片后的 memoryview 仍绑定原始对象；修改原 bytearray 内容，切片视图会立刻反映变化。

必须用 bytearray 才能安全写入切片视图

bytes 是不可变的，即使你用 memoryview 包装它，也无法通过切片视图修改内容——尝试赋值会抛 TypeError: cannot modify read-only memory。

而 bytearray 是可写的缓冲对象，它的 memoryview 支持读写。只要原始对象没被释放或 resize，所有基于它的 memoryview 切片都可直接写入：

data = bytearray(b'hello world')
m = memoryview(data)
sub = m[6:11]  # b'world'
sub[0] = ord('W')  # ✅ 成功：data 变成 b'hello World'

• 切片得到的 memoryview 与原对象共享底层存储，写入即生效
• 若原 bytearray 后续调用 .extend() 或 .resize()，可能触发内存重分配，原有 memoryview 会自动失效（访问时抛 ValueError: memoryview has been detached）
• bytes 包装的 memoryview 只能用于只读场景，如解析协议头、快速比对字节段

切片后传参给 C 扩展或 socket.send() 的注意事项

很多底层 API（如 socket.send()、struct.unpack_from()、Cython 中的 char[:]）接受 memoryview，且明确支持零拷贝传递。但要注意：

• 函数是否声明接受 buffer protocol 对象（查文档看参数类型是否写 “buffer-like” 或 “bytes-like”）
• socket.send(sub) 是安全的，内核直接从用户态内存读取，不经过 Python 层拷贝
• 如果函数内部做了 bytes(obj) 转换，就会触发拷贝——得看其实现，不能只看接口签名
• 跨线程传递 memoryview 切片需确保原始 bytearray 生命周期足够长，否则可能访问已释放内存（虽 Python 通常会报错，但不是绝对安全）

容易忽略的边界问题：非连续内存与 format 不匹配

memoryview 切片在底层依赖 Py_buffer 的 strides 和 suboffsets。如果原始对象是非连续布局（如 NumPy 的 strided array），切片可能无法生成有效的子视图，抛 BufferError: memoryview: underlying buffer is not C-contiguous。

对纯 bytes/bytearray 来说这不是问题（它们总是 C 连续），但如果你混用其他支持 buffer protocol 的类型（如某些 ctypes 数组、自定义类），就得检查：

• 用 m.c_contiguous 或 m.f_contiguous 属性判断连续性
• 切片后 m.format 保持为 'B'（单字节无符号整数），若原始 view 是 '

  

  i'（int32），切片可能因对齐失败而报错
• 避免对 memoryview 做“越界但未崩溃”的切片：如 m[1000:] 在原长 500 时返回空视图，看似安全，但后续若误当成有效数据用，逻辑就错了

零拷贝的代价是更紧的生命周期耦合和更少的容错空间——切片本身不危险，危险的是忘了谁在真正管理那块内存。