生产环境中除GET外的Fetch请求无限挂起，无法建立连接

1. 优先处理 Cloudflare Worker 的 OPTIONS 预检请求 #

浏览器发起非GET请求前会自动发送OPTIONS预检请求，若Worker未正确响应，会导致请求静默挂起（无明显报错）。

• 在Worker请求逻辑最前端拦截OPTIONS请求，返回完整CORS响应头：

addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  // 处理OPTIONS预检
  if (request.method === 'OPTIONS') {
    const allowedOrigin = 'https://你的生产环境域名.com' // 替换为实际域名
    const corsHeaders = {
      'Access-Control-Allow-Origin': allowedOrigin,
      'Access-Control-Allow-Methods': 'GET, POST, OPTIONS',
      'Access-Control-Allow-Headers': 'Content-Type',
      'Access-Control-Max-Age': '86400' // 缓存预检结果，减少重复请求
    }
    return new Response(null, { headers: corsHeaders, status: 204 })
  }

  // 处理POST请求
  if (request.method === 'POST') {
    // 确保异步逻辑无阻塞，必须捕获错误返回响应
    try {
      const body = await request.json()
      // 业务逻辑...
      return new Response(JSON.stringify({ data: 'success' }), {
        headers: {
          'Content-Type': 'application/json',
          'Access-Control-Allow-Origin': allowedOrigin
        }
      })
    } catch (err) {
      return new Response(JSON.stringify({ error: err.message }), { status: 500 })
    }
  }

  // GET请求处理逻辑...
}

• 注意：生产环境不要用*作为Access-Control-Allow-Origin（若请求带Credentials），必须指定具体域名。

2. 核对 Vite 生产构建的请求参数一致性 #

本地开发/预览环境的fetch参数可能和生产环境存在差异：

• 生产环境打开浏览器控制台，打印fetch的请求参数（如console.log(url, options)），确认method、headers、body与本地完全一致。
• 临时关闭Vite压缩测试：修改vite.config.js的build.minify为false，重新构建部署，排除压缩导致的代码逻辑异常。
• 确认生产环境未依赖本地代理：本地的server.proxy仅在开发环境生效，生产环境要确保请求直接指向Worker域名，而非本地代理路径。

3. 排查 Worker 内部逻辑阻塞 #

• 检查POST处理逻辑是否存在未resolve的异步操作（如无限循环、await了永远不完成的Promise），这种情况会导致Worker无法返回响应，浏览器无限挂起。
• 登录Cloudflare Dashboard，查看Worker的请求日志（Workers > 目标Worker > Logs），搜索对应POST请求记录，排查超时、报错细节（浏览器端可能无法显示这些信息）。

4. 排除浏览器缓存/Service Worker干扰 #

• 生产环境可能存在Service Worker拦截POST请求：在浏览器开发者工具Application面板，找到Service Workers，勾选Bypass for network后重新测试。
• 若使用vite-plugin-pwa，检查缓存策略配置，确保POST请求被排除在缓存规则外（如在workbox配置中添加{ urlPattern: /.*$/, method: 'POST', handler: 'NetworkOnly' }）。

5. 确认请求内容格式 #

• 确保POST请求的Content-Type头正确设置（如application/json），且body为合法JSON字符串（避免生产环境代码压缩导致JSON.stringify异常）。
• 简化请求测试：先发送空body的POST请求，确认能正常响应后，逐步排查body内容的问题。

内容的提问来源于stack exchange，提问作者Will