联调失败主因是HTTP层细节未对齐：本地验证需用httptest.NewRequest/Recorder显式构造请求并校验响应，前端联调须起真实服务（如:8080）、配CORS与proxy、禁用httptest.NewServer。
接口开发没调通，八成卡在「本地验证」和「前端联调」两个环节——不是逻辑写错了，而是 HTTP 层细节没对齐。
用 httptest.NewRecorder 做 handler 单元验证
别急着 go run main.go 启服务再 curl，先确保 handler 本身能正确处理请求、设状态码、序列化 JSON。
-
httptest.NewRequest必须显式构造：method、path、body（用strings.NewReader）、Content-Type头一个不能少 -
httptest.NewRecorder是内存响应体，不占端口；但recorder.Code默认是 0，handler 没调w.WriteHeader就会误判为“没返回” - JSON 请求体必须用
json.Marshal转，且检查 error；字符串拼接（如fmt.Sprintf）极易漏转义、空值或引号错位 - 响应体别用
recorder.Body.String()做字符串比对，改用json.Unmarshal解到结构体，或assert.JSONEq（忽略空格与键序）
用 net/http.ListenAndServe 起本地可调服务
前端要连、Postman 要发、浏览器要调试，就得一个真实监听的 HTTP 服务——但不是为了“上线”，而是为了“对齐”。
- 监听地址写
":8080"，别写"localhost:8080"；macOS 或 Docker 环境下后者可能无法被 curl 或容器内访问 - 每个 handler 都要显式设
w.Header().Set("Content-Type", "application/json; charset=utf-8")；否则前端fetch().json()会静默失败 - 加
w.Header().Set("Access-Control-Allow-Origin", "*")，不然浏览器预检请求（OPTIONS）直接被拦，连 404 都看不到 - 路径注册别写死
/api/user/123，用/api/user/{id}或直接解析r.URL.Path，否则带参数的请求全 404
前端怎么无缝切到你的 Mock 接口
改 JS 里的 URL 是最危险的操作——上线漏切，流量直发 localhost。唯一安全的方式是网络层劫持。
立即学习“go语言免费学习笔记（深入）”；
- Webpack/Vite 开发服务器配
proxy：把所有/api/**转发到http://localhost:8080，前端代码零修改 - 或改本地
/etc/hosts，把真实域名（如api.example.com）指向127.0.0.1，Mock Server 监听:8080后配反向代理（Nginx 或 Caddy） - 绝对不要写
if (process.env.NODE_ENV === 'development')切地址——环境变量可能随构建产物打进线上包，导致生产环境请求发到本地 - 验证是否生效：用
curl -v http://localhost:8080/api/user?id=1看响应头（Content-Type、Access-Control-Allow-Origin）和 body 是否符合预期
为什么 httptest.NewServer 不适合联调
它启动的是测试专用服务，生命周期绑定单个 test 函数，根本扛不住真实联调场景。
-
httptest.NewServer返回的 URL 是随机端口（如http://127.0.0.1:56789），前端没法硬编码，每次运行都变 - 默认不处理 CORS，也不支持长连接、流式响应、多并发等真实 HTTP 行为
- Postman、浏览器、Vue Devtools 都连不上——它只供 Go 测试代码内部调用，不是对外服务
- 如果你看到有人用它做联调，大概率是误用了；那是单元测试工具，不是联调工具
真正卡住人的，从来不是 handler 逻辑，而是 Content-Type 没设、CORS 没开、路径没泛匹配、前端 proxy 配错路径层级——这些点漏一个，就卡半天。
