正则表达式适用于基于字符串模式的局部匹配与提取，如日志过滤、表单校验、注释提取、URL参数捕获；不适用于嵌套结构、语义理解或上下文依赖任务。
正则表达式能处理哪些文本任务
正则表达式不是万能的，它只适合解决「基于字符串模式的局部匹配与提取」类问题。一旦涉及嵌套结构（如 HTML 标签嵌套、JSON 层级）、语义理解（如判断“这句话是否在批评产品”）、或上下文依赖（如“the”后面跟名词才匹配），就该换用语法分析器、NLP 工具或专用解析库。
典型适用场景包括：
- 日志行过滤（^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2} 匹配时间戳）
- 表单校验（^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$ 粗略验证邮箱格式）
- 代码注释提取（//.*$ 或 /\*[\s\S]*?\*/）
- URL 路径参数拆解（/user/(\d+)/profile 中捕获 \d+）
哪些语言和工具默认支持正则
几乎所有现代编程语言都内置正则引擎，但实现细节和默认行为差异很大。关键不是“能不能用”，而是“用哪个 flavor”和“要不要转义”。
- JavaScript：使用
/pattern/g字面量或RegExp构造函数，不支持\K和原子组(?>...) - Python：
re模块默认 POSIX BRE 风格，re.compile()支持flags=re.DOTALL；regex第三方库才支持逆序环视等高级特性 - Shell（grep/sed/awk）：
grep -E启用 ERE，sed -r（GNU）或sed -E（macOS）启用扩展语法，但不支持 Unicode 属性类如\p{L} - Java：
java.util.regex支持\Q...\E引用字面量，但String.replaceAll()中第一个参数是正则，第二个是替换字符串——容易误把$1当普通字符
常见踩坑点：看似能用，实则危险
正则写出来能跑通测试用例，不代表它在线上安全。尤其要注意回溯爆炸、Unicode 处理偏差和边界条件遗漏。
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
-
.*在非贪婪模式下仍可能引发灾难性回溯，比如匹配a+b+c+d+...类重复结构时，应改用原子组或占有量词（如果引擎支持） -
\w在 Python 2 默认只匹配 ASCII，在 Python 3 默认开启 Unicode 模式，但 Java 的\w始终不含中文，需显式写[\w\u4e00-\u9fa5] - 用
^/$判断整串匹配时，忘了换行符存在——^foo$会匹配多行字符串中的某一行，而\Afoo\Z才强制锚定全文首尾 - 替换时误用
$1而不是\1（如 JavaScript 中replace()用$1，而 sed 中用\1）
什么时候该放弃正则，直接切分或解析
当出现以下任意一种情况，立刻停手，换方案：
- 需要提取嵌套括号内容，例如从
func(a(b,c), d)中完整取出a(b,c)—— 正则无法计数，用递归下降或栈解析 - 要校验 CSV 行，字段含逗号和引号（
"a,b",c,"d""e"）——用csv模块，别自己写/"([^"]*)"|([^,]+)/g - 从 HTML 中取某个 class 的文本内容——用
BeautifulSoup或DOMParser，正则遇到属性顺序变化、自闭合标签、注释就会崩 - 做自然语言分词或词性标注——交给
spaCy或jieba，正则连“iPhone X”和“iPhone14”都难统一对待
正则真正的价值不在“看起来很酷”，而在于它足够轻、足够快、足够嵌入到 grep / vim / Nginx rewrite 等不支持复杂逻辑的环境里。滥用它的“能力”，往往是因为没看清它本质只是个字符串扫描机。
