从明确的 Flag 边界开始
如果题目约定格式为 flag{...}，可以从字面前缀和右花括号开始：
flag\{[^}\r\n]{1,200}\}\{ 匹配字面花括号，否定字符类避免跨过右括号和换行，长度上限防止异常长匹配。相比 flag\{.*\}，它更容易解释，也不容易吞掉同一行中的多个 Flag。
边界比内容更重要
提取日志字段时，优先利用键名、引号、分隔符和行边界。例如从 JSON 风格文本中提取 request_id：
"request_id"\s*:\s*"([^"]+)"括号中的第一个捕获组才是目标值。若输入是真正 JSON，应优先使用 JSON 解析器；正则适合不完整片段、混合日志或快速定位。
常见线索模式
| 目标 | 起始模式 | 注意 |
|---|---|---|
| 64 位 Hex | \b[a-fA-F0-9]{64}\b | 只能说明形状像 SHA-256 |
| IPv4 候选 | \b(?:\d{1,3}\.){3}\d{1,3}\b | 还需验证每段不超过 255 |
| 邮箱候选 | [\w.+-]+@[\w.-]+\.[A-Za-z]{2,} | 适合提取，不是完整标准验证 |
| JWT 候选 | [A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+ | 仍需 Base64URL 与 JSON 验证 |
贪婪与非贪婪
.* 默认尽可能多地匹配。对于 key=[one] other=[two]，表达式 \[(.*)\] 可能把两个方括号之间全部吞掉。改成 \[(.*?)\] 会尽早停止，但更稳妥的是 \[([^\]]*)\]，直接说明允许的字符范围。
正则不是解析器的替代品
完整 JSON、HTML、URL 或二进制格式应使用对应解析器。正则适合筛选候选和提取局部，不适合承担复杂嵌套语法。
模式标志
g：查找全部匹配，而不只返回第一个。i：忽略大小写，使用前要确认题目是否区分大小写。m：让^和$按每一行工作。s：让点号匹配换行，可能显著扩大匹配范围。
避免性能陷阱
嵌套量词和模糊回溯在长文本上可能非常慢，例如 (a+)+$。处理未知或超长输入时，应使用明确字符类、长度上限和简单边界，并先在小样本上测试。
提取流程
- 写出一个真实样例和一个不应匹配的反例。
- 先确定左、右边界。
- 收紧中间字符范围和长度。
- 检查全局、大小写和多行标志。
- 查看捕获组，而不只看整段高亮。
- 对提取出的哈希、IP、JWT 再做语义验证。