go 中全局布尔变量被意外重置为 false，通常源于局部变量遮蔽（shadowing）与类型转换缺失；正确做法是使用赋值语句（而非短声明）并显式解析字符串为布尔值，更推荐通过函数参数传递状态以保证并发安全。
在 Go 中，布尔变量的误用常导致难以调试的逻辑错误——如题中所示：全局 withKetchup 和 withMustard 声明为 bool 类型，但在 orderProcess 函数内使用 := 重新声明，实际创建了同名局部变量，完全遮蔽了全局变量。因此，后续 prepareOrder 读取的仍是未修改的零值 false。
✅ 正确写法一：修复遮蔽 + 显式类型转换（不推荐用于并发场景）
var withKetchup bool
var withMustard bool
func orderProcess(w http.ResponseWriter, r *http.Request) {
r.ParseForm()
// ❌ 错误：withKetchup := ... 创建了新的局部 string 变量
// ✅ 正确：赋值给全局变量，并将表单字符串转为 bool
withKetchup = r.FormValue("withKetchup") == "true"
withMustard = r.FormValue("withMustard") == "true"
}
func prepareOrder() {
fmt.Println(withKetchup, withMustard) // 现在能输出预期值
if withKetchup && withMustard { // ✅ 可直接写 bool 表达式，无需 == true
// 处理双酱订单
}
}⚠️ 但请注意：上述方式仍存在严重隐患——HTTP 处理函数默认并发执行，多个请求同时调用 orderProcess 会竞争修改同一组全局变量，导致数据错乱（例如 A 请求设为 true，B 请求覆盖为 false，C 请求读到错误状态）。Go 官方强烈反对在 handler 间共享可变全局状态。
✅ 推荐写法：函数参数传递（安全、清晰、符合 Go 习惯）
func orderProcess(w http.ResponseWriter, r *http.Request) {
r.ParseForm()
// 解析表单值为布尔类型（假设前端发送 "true"/"false" 字符串）
withKetchup := r.FormValue("withKetchup") == "true"
withMustard := r.FormValue("withMustard") == "true"
// 将状态作为参数传入，隔离每次请求的数据边界
prepareOrder(withKetchup, withMustard)
}
func prepareOrder(withKetchup, withMustard bool) {
fmt.Printf("Ketchup: %t, Mustard: %t\n", withKetchup, withMustard)
if withKetchup && withMustard {
fmt.Println("Preparing order with both condiments.")
} else if withKetchup {
fmt.Println("Preparing order with ketchup only.")
} else if withMustard {
fmt.Println("Preparing order with mustard only.")
} else {
fmt.Println("Preparing plain order.")
}
}? 补充说明与最佳实践
-
表单值解析建议：HTML 表单中复选框（）未勾选时不会提交该字段，因此 r.FormValue("withKetchup") 在未勾选时返回空字符串 ""。更健壮的判断方式是：
withKetchup := r.FormValue("withKetchup") != ""或统一约定前端显式提交 "true"/"false"，再用 == "true" 判断。
避免冗余比较：Go 中 if flag == true 应简化为 if flag；同理 flag == false → !flag。
全局变量替代方案：若需跨请求共享只读配置（如开关、阈值），可使用 sync.Once 初始化的包级变量；若需持久化状态，请使用数据库、缓存（Redis）或上下文（context.Context）传递请求级数据。
遵循“参数即契约”原则，让函数职责明确、无副作用、易于测试——这才是 Go 并发编程的正确打开方式。
