用 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 字段的
formtag 完全一致，例如Q1 string `form:"q1"`对应 - 使用
url.Values手动映射可绕过 tag，但失去类型安全；推荐用第三方库如go-playground/form自动填充 - JSON 提交时，同一 struct 可直接复用，只需把
formtag 改为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键中加入时间戳前缀，如"2024-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。
立即学习“go语言免费学习笔记（深入）”；
-
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 到磁盘），这些细节比选什么框架更容易让系统在真实用户下出问题。
