企业官网建设流程全解析

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://模型服务地址:端口/' 2>&1 | head -n 20

连不通时的典型表现：connection refused 表示目标端口没有进程在监听，模型服务可能没启动或端口与配置不一致；timeout、context deadline exceeded 表示请求发出但没收到应答，常见于地址写错、防火墙未放行，或模型服务还在加载权重；返回 401、403 表示地址可达但密钥或鉴权头没配对；返回 404 但 TCP 已建立，说明服务在跑、只是路径不对。一个很有用的旁证是：后端日志记录了失败，但模型服务日志里完全没有对应的请求记录，通常说明请求根本没到模型侧，问题在中间这一段。

对照后端日志把错误落到具体环节

把浏览器里那次失败请求的时间戳，和同一时刻的后端日志对齐，日志关键字通常能直接指出断点在哪一段：

需要强调的是，同一句报错在不同部署形态下指向可能不同，比如反向代理的 502 既可以来自后端崩溃，也可以来自模型服务不可达。判断依据是同一时间点上哪一层先出现异常日志，而不是孤立的报错文案。

把每层的最小验证动作固定成清单

下次再遇到空白页，按下面五步走，每步只做一件事，改完只重测这一步：

1. 浏览器 Network 面板刷新页面。执行动作：记录失败请求的路径、状态码、响应体。通过标准：能明确回答业务接口请求有没有发出去、结果是什么。
2. 在后端机器上 curl 直连后端接口。执行动作：用上面的骨架替换成实际路由。通过标准：返回预期状态码和可解析的响应结构。
3. 从后端机器 curl 模型服务的健康检查或根路径。执行动作：观察返回码或 TCP 是否建立。通过标准：连通且返回正常，或明确拿到拒绝、超时这类可解释的结果。
4. 对齐后端日志时间戳。执行动作：找到那次失败对应的日志行。通过标准：能说出失败发生在连接、鉴权、超时还是解析环节。
5. 只改一处配置后重测同一条命令。执行动作：用第 2、3 步相同的命令复测。通过标准：原来的失败变成通过，再回到浏览器验证页面是否可以渲染。

如果第 2 步和第 3 步都通过，而页面仍然空白，问题基本落在前端构建产物、静态资源路径或接口返回结构与前端预期不一致上，这时应该继续看 Network 里的响应体，而不是再去动模型服务的配置。