字符串切片生成新对象而非修改原字符串，因str不可变；负步长时start需大于end，越界不报错但易掩藏bug，关键截取前应校验长度。
字符串切片本质是生成新对象，不是修改原字符串
Python 中 str 是不可变类型，所有切片操作（如 s[2:5]）都返回一个**全新字符串对象**，原字符串 s 完全不变。这点常被误认为“截取后原字符串变短了”，其实只是变量重新指向了新对象。
实操建议：
- 若需多次截取同一长字符串的多个片段，直接用切片即可，无需担心性能——CPython 对字符串切片做了优化，底层用的是内存视图（
PyStringObject的偏移+长度），不立即拷贝内容，直到你真正使用该切片结果 - 但一旦对该切片结果做拼接、编码、正则匹配等操作，就会触发实际拷贝，此时内存占用会翻倍
- 避免在循环中反复切片超长字符串（比如日志行解析），可先用
re.finditer()或str.partition()定位关键位置，再统一切
负索引和省略步长的边界行为必须手动验证
切片语法 s[start:end:step] 中，负索引从末尾计数（-1 是最后一个字符），但 start 和 end 在 step 为负时含义反转——这容易导致空结果或 IndexError 感觉不到的逻辑错误。
常见错误现象：用 s[::-1] 反转没问题，但写成 s[5:-1:-1] 却返回空字符串，因为起始位置 5 已经在终止位置 -1 的右侧，而步长为负时要求 start > end 才能有值。
立即学习“Python免费学习笔记（深入）”；
实操建议：
-
start和end未指定时默认为None，解释器会自动映射为边界值（如s[:]→s[0:len(s):1]），但s[::-1]实际等价于s[-1:-len(s)-1:-1] - 对负步长切片，优先用
s[::-1]或s[end:start:-1]形式，避免混用正负索引 - 调试时直接打印
list(range(*slice(start, end, step).indices(len(s))))，能看清实际遍历哪些下标
切片越界不会报错，但可能掩盖数据异常
Python 切片天然容错：s[100:200] 对长度为 10 的字符串返回空字符串 ''，s[3:100] 返回 s[3:]。这方便编码，但也让“本该存在却没取到”的 bug 难以暴露。
使用场景：解析固定格式文本（如 CSV 某列总在第 5–12 字符）时，若源数据某行意外缩短，切片静默返回空，后续 int() 转换才抛 ValueError，错误位置远离问题源头。
实操建议：
- 关键字段截取前加长度校验：
if len(s) - 用
s.split(sep, maxsplit=1)替代基于位置的切片，语义更清晰且自带分隔符容错 - 正则
re.match(r"^(\w{3})-(\d{4})-(\w+)", s)比s[0:3], s[4:8], s[9:]更健壮
大量小切片拼接时，用 join() 而非 +=
频繁用 result += s[i:j] 拼接多个切片，在 CPython 中因字符串不可变，每次 += 都创建新对象，时间复杂度接近 O(n²)。
性能影响：处理 10 万次切片拼接，+= 可能比 ''.join(list_of_slices) 慢 5–10 倍，尤其当切片本身很短（如单字符）时更明显。
实操建议：
- 收集所有切片结果进列表：
parts = [s[i:j] for i,j in ranges]，最后''.join(parts) - 若切片位置连续（如提取所有偶数位字符），改用生成器表达式：
''.join(s[i] for i in range(0, len(s), 2)) - 极端性能场景（如日志实时解析），考虑用
bytearray预分配缓冲区，再用memoryview写入切片字节
切片看着简单，但 start/end 的隐式转换、负步长的方向陷阱、以及静默越界，每个都可能在数据规模变大或格式微调后突然爆发。动手前花十秒想清楚索引是否真覆盖了你想取的全部字符，比事后查半天空字符串来得实在。
