字符串切片会复制底层字符数组。python的str切片操作（如s[10:20]）总是创建新字符串并分配独立内存，而非共享原字符串内存，这是由cpython的设计决定的。
字符串切片会复制底层字符数组吗
会。Python 的 str 是不可变对象，但底层实现中，切片操作（如 s[10:20]）在多数情况下会创建新字符串对象，并分配独立内存来存储子串内容——不是共享原字符串的内存块。
这和 CPython 的历史优化有关：早期版本为避免“长字符串持有时短切片无法释放内存”，引入了“字符串对象自带引用计数 + 独立数据缓冲区”的设计。即使你只取 3 个字符，s[1000:1003] 也会拷贝这 3 字节，而不是复用原字符串的某段地址。
常见错误现象：
— 加载一个 500MB 的日志文件到 text，反复做 text[i:i+100]，内存占用持续上涨，GC 也清不掉
— 使用 line.split()[0] 处理百万行 CSV，发现内存比原始文件还高一倍
实操建议：
• 如果只是临时检查内容（比如判断前缀），优先用 str.startswith() 或 str.endswith()，它们不生成新字符串
• 对超长文本做多次小范围提取，考虑改用 memoryview(bytearray(text, 'utf-8')) 配合字节操作（需注意编码边界）
• 不要假设 s[a:b] 是“零拷贝”——它从来就不是
立即学习“Python免费学习笔记（深入）”；
为什么 str.__getitem__ 不返回视图而是新字符串
因为 Python 的 str 接口契约要求返回 str 类型，而字符串必须是不可变且语义完整的。如果返回某种“切片视图”，就会破坏类型一致性、引发 isinstance(x, str) 意外失败，也难以支持 .upper()、.encode() 等方法。
使用场景差异：
— bytes 类型确实支持视图（memoryview(b)[10:20] 不拷贝）
— str 没有等价机制，这是设计取舍，不是 bug
参数差异：
• s[1:1000000] 和 s[1:2] 在 CPython 中调用的是同一套复制逻辑，开销主要取决于长度，而非起始偏移
• 负索引（如 s[-10:] ）会先换算成正索引再复制，无额外优化
哪些操作能绕过切片拷贝
真正避免内存复制的方法极少，且都有代价。没有银弹，只有折中。
实操建议：
• 用 re.match() 或 re.search() 提前匹配并捕获，比先切片再判断更省内存（正则引擎内部可做偏移跳转）
• 处理固定格式文本（如 HTTP header、JSON 片段），用 str.find() 定位边界，配合 str.index() 获取下标，再用元组或命名元组存 (start, end) 而非真实切片
• 如果必须大量随机访问子串，且原始字符串长期存在，可手动缓存 memoryview(bytearray(s, 'utf-8'))，但要注意：UTF-8 多字节字符不能按字节直接切，否则会得到无效序列
性能影响：
— 切片本身很快（O(n) 拷贝，n 是切片长度），但频繁小切片会触发高频内存分配，增加 GC 压力
— 在容器中存大量短切片（如列表里放十万 s[i:i+5]），实际内存占用可能是原始字符串的数倍
CPython 3.12+ 有没有改进
没有本质改变。3.12 引入了“紧凑字符串”（compact string）作为内部表示，默认启用，但它优化的是单个字符串对象的存储密度（比如 ASCII 字符只用 1 字节/字符），不是切片行为。
兼容性影响：
— 所有已有的切片代码行为完全一致，无需修改
— 第三方 C 扩展若直接访问 PyUnicodeObject 的字段（如 data 指针），可能因紧凑表示失效而崩溃——但这属于未公开 API 的误用，不是切片问题本身
容易被忽略的一点：
字符串驻留（interning）对切片无效。哪怕 s = 'hello world' 被驻留，s[0:5] 仍会新建对象，不会自动去重或复用已有 'hello' 对象。
