Python字符串不可变性导致每次操作都生成新对象，引发O(n²)拼接、编码转换开销、正则重复编译及切片退化拷贝等问题，应使用join、预编译正则、避免冗余encode等优化。
字符串不可变性直接决定每次操作都产生新对象
Python 的 str 是不可变类型，这意味着任何看似“修改”字符串的操作（比如 replace()、upper()、拼接 +）都会分配一块新内存，复制全部字符。不是在原地改，而是重建——这是所有成本的起点。
常见错误现象：在循环里反复拼接字符串，如 s = "" 然后 s += item，时间复杂度是 O(n²)，因为第 i 次迭代都要复制前 i−1 个字符。
- 用
list缓存片段，最后''.join()——这是标准解法，join()内部做一次预计算长度 + 单次内存分配 -
io.StringIO适合需要类文件接口的场景，但比list + join多一层封装开销 - 避免对长字符串频繁调用
split()后又join()，尤其当只改其中一两段时，考虑用re.sub()或切片重组
编码转换隐含内存拷贝和查表开销
Python 字符串以 Unicode 码点为逻辑单位存储（CPython 中是 UTF-32-like 内部表示），但 encode() / decode() 必须遍历每个字符做编码映射。对含中文、emoji 的字符串，这不只是复制，还涉及查 Unicode 数据库、处理代理对、验证合法性。
典型高开销场景：HTTP 响应体反复 body.encode('utf-8') 发送；或日志中对同一字符串不断 str(msg).encode()。
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 如果确定后续只用于传输（如 HTTP），尽早 encode 成
bytes并复用，别留着str反复转 -
latin-1编码零开销（1:1 字节映射），仅当数据纯 ASCII 或你明确控制字节范围时可用 - 避免在热路径里用
str.encode(encoding=dynamic_var)，动态 encoding 名会触发额外字符串查找和注册表查询
正则匹配与替换的预编译不是可选项，是必须项
每次调用 re.sub(pattern, repl, text) 且 pattern 是字符串时，CPython 都会先查缓存、未命中则解析正则 AST、编译成字节码、再执行。对固定 pattern，这个解析+编译成本远高于匹配本身，尤其 pattern 含复杂断言或嵌套组时。
错误写法：[re.sub(r'\d+', 'X', s) for s in huge_list] —— 每次都重新编译。
- 一律用
re.compile(r'\d+')得到Pattern对象，再调用其.sub()方法 - 注意
re模块内部有默认缓存（默认 maxsize=512），但不保证你的 pattern 一定被缓存住，也不保证缓存不被淘汰 - 若 pattern 含运行时变量，用
f-string拼接后仍要re.compile()，别以为“只拼一次”就安全——拼接字符串仍是新对象，缓存键不同
切片操作看似廉价，但小步长或大跨度会失效优化
Python 对 s[a:b] 做了内存视图优化：如果步长为 1 且起止索引合法，底层直接构造新字符串对象指向原内存的子区间（copy-on-write 语义）。但一旦步长 ≠ 1（如 s[::2]）、或涉及负索引需换算、或切片结果跨多个内存页，就会退化为逐字符拷贝。
性能陷阱：用 s[::-1] 反转长字符串；或 s[0:len(s)//2] 切一半却触发完整复制（因 len(s)//2 是运行时值，无法静态判定是否连续）。
- 确认是否真需要新字符串：若只是遍历，用
reversed(s)或range(len(s)-1,-1,-1)避免分配 - 反转需求强烈且频繁，考虑提前存
s_reversed = s[::-1]复用，而非每次计算 - 用
memoryview(bytearray)替代字符串切片做二进制处理——绕过 Unicode 层，但仅适用于纯 ASCII 或已知编码的 bytes 场景
真正影响性能的往往不是单次操作，而是不可变性 + 隐式编码 + 正则解析 + 切片语义这些机制叠加后的组合效应。调试时别只看函数耗时，得看它背后触发了多少次内存分配和字符遍历。
