当使用 fetch 发起 put/delete 等非标准表单请求时，express 中间件返回的 ejs 渲染 html 页面不会自动显示在浏览器中——需在前端显式解析并注入响应体，而非依赖浏览器默认导航行为。

当使用 fetch 发起 put/delete 等非标准表单请求时，express 中间件返回的 ejs 渲染 html 页面不会自动显示在浏览器中——需在前端显式解析并注入响应体，而非依赖浏览器默认导航行为。

在现代 Web 开发中，通过 JavaScript 的 fetch() 替代原生表单提交（以支持 PUT/DELETE 方法）已成为常见实践。但一个容易被忽视的关键点是：fetch 是纯 API 交互机制，它不会触发浏览器的页面跳转或 HTML 渲染流程——即使后端 res.render() 成功返回了完整的 HTML 字符串，若前端未主动处理该响应内容，用户界面将保持静止，仅网络面板中可见响应体。

问题本质：Fetch 不会自动渲染 HTML 响应

你遇到的现象——DevTools 的 Network 标签页中能清晰看到完整的 HTML 响应（含 ...）、状态码为 400 或 500，但页面无任何变化——正是 fetch 的预期行为。它把响应当作“数据”而非“导航指令”，与

提交后浏览器自动加载新页面有根本区别。

服务端逻辑（Joi 验证失败 → next(err) → 全局错误中间件 → res.status(400).render('error')）完全正确，且在 GET/POST 表单直连场景下可正常工作，恰恰印证了问题出在客户端对响应的消费方式上。

正确的客户端处理方案

你需要在 fetch().then() 中根据 response.ok（即状态码是否在 200–299 范围）分支处理：

cn-json-diff

比较两个 JSON 文件并显示差异。支持嵌套结构、数组及值变更。纯 Python 标准库实现，无需 API 密钥。

下载

• ✅ 成功响应（如 200 OK）：解析 JSON 并执行业务逻辑（如提示、跳转）；
• ❌ 失败响应（如 400 Bad Request）：调用 response.text() 获取 HTML 字符串，并手动替换当前 DOM 内容。

以下是优化后的健壮实现（已避免深层嵌套 .then()，提升可读性与可维护性）：

form.addEventListener("submit", async function (ev) {
  if (this.dataset.id !== "create") {
    ev.preventDefault();

    const formData = Object.fromEntries(
      new FormData(this).entries()
    );

    try {
      const response = await fetch(this.action, {
        method: "PUT",
        body: JSON.stringify(formData),
        headers: { "Content-Type": "application/json;charset=utf-8" },
      });

      if (response.ok) {
        // 成功：期望返回 JSON { message: "updated" }
        const data = await response.json();
        alert(data.message);
        window.location.href = "/user"; // 显式跳转
      } else {
        // 失败：服务端 render() 返回 HTML，需手动注入
        const errorHtml = await response.text();
        document.documentElement.innerHTML = errorHtml; // 替换整个页面
      }
    } catch (err) {
      alert("网络请求失败，请检查连接", err);
      console.error("Fetch error:", err);
    }
  }
});

✅ 关键改进说明：

• 使用 async/await 替代嵌套 .then()，逻辑扁平、错误统一捕获；
• Object.fromEntries(new FormData(...)) 比手动遍历 更健壮（兼容 textarea、select、文件字段占位等）；
• document.documentElement.innerHTML = errorHtml 替换整页，确保 CSS/JS 上下文完整复原（优于 document.body.innerHTML）；
• window.location.href 显式跳转，语义清晰且兼容性更好。

注意事项与最佳实践

• 不要混淆状态码用途：400/500 是语义正确的错误标识，无需改为 200。浏览器不会因状态码拒绝渲染 HTML，问题只在于前端未消费它。
• 避免 innerHTML XSS 风险：本方案安全的前提是——你的 EJS 模板由可信服务端渲染，且未直接插入未经转义的用户输入。务必在模板中使用 （不转义）时严格校验内容，常规变量一律用 。
• 增强用户体验：可在注入错误页前添加加载状态，或对错误页做轻量级过渡动画（如淡入）。
• 服务端补充建议：若未来需支持 SPA 式局部刷新，可考虑统一返回 JSON 结构（含 redirect 或 html 字段），由前端判断渲染策略，实现前后端职责更清晰的解耦。

总结

Fetch 与传统表单提交的核心差异在于控制权归属：前者将响应处理完全交给开发者，后者由浏览器接管导航。解决 EJS 页面不显示的问题，不是修改 Express 渲染逻辑，而是补全前端对非 2xx 响应的 HTML 消费链路。掌握这一模式，即可无缝复用现有服务端错误中间件，同时获得现代化请求控制能力。