Go HTTP handler 怎么安全存取向导步骤状态
不能靠全局变量或内存 map，每个用户必须隔离；用标准 net/http 的 http.ServeMux 本身不带 session，得自己套一层状态载体。最轻量做法是把 session ID 塞进 cookie，再用内存 map（加读写锁）或 Redis 存状态快照——开发期用前者够用，上线前必须切 Redis。
常见错误是直接在 handler 里 new struct 当“状态机”，结果并发请求一来，字段被覆盖，用户卡在第三步点不下去。还有人用 context.WithValue 往 request 里塞状态，但 context 只活到 handler 返回，跨重定向就丢了。
- 每次请求先从 cookie 读
session_id，没则生成新 ID 并 Set-Cookie - 用
sync.RWMutex包裹内存 state map，key 是session_id，value 是自定义结构体（含step、datamap 等字段） - 所有状态变更操作（如
NextStep()、SaveData()）必须走同一把写锁，读操作用读锁 - 别把敏感数据（如密码、token）全扔进 state，只存必要流程标识和已校验过的业务字段
怎么设计向导状态机的 step 跳转逻辑
硬编码 if/else 判 step 值容易漏分支、难测试；推荐用 map 显式声明合法转移路径，运行时查表比 switch 更易维护。比如用户当前在 "address" 步，只允许跳去 "payment" 或回退到 "contact"，不能直跳 "confirm"。
典型坑是忽略“非法跳转”：用户手动改 URL 参数或重复提交上一步表单，导致状态错乱。必须在每步 handler 开头做前置校验，不是简单 check state.Step == "xxx"，而是查 allowedTransitions[state.Step]["POST"] 是否包含当前请求动作。
立即学习“go语言免费学习笔记（深入）”；
- 定义
type TransitionMap map[string]map[string]bool，如allowedTransitions["contact"]["next"] = true - 在 handler 入口调用
isValidTransition(currentStep, action)，失败则返回 400 或重定向到当前步 - step 字符串统一用常量，避免散落字符串字面量：
const StepContact = "contact" - 后退（back）和跳过（skip）要单独建模，比如
allowedTransitions["address"]["back"] = true
表单数据怎么随 step 持久化又不污染 state 结构
用户填了 5 步，每步只交部分字段，最终要拼成完整订单结构。如果每步都用独立 struct，合并时类型转换麻烦；如果全塞进一个大 map，字段名冲突、校验分散、序列化臃肿。
实际做法是 state 里只存 map[string]interface{}，但每步提交前用专用函数做 schema 校验和归一化。比如地址步只接受 city、street，其他字段丢弃；付款步只收 method、card_last4，且强制 method 必须是预设枚举值。
- 为每步定义
func ValidateAddress(data map[string]string) (map[string]interface{}, error) - 校验通过后，用
state.Data["address"] = result存，键名即 step 名，避免扁平化冲突 - 最终提交时，用
json.Marshal(state.Data)直出，不用手拼 struct - 注意：
map[string]string接口层更安全，避免前端传数字或布尔值导致 type assert panic
为什么不能依赖 HTTP 重定向传递状态参数
有人图省事，在 redirect URL 里加 ?step=payment&token=abc123，以为能绕过 session。这会导致三个问题：URL 过长被截断、参数被用户篡改、敏感数据泄露到 referer 或服务端日志。
真正该做的是：重定向只负责跳转路径（如 /wizard/payment），所有状态仍走 session ID 关联。如果真需要临时透传少量非敏感标记（如来源页），用加密签名短 token，服务端验证后再查 session。
- redirect 目标永远只是路径，不要带业务参数
- 若需区分入口（如从邮件链接进向导），用独立的
ref_idcookie，和主 session 分离 - 所有重定向响应必须设
http.Redirect(w, r, "/wizard/"+nextStep, http.StatusSeeOther)，避免 GET 请求重复提交 - 浏览器前进/后退时，history.state 为空，不能依赖它恢复向导状态
最难绷的是状态过期处理——用户开两个标签页同时操作，或半小时没动，session 被清理了，但前端还在显示第三步表单。这时候后端要返回明确错误（比如 {"error": "session_expired", "redirect_to": "/wizard/start"}），前端捕获并跳转，而不是让表单提交 500 后白屏。
