核心在于全链路透传、统一生成、日志标准化输出：Nginx入口统一生成request_id并透传，后端从X-Request-ID读取并注入MDC日志上下文，前端获取后携带至后续请求，最终在ELK/SLS中凭该ID一键串联全链路日志。
在分布式系统中，通过 $request_id 实现前后端请求的一键关联，核心在于：**全链路透传、统一生成、日志标准化输出**。只要每个中间节点（Nginx、后端服务、前端埋点）都携带并记录同一个 request_id，就能在 ELK、SLS 或其他日志平台中用一个 ID 快速串联起一次完整请求的全部日志。
1. 在 Nginx 层统一生成并透传 $request_id
Nginx 作为入口网关，是最适合统一生成和注入 request_id 的位置。它能避免后端重复生成，也确保即使请求未到达应用层，也有 ID 可查。
- 使用
ngx_http_secure_link_module或更常用的是map+random模块（需编译支持）生成 UUID；但更推荐用lua-resty-random或 OpenResty 的resty.uuid模块生成标准 UUIDv4 - 若用 OpenResty，在
http块中定义：lua_package_path "/path/to/lua-resty-uuid/lib/?.lua;;"; init_by_lua_block { require "resty.uuid" } map $time_iso8601 $request_id { default ""; } server { listen 80; location / { set $req_id ""; access_by_lua_block { local uuid = require "resty.uuid" local ok, id = uuid:generate() if ok then ngx.var.req_id = id else ngx.var.req_id = ngx.md5(ngx.now() .. ngx.var.remote_addr .. math.random(10000, 99999)) end } proxy_set_header X-Request-ID $req_id; proxy_pass http://backend; } } - 务必把
X-Request-ID透传给后端（proxy_set_header），同时自身 access log 中记录该字段：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_request_id"';
2. 后端服务主动读取并注入日志上下文
后端不自行生成 request_id，而是优先从 X-Request-ID Header 中读取。若缺失，再按需生成（仅作兜底，避免空 ID）。
- Spring Boot 示例：用
OncePerRequestFilter提前提取并存入 MDC（Mapped Diagnostic Context） - 代码片段：
@Component public class RequestIdFilter extends OncePerRequestFilter { @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException { String reqId = Optional.ofNullable(request.getHeader("X-Request-ID")) .filter(id -> !id.trim().isEmpty()) .orElse(UUID.randomUUID().toString()); MDC.put("request_id", reqId); try { filterChain.doFilter(request, response); } finally { MDC.remove("request_id"); } } } - Logback 配置中启用
%X{request_id}，例如：%d{yyyy-MM-dd HH:mm:ss.SSS} [%X{request_id}] [%thread] %-5level %logger{36} - %msg%n - Node.js（Express）可用
cls-hooked或简单中间件挂载到res.locals+ winston 的 format 添加字段
3. 前端主动采集并带上 request_id 发起后续请求
用户首次访问时，Nginx 已在响应头中写入 X-Request-ID。前端可在页面初始化时读取，并用于后续所有 API 请求。
- 在 HTML 模板或首屏 JS 中获取响应头（需服务端允许 CORS 暴露）：
Access-Control-Expose-Headers: X-Request-ID - 示例（fetch 封装）：
let globalRequestId = ''; // 首次加载时从 document.responseHeader 获取（实际需用 fetch + Response.headers） // 更可靠方式：服务端渲染模板时注入 window.__INITIAL_REQUEST_ID__ = 'xxx' fetch('/api/init').then(r => { globalRequestId = r.headers.get('X-Request-ID') || ''; }); // 后续请求自动携带 function api(url) { return fetch(url, { headers: { 'X-Request-ID': globalRequestId } }); } - Vue/React 可结合 axios 拦截器或自定义 Hook 统一注入
- 注意：WebSocket、图片资源等非 XHR 请求无法自动带 header，可改用 URL query（如
?_rid=xxx）并在后端解析补全
4. 日志平台中一键检索与链路还原
当日志中每条记录都含 request_id 字段（Nginx access log、后端业务日志、前端上报日志），即可在日志系统中直接搜索该 ID 查看完整链路。
- ELK 中：Kibana 使用
request_id: "a1b2c3..."查询，按@timestamp排序，天然呈现时间线 - SLS（阿里云日志服务）：用
* | select * where request_id = 'xxx'，支持关联分析（如统计该请求下各服务耗时、错误码分布） - 进阶技巧：在日志中额外打点关键阶段，例如
"stage": "nginx-enter"、"stage": "service-db-query"，便于快速定位瓶颈环节 - 前端日志建议上报时也带上
request_id和page_url、user_id等上下文，实现“用户行为 → 请求链路 → 后端异常”闭环排查
