必须用 $request_time 字段精准匹配，其格式为带三位小数的秒级数字（如1.234），位于$status和$body_bytes_sent之间，由log_format显式定义；若日志中无此字段，需修改nginx配置并重载。
必须用 $request_time 字段匹配，不能靠模糊关键词或数字通配；否则会把 $msec、$body_bytes_sent 甚至日志里的 URL 参数都错当耗时。
确认日志里真有 $request_time 字段
打开任意一条 access.log，找形如 1.234 或 0.008 这样带三位小数的秒级数字——它得出现在 $status 和 $body_bytes_sent 之间，且由 Nginx 的 log_format 显式定义为 $request_time。如果看到的是 1719235422 这种整数，那是 $msec（毫秒时间戳），不是响应耗时，不能用。
- 没这个字段？得改 Nginx 配置，在
log_format行加上$request_time，再执行nginx -s reload - 历史日志无法补全，别试图用正则“猜”耗时
- 有些日志用
$upstream_response_time，语义不同（只计后端响应），但格式一样，可同样提取
写能稳抓 $request_time 的正则（不跨行、不误捕）
标准日志行示例：192.168.1.100 - - [02/Jul/2026:15:23:44 +0000] "GET /api/v1/users?id=123 HTTP/1.1" 200 2345 "https://example.com" "curl/7.68.0" 1.234 0.987。目标是精准捕获最后那个 1.234，并顺带拿到前面的 URL。
Toingg Ops Toolkit
下载
一款AI音频处理工具，主要用于通过向 `toingg/make_campaign` API 发送 POST 请求，提交用户提供的 JSON 数据，创建并启动 Toingg 语音呼叫活动，适用于 Codex 将活动简报……，适合需要提升相关任务效率的用户。
- 推荐正则：
"([A-Z]+)\s+([^"]+)"\s+\d{3}\s+\d+\s+"[^"]*"\s+"[^"]*"\s+(\d+\.\d{3})\s+ -
$1是方法（GET），$2是完整 URL（/api/v1/users?id=123），$3是request_time（1.234） - 必须用
\s+(\d+\.\d{3})\s+而非\d+\.\d{3}：前后加空白符锚定，避免匹配到123.456.789中间那段 - 别用
.*request_time.*——日志里没有字面量request_time，那是 Nginx 变量名，实际写入的是纯数字
替换导出为制表分隔格式（URL + 耗时）
Find All 匹配后，用替换功能一次性生成干净结果，比手动复制快且不易漏行。
- 打开替换面板（
Ctrl+H），勾选Regular Expression - Find What 填上面的正则，Replace With 填：
$2\t$3（\t是制表符，粘贴到 Excel 或 CSV 工具里自动分列） - 点
Replace All，所有匹配行被替换成/api/v1/users?id=123 1.234这样的两列数据 - 若只想看 ≥1 秒的慢请求，先全量提取，再在 Sublime 里按
Ctrl+Shift+P→Sort Lines，从大到小排$3列，人工扫顶部几行即可
真正容易被忽略的是：正则里 \s+ 的松紧度——太松会吞掉中间字段导致捕获错位，太紧又可能因日志中空格数量浮动而漏匹配；实操中建议先用单行日志测试，确认 $1、$2、$3 各自捕获内容准确，再批量跑。
