Python中两次切片操作的效率对比探究

核心原理：str/bytes的切片实现 #

Python里的str和bytes都是不可变序列类型，它们的切片操作并不会直接复制底层的字符/字节数组。切片生成的新对象会共享原对象的底层数据，仅通过指针标记自身的起始位置和长度，同时依靠引用计数管理内存。只有当对切片后的对象执行修改操作时，才会触发底层数据的复制（即写时复制，COW机制）。

两种切片写法的效率差异 #

• 单次切片：mystr[offset: offset+length]
  一步到位创建新的切片对象，仅需计算一次边界、设置指针和长度，开销极小。

• 链式切片：mystr[offset:][:length]
  先通过mystr[offset:]创建一个共享原数据的切片对象，再基于这个中间对象做第二次切片得到结果。这里的额外开销只是多创建了一个中间切片对象，以及两次边界计算——但因为没有复制底层数据，实际性能差异非常小，普通业务场景下几乎感知不到。

更长链式切片的效率问题 #

比如mystr[a:][b:][c:]这类多层链式切片，本质就是多次创建中间切片对象，每个对象都只是指向原数据的指针加长度记录，额外开销仅为几次对象初始化操作。只要不对切片后的对象进行修改，就不会触发数据复制，效率下降的幅度远没有“每次复制数据”的最坏情况那么夸张。

需要关注差异的场景 #

只有当代码处于百万次以上的高频循环中调用这类切片操作时，链式切片多出来的中间对象创建、销毁开销才会累积，此时单次切片的性能优势才会显现。但这种场景在日常业务代码中极少出现。

总结 #

• 对于str和bytes，链式切片的效率损失远低于“每次复制数据”的预期，核心原因是底层采用了共享数据+引用计数的实现机制。
• 若追求极致性能且切片调用极为频繁，优先选择单次切片；若链式切片的可读性更重要，在绝大多数场景下完全可以放心使用。

内容的提问来源于stack exchange，提问作者Victoria