Nginx 不支持在 access_log 中直接使用 if 判断，但可通过 map 指令生成条件变量控制日志路径（空字符串则不记录），配合多 access_log 指令实现选择性日志记录。
Nginx 本身不支持在 access_log 指令中直接使用 if 条件判断来动态开启或关闭日志记录，因为 if 在日志上下文中是被禁止的（Nginx 官方明确说明 if 不可用于 access_log）。但可以通过「变量 + map 指令」配合日志格式控制，实现“选择性记录”——即让不满足条件的请求写入空日志行、丢弃、或写入独立文件。
用 map 定义条件变量控制日志路径
这是最常用且推荐的方式：先用 map 根据请求特征（如 URI、状态码、User-Agent）生成一个变量，再将该变量用于 access_log 的路径参数。Nginx 会跳过值为空字符串（""）的日志路径，从而实现“不记录”。
示例：只记录非健康检查（/healthz）和返回状态非 200 的请求到主日志，其他跳过：
map $request_uri $loggable {
default "1";
~^/healthz "";
}
<p>map $status $loggable_by_status {
~^[2] ""; # 状态码以 2 开头（如 200、204）不记
default "1";
}</p><h1>合并逻辑：两个条件都满足才记录（AND）</h1><p>map "$loggable:$loggable_by_status" $should_log {
"1:1" "/var/log/nginx/access.log";
default ""; # 空字符串 → 不写日志
}</p>然后在 server 或 location 块中使用：
access_log $should_log main;
用 log\_format 配合变量隐藏敏感或冗余字段
虽然不能跳过整条日志，但可以控制日志内容是否输出。比如对某些 UA 或内网 IP，把关键字段（如 $request、$args）设为空：
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
map $http_user_agent $safe_request {
~*(curl|httpie|monitor) "-";
default "$request";
}
<p>log_format selective '$remote_addr - $remote_user [$time_local] '
'"$safe_request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';
access_log /var/log/nginx/selective.log selective;</p>这样监控脚本的请求仍会写日志，但 request 字段显示为 "-"，降低信息量。
分离日志：把符合条件的请求单独记录到另一文件
更清晰的做法是“正向筛选”，把需要特别关注的请求（如错误、API 调试、特定用户）单独记日志，主日志保持默认记录：
# 记录所有 5xx 错误到 error_api.log
map $status $log_to_error_api {
~^5 "/var/log/nginx/error_api.log";
default "";
}
access_log $log_to_error_api main;
<h1>主日志继续记录全部（或按需 exclude）</h1><p>access_log /var/log/nginx/access.log main;</p>注意：多个 access_log 指令可共存，Nginx 会依次执行，适合做多路日志分流。
不推荐但偶见的 hack 方式：用空文件 + null 设备
有些方案尝试用 access_log /dev/null 配合 if，但 if 无法嵌套进 access_log，以下写法无效：
if ($request_uri = "/favicon.ico") { access_log off; } ❌（语法错误）
正确替代是：用 location = /favicon.ico { access_log off; } —— 这是在 location 级别关闭日志，适用于固定路径，灵活性较低。
本质上，Nginx 的日志开关粒度在 location 或变量驱动路径层面，而非运行时 if 判断。合理组合 map、log_format 和多 access_log 指令，就能干净地实现按需记录。
