17370845950

用 net/http 接收问卷表单需先调用 r.ParseForm() 解析 application/x-www-form-urlencoded 数据，再通过 r.FormValue 或 struct + form tag 统一绑定；统计初期可用 sync.Map，路由复杂时应换用 gorilla/mux 等支持方法区分的路由器。

如何用 net/http 接收问卷表单数据

Go 没有内置的表单解析中间件，ParseForm() 是关键入口，但容易漏掉调用或忽略错误。不调用它会导致 r.Form 为空，所有 r.FormValue("xxx") 返回空字符串。

• 必须在读取 r.Body 前调用 r.ParseForm()，否则后续解析失败
• POST 请求需设置 Content-Type: application/x-www-form-urlencoded，否则 ParseForm() 不生效
• 若前端用 fetch 提交，记得显式设置 headers: {'Content-Type': 'application/x-www-form-urlencoded'}，或用 URLSearchParams 构造 payload
• 文件上传场景需改用 r.ParseMultipartForm()，和普通表单互斥

func handleSubmit(w http.ResponseWriter, r *http.Request) {
    if r.Method != "POST" {
        http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
        return
    }
    if err := r.ParseForm(); err != nil {
        http.Error(w, "Invalid form data", http.StatusBadRequest)
        return
    }
    name := r.FormValue("name")
    answer := r.FormValue("q1")
    // ... 保存逻辑
}

用 struct 和 encoding/json 统一处理前后端数据结构

问卷字段多时，硬写 r.FormValue 易出错、难维护。用 Go struct + tag 显式绑定字段，既支持 HTML 表单提交（通过 ParseForm），也兼容 JSON API（通过 json.Unmarshal）。

• HTML 表单字段名必须和 struct 字段的 form tag 完全一致，例如 Q1 string `form:"q1"` 对应
• 使用 url.Values 手动映射可绕过 tag，但失去类型安全；推荐用第三方库如 go-playground/form 自动填充
• JSON 提交时，同一 struct 可直接复用，只需把 form tag 改为 json，或保留双 tag：Q1 string `form:"q1" json:"q1"`
• 注意 time.Time 等复杂类型需自定义 Unmarshal，HTML 表单只传字符串，需手动解析

type SurveyResponse struct {
    Name string `form:"name" json:"name"`
    Q1   string `form:"q1" json:"q1"`
    Q2   int    `form:"q2" json:"q2"`
}

func parseForm(r *http.Request) (SurveyResponse, error) {
    var resp SurveyResponse
    if err := r.ParseForm(); err != nil {
        return resp, err
    }
    // 使用 go-playground/form 库自动填充：
    // decoder := form.NewDecoder()
    // if err := decoder.Decode(&resp, r.PostForm); err != nil {
    //     return resp, err
    // }
    return resp, nil
}

统计逻辑放在内存还是数据库？从 sync.Map 开始够用

初期问卷流量低、无需持久化时，用 sync.Map 做实时计数比连 DB 更快、更轻量。但要注意：它不支持原子性批量操作，也不能替代事务。

• 键建议用 "q1|yes" 这类组合字符串，避免嵌套 map 导致锁竞争
• 不要用 sync.Map.LoadOrStore 直接存整数——它返回 interface{}，需类型断言，易 panic；改用 Load + Store 显式处理
• 如果需要按日期分桶统计，sync.Map 键中加入时间戳前缀，如 "2025-06-q1|no"
• 一旦要导出报表、做多维交叉分析，就得迁移到 SQLite 或 PostgreSQL，此时统计逻辑应移入 SQL 查询

var stats sync.Map // key: string, value: uint64

func incStat(key string) {
    if v, ok := stats.Load(key); ok {
        stats.Store(key, v.(uint64)+1)
    } else {
        stats.Store(key, uint64(1))
    }
}

// 调用示例：incStat("q1|agree")

为什么 http.ServeMux 不适合复杂路由？该换 gorilla/mux 或 chi

原生 http.ServeMux 只支持前缀匹配，无法区分 /survey（渲染页）和 /survey/submit（接收 POST），强行共用路径会触发 Method Not Allowed。

• http.HandleFunc("/survey", ...) 会同时响应 GET /survey 和 POST /survey，但 handler 内仍需手动判断 r.Method
• gorilla/mux 支持 Methods("GET") 和 Methods("POST") 分离注册，语义清晰
• 若已用 net/http 写完，最简方案是加一个子路径，比如统一用 /submit 接收所有 POST，避免歧义
• 静态资源（如 CSS/JS）建议用 http.FileServer 配合 http.StripPrefix，别混在业务路由里

复杂点往往不在功能实现，而在字段校验边界（比如空字符串、超长文本、重复提交）、统计聚合时机（是每次请求都刷 DB，还是定时 flush 到磁盘），这些细节比选什么框架更容易让系统在真实用户下出问题。