Python中re.match仅从开头匹配，re.search全局查找首个结果，re.findall返回所有非重叠匹配（含捕获组时只返组内容），re.sub默认全替换；JS中match带g标志丢失位置和分组信息，exec可迭代获取完整匹配；正则应预编译以提升性能并提前捕获错误；Shell中grep/sed默认BRE，awk默认ERE，跨平台需注意语法差异。
Python 的 re 模块核心函数怎么选
处理文本时，re.match、re.search、re.findall、re.sub 这四个最常用，但容易用错场景：
-
re.match只从字符串开头匹配，哪怕后面有符合的模式也无视——不是“找不找得到”，而是“开没开头就对得上” -
re.search才是真正的“全局查找”，遇到第一个匹配就停，适合判断是否存在或提取首个结果 -
re.findall返回所有**非重叠**匹配的字符串列表；如果正则含捕获组，它只返回组内容（不是整个匹配），这点常被忽略 -
re.sub默认替换全部匹配，加count=1参数才能只换第一个；注意替换字符串里用\1引用捕获组，不是$1
import re text = "id:123, name:alice, id:456" re.findall(r"id:(\d+)", text) # 返回 ['123', '456']，不是 ['id:123', 'id:456'] re.sub(r"id:(\d+)", r"ID:\1", text) # 替换为 "ID:123, name:alice, ID:456"
JavaScript 的 String.prototype.match 和 RegExp.exec 区别在哪
JS 里看似都能取匹配结果，但行为差异直接影响逻辑健壮性：
-
str.match(/pattern/)不带g标志时，返回数组（含index、input等属性）；带g时只返回纯字符串数组，**丢失捕获组和位置信息** -
regexp.exec(str)每次调用返回一个匹配结果，含完整信息，且会更新lastIndex（支持手动控制迭代），适合需要精确控制匹配过程的场景 - 全局正则对象（
/pattern/g）在多次exec调用间保持状态，重复使用前记得regex.lastIndex = 0或重建正则，否则可能漏匹配
const str = "a1b2c3"; const regG = /\d/g; console.log(str.match(regG)); // ['1', '2', '3'] —— 没位置、没分组 const reg = /(\d)/; console.log(reg.exec(str)); // ['1', '1', index: 1, input: 'a1b2c3'] console.log(reg.exec(str)); // ['2', '2', index: 3, input: 'a1b2c3']
为什么 re.compile 在 Python 里不是可选项而是必选项
频繁使用的正则如果不预编译，性能损耗明显，而且容易掩盖错误：
10分钟内自己学会PHP
下载
10分钟内自己学会PHP其中，第1篇为入门篇，主要包括了解PHP、PHP开发环境搭建、PHP开发基础、PHP流程控制语句、函数、字符串操作、正则表达式、PHP数组、PHP与Web页面交互、日期和时间等内容；第2篇为提高篇，主要包括MySQL数据库设计、PHP操作MySQL数据库、Cookie和Session、图形图像处理技术、文件和目录处理技术、面向对象、PDO数据库抽象层、程序调试与错误处理、A
- 每次调用
re.search(pattern, text)都会隐式编译一次正则，若 pattern 是变量或循环内拼接，等于反复解析同一模式 -
re.compile(pattern)返回Pattern对象，可复用、可传参（如flags=re.I）、可检查是否编译成功（避免运行时才发现语法错） - 编译后的对象方法（
pattern.search()、pattern.sub()）比模块级函数快 2–5 倍，尤其在循环中差异显著 - 注意：
re.compile编译失败抛re.error，不是SyntaxError，需单独捕获
import re
# ❌ 低效且难调试
for line in lines:
if re.search(r"\d{4}-\d{2}-\d{2}", line):
...
✅ 推荐写法
date_pattern = re.compile(r"\d{4}-\d{2}-\d{2}")
for line in lines:
if date_pattern.search(line):
...
Shell 中 grep、sed、awk 正则能力边界在哪
命令行文本处理常混用三者，但默认正则引擎不同，导致行为不一致：
-
grep默认用 BRE（基本正则），+、?、{n,m}需加反斜杠才生效（\+）；加-E切换 ERE，此时括号和竖线不用转义 -
sed默认也是 BRE，s/pat/repl/中的pat不支持+，想匹配“一个或多个数字”得写[0-9][0-9]*或用sed -E -
awk默认支持 ERE，+、?、(...|...)直接可用，且内置字段分割逻辑，比单纯 grep 更适合结构化提取 - 跨平台注意：
macOS sed不支持-E，得用gsed（brew install gnu-sed）
# Linux/macOS 差异示例（匹配连续数字）
echo "abc123def" | grep -E "[0-9]+" # ✅ 大部分 Linux 支持
echo "abc123def" | sed -E "s/[0-9]+/NUM/" # macOS 原生 sed 不认 -E
echo "abc123def" | awk '{gsub(/[0-9]+/, "NUM"); print}' # ✅ awk 通用正则函数本身不复杂，真正卡住人的往往是隐式行为：Python 的捕获组返回规则、JS 全局正则的状态残留、Shell 各工具的正则方言差异。用之前先确认引擎类型和标志位影响，比死磕 pattern 本身更省时间。
