可在location块直接启用access_log并引用http块定义的log_format，需确保变量在该作用域存在（如proxy_pass下$upstream_response_time可用），通过set/map提前提取业务变量（如$order_id、$env_name）并写入日志格式。
可以直接在 location 块里启用 access_log 并引用自定义 log_format，无需额外模块。关键在于格式定义位置、变量可用性、作用域控制三者配合——不是所有变量在任意 location 都能取到值。
在 http 块中定义 log_format
log_format 必须写在 http { } 块内，不能放在 server 或 location 里：
- 名称唯一，比如叫 api_metric，后续通过名字引用
- 可嵌入业务强相关字段：$upstream_response_time（代理场景）、$request_id（链路追踪）、$arg_order_id（提取 URL 参数）、$sent_http_x_rate_limit_remaining（响应头）
- 示例：log_format api_metric '$remote_addr [$time_local] "$request" $status $body_bytes_sent $request_time $upstream_response_time $request_id "$http_x_forwarded_for"';
在目标 location 中启用并绑定格式
location 是作用域边界，log_format 在此生效的前提是变量实际存在且可读取：
- 若 location 内含 proxy_pass，$upstream_* 类变量可用；纯静态服务则无 upstream 相关值
- 用 access_log /var/log/nginx/order.log api_metric; 启用该格式，路径需 Nginx 进程有写权限
- 避免继承父级日志：不写 access_log 即继承 server 级配置；显式写即覆盖
按需注入业务上下文变量
仅靠内置变量不够时，用 set 或 map 提前提取或映射关键标识：
- 在 location 内用 set $log_order_id $arg_order_id; 提取订单号参数
- 在 http 块顶层用 map $host $env_name { default prod; ~^staging\. api staging; } 统一标记环境
- 然后把 $log_order_id 或 $env_name 直接写进 log_format 字符串里
验证与调试要点
配置 reload 后需确认日志是否真实产出、字段是否符合预期：
- 触发请求：curl -s "https://your.site/api/v2/order?order_id=1001"
- 实时查看：tail -f /var/log/nginx/order.log，检查 order_id 是否落进日志
- 若字段为空，先 nginx -t 检查语法；再确认变量来源是否存在（如 $arg_order_id 要求 URL 真有该参数）
- 注意：$sent_http_* 类变量只在响应头已生成后才可用，若 location 未返回响应（如内部重定向），可能为空
