Jev Search 打开就是空白页——是前端没连上后端还是模型服务没起？

Jev Search 打开是空白页通常不能直接归到「前端没连上后端」或「模型服务没起」其中一边。更可行的做法是分层验证先在浏览器里确认前端到底发了什么请求、收到什么响应再绕开页面直接请求后端接口接着确认后端到模型服务的连通性最后用后端日志把现象落到具体环节。只有当某一层出现明确失败才继续往下追否则很容易在错误的方向上反复改配置。下面按这个顺序给出每层要看的信息、可执行的验证动作以及现象与环节的对照。空白页多数是请求链路在某一层断开、前端拿不到可渲染数据所致。建议按「浏览器控制台 → 后端接口 → 模型服务 → 后端日志」的顺序排查每层都有可判断的通过标准控制台无失败的业务请求、接口能返回结构正常的响应、模型服务能从后端所在机器连通。任一层不通时先修那一层不要同时改前端和后端配置否则失败点会互相掩盖。先看浏览器控制台和网络面板里的失败请求打开开发者工具的 Network 面板勾选 Fetch/XHR 和 JS再刷新页面。要记录的是三样东西失败请求的完整路径、HTTP 状态码、响应体前几行很多后端会返回 code 和 message 字段。如果有多个请求按时间顺序看第一个失败的后面的往往是被连带影响的。区分前端渲染失败和请求失败看的是有没有业务接口请求这一层Network 里只有静态资源JS/CSS/字体404 或加载失败没有任何业务接口请求同时 Console 里有 JS 报错——更可能是构建产物没部署对、静态资源路径或 base 路径配错、前端挂载点为空属于渲染侧问题。业务接口请求存在但返回 4xx、5xx、CORS 报错或长时间 pending 后失败——属于请求侧问题问题在后端或中间的转发链路。所有请求都是 200但页面依然空白——接口通了前端拿到的字段结构和它预期的不一致或者渲染时读到了空数据。Console 里的 Cannot read properties of undefined 之类报错通常属于这一类不要直接当成后端故障。Console 里出现 Failed to fetch、NetworkError、被 CORS policy 拦截基本指向请求层这类报错本身不区分是后端没起还是跨域没放行需要下一步的直连请求来确认。绕开前端直接对后端接口发一次请求在部署后端的那台机器上不是自己的电脑执行避免被本机网络环境干扰。下面只是通用骨架地址、端口、路由、令牌、字段名都按实际配置替换不要照抄路径。# GET 探测 curl -i --max-time 5 \ -H Accept: application/json \ -H Authorization: Bearer 你的令牌 \ http://127.0.0.1:后端端口/实际路由 # POST 探测请求体字段以实际接口契约为准 curl -i --max-time 5 \ -H Content-Type: application/json \ -H Authorization: Bearer 你的令牌 \ -d {query:test} \ http://127.0.0.1:后端端口/实际路由结果怎么读返回 200 且响应体是可解析的 JSON说明后端进程在监听、路由也对空白页的成因更可能在前端配置或跨域连接被拒绝说明后端没起或端口写错401、403 说明鉴权头或密钥配置有问题404 往往是路由前缀不一致比如前端请求带 /api 而网关没有对应的转发规则5xx 说明后端自己在处理过程中出错需要看它的日志。这一步只回答「后端本身通不通」不解释模型侧。确认模型服务是否可达Jev Search 的搜索或问答链路一般会调模型服务模型侧挂掉时后端接口的典型表现是先卡住一段时间再返回超时或 5xx而不是立刻报错。检查要在后端所在机器上做因为后端的出网路径和你的电脑不一定一样。# 有健康检查或版本路径时 curl -i --max-time 5 http://模型服务地址:端口/实际健康检查路径 # 不确定路径时先只确认 TCP 能否建立 curl -v --max-time 5 http://模型服务地址:端口/ 21 | head -n 20连不通时的典型表现connection refused 表示目标端口没有进程在监听模型服务可能没启动或端口与配置不一致timeout、context deadline exceeded 表示请求发出但没收到应答常见于地址写错、防火墙未放行或模型服务还在加载权重返回 401、403 表示地址可达但密钥或鉴权头没配对返回 404 但 TCP 已建立说明服务在跑、只是路径不对。一个很有用的旁证是后端日志记录了失败但模型服务日志里完全没有对应的请求记录通常说明请求根本没到模型侧问题在中间这一段。对照后端日志把错误落到具体环节把浏览器里那次失败请求的时间戳和同一时刻的后端日志对齐日志关键字通常能直接指出断点在哪一段日志关键字或现象指向的环节connection refused、dial tcp 失败目标进程没监听确认后端或模型服务已启动端口与配置一致timeout、deadline exceeded请求已发出但无应答查网络与防火墙或模型服务是否卡在加载401、403、invalid api key、unauthorized鉴权失败检查密钥、令牌以及是否注入了运行环境404、no route、not found路由或前缀不匹配检查前端 base 路径、网关转发规则502、504网关到上游不通上游可能是后端或模型服务响应解析失败、字段缺失链路已通但返回结构不符合后端预期属于契约问题需要强调的是同一句报错在不同部署形态下指向可能不同比如反向代理的 502 既可以来自后端崩溃也可以来自模型服务不可达。判断依据是同一时间点上哪一层先出现异常日志而不是孤立的报错文案。把每层的最小验证动作固定成清单下次再遇到空白页按下面五步走每步只做一件事改完只重测这一步浏览器 Network 面板刷新页面。执行动作记录失败请求的路径、状态码、响应体。通过标准能明确回答业务接口请求有没有发出去、结果是什么。在后端机器上 curl 直连后端接口。执行动作用上面的骨架替换成实际路由。通过标准返回预期状态码和可解析的响应结构。从后端机器 curl 模型服务的健康检查或根路径。执行动作观察返回码或 TCP 是否建立。通过标准连通且返回正常或明确拿到拒绝、超时这类可解释的结果。对齐后端日志时间戳。执行动作找到那次失败对应的日志行。通过标准能说出失败发生在连接、鉴权、超时还是解析环节。只改一处配置后重测同一条命令。执行动作用第 2、3 步相同的命令复测。通过标准原来的失败变成通过再回到浏览器验证页面是否可以渲染。如果第 2 步和第 3 步都通过而页面仍然空白问题基本落在前端构建产物、静态资源路径或接口返回结构与前端预期不一致上这时应该继续看 Network 里的响应体而不是再去动模型服务的配置。