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 时返回空视图，看似安全，但后续若误当成有效数据用，逻辑就错了
零拷贝的代价是更紧的生命周期耦合和更少的容错空间——切片本身不危险，危险的是忘了谁在真正管理那块内存。
