该用 str.replace() 而不是 re.sub() 时：进行简单字面替换且无模式需求，因前者更快、更安全、更易读，不解析正则元字符，避免 re.error。
什么时候该用 str.replace() 而不是 re.sub()
简单字面替换，无模式需求时，str.replace() 更快、更安全、更易读。它不解析正则元字符，不会因误传 *、.、[ 等触发 re.error。
- 替换固定字符串：
"abc".replace("a", "x")→"xbc"；若用re.sub("a", "x", "abc")，功能等价但多出编译和匹配开销 - 批量替换多个不同子串？别硬套
re.sub()，改用链式replace()或字典映射 +str.translate() - 想替换所有空格为下划线？直接
s.replace(" ", "_")，别写re.sub(r" ", "_", s)—— 没必要引入正则引擎
re.findall() 和 str.split() 怎么选
要提取分隔符之间的内容，且分隔符**固定、无歧义、不嵌套**，优先用 str.split()。它更快、不依赖正则语法、返回结果更直观。
-
"a,b,c".split(",")→["a", "b", "c"]；用re.findall(r"[^,]+", "a,b,c")也能得到类似结果，但逻辑绕、难维护 - 分隔符本身也要保留？
str.split()不支持，此时必须用re.split()（注意括号捕获会把分隔符也纳入结果） - 需要按多种空白（\t、\n、多个空格）统一切分？
re.split(r"\s+", s)更合适；str.split()默认行为虽也处理各种空白，但无法自定义“至少两个空白才切”这类规则
为什么 re.match() 经常“不工作”，而 re.search() 可以
re.match() 只从字符串开头匹配，哪怕只差一个空格或换行就失败；re.search() 在整个字符串中查找，行为更接近直觉。
- 验证邮箱格式？别用
re.match(r"[^@]+@[^@]+\.[^@]+", s)—— 如果字符串开头有空格或提示文字（如"Email: user@example.com"），它直接返回None - 真正需要“必须开头就满足”的场景才用
match()，比如解析协议头"HTTP/1.1 200 OK"，或校验文件路径前缀/usr/bin/ - 绝大多数表单校验、日志提取、配置解析，应默认用
re.search()或带^锚定的re.fullmatch()
re.compile() 不是“可选优化”，而是关键安全点
在循环里反复调用 re.search(pattern, s)，等于每次重新编译正则——不仅慢，还可能因用户输入含未转义元字符导致异常或误匹配。
立即学习“Python免费学习笔记（深入）”；
- 高频使用同一模式（如日志行解析、参数校验），务必提前
pattern = re.compile(r"\d{4}-\d{2}-\d{2}")，再在循环中调用pattern.search(s) - 用户可控输入作为 pattern？必须用
re.escape(user_input)包裹，否则user_input = "3.14"会被当作“3任意字符14”，而非字面量 - 编译后的
Pattern对象可跨线程安全复用，但不能跨进程共享（需在每个进程中重新compile）
import re
<h1>✅ 推荐：预编译 + 转义用户输入</h1><p>date_pattern = re.compile(r"\d{4}-\d{2}-\d{2}")
user_keyword = re.escape("[important]")
keyword_pattern = re.compile(user_keyword)</p><h1>❌ 避免：每次调用都编译，且未处理用户输入特殊字符</h1><h1>for line in logs:</h1><h1>if re.search(r"\d{4}-\d{2}-\d{2}", line): ...</h1><h1>if re.search(user_keyword, line): ... # user_keyword = "[important]" → 匹配 "iportant"</h1>正则不是银弹，字符串方法也不是过时工具。关键在分清：你要的是「精确位置控制」还是「语义化提取」，是「一次解析」还是「高频复用」——选错，轻则性能掉一截，重则漏匹配或炸出 re.error。
