Go HTTP服务无PHP式请求快照机制，需实时从r/w获取数据；无自动session，须手动处理cookie与JWT；DB等资源应提前初始化并复用；goroutine需配合context控制生命周期。
HTTP服务不是“一次请求一个进程”，而是长连接+复用
PHP-FPM 模式下，每个请求启动新进程、读取全部代码、执行、销毁——$_GET、$_POST、$_SERVER 都是 PHP 运行时自动填充的快照。Go 里没有这种“快照机制”：http.Request 是一个结构体指针，生命周期绑定当前 goroutine，它不会自动更新，也不会跨请求残留。
常见错误现象：
- 在 handler 外部缓存
r.URL.Query()结果，下次请求仍用旧值 - 把
r.Context()存到全局变量或包级变量里，导致并发请求互相污染 - 误以为
http.HandleFunc的回调函数每次都是“全新环境”，其实闭包捕获的变量可能被多个请求共享
正确做法是：所有请求相关数据必须从 r *http.Request 和 w http.ResponseWriter 中实时获取，不缓存、不跨 handler 传递、不依赖全局状态。
别再写 $_SESSION 思维的中间件
PHP 的 session_start() 会自动解析 Cookie、加载 session 文件、挂载到 $_SESSION。Go 没有等价物——你得自己解析 r.Header.Get("Cookie")，校验签名，解密，反序列化，再决定是否允许访问。
立即学习“PHP免费学习笔记（深入）”；
使用场景：
- 需要用户登录态：用
gorilla/sessions或fasthttp/sessions（如果用 fasthttp） - 只需临时透传 ID：直接读
r.URL.Query().Get("token")或r.Header.Get("Authorization")，然后验证 JWT - 完全无状态 API：压根不处理 session，靠前端每次带 token
容易踩的坑：
- 手写 cookie 解析但没做 HMAC 校验，导致 session 伪造
- 把 session 数据存在内存 map 里，没加锁，高并发下 panic
- 忘记设置
HttpOnly和Secure标志，cookie 被 XSS 窃取
net/http 的 HandlerFunc 不是入口，而是路由终点
PHP 开发者习惯在入口文件顶部写一堆 include、初始化 DB、加载配置，再判断 $_SERVER['REQUEST_URI'] 分发。Go 里 http.HandleFunc 只负责响应，不负责初始化；DB、配置、日志等应在 main() 函数中提前准备好，通过闭包或结构体注入 handler。
示例对比：
// ❌ 错误：每次请求都重连 DB
http.HandleFunc("/user", func(w http.ResponseWriter, r *http.Request) {
db := sql.Open(...) // 危险！
// ...
})
// ✅ 正确：复用连接池，注入到闭包
db, _ := sql.Open("mysql", dsn)
http.HandleFunc("/user", func(w http.ResponseWriter, r *http.Request) {
// 直接用 db.Query(...)
})
关键点：
-
sql.DB本身是连接池，不是单个连接，可安全复用 - 配置应提前
json.Unmarshal到结构体，而不是运行时反复读文件 - 日志实例（如
logrus.Logger）也应提前构建，避免 handler 内重复初始化
goroutine 不是“多线程”，而是轻量级协作单元
PHP 用 Swoole 协程时，常误以为 “协程 = 线程”，结果在 Go 里滥用 go func() {}() 导致资源泄漏或竞态。Go 的 goroutine 是协作式调度的，但调度权仍在 runtime 手中；它不等于“开个后台线程就完事”。
典型错误：
- 在 handler 中起 goroutine 处理耗时逻辑，但没传入
r.Context().Done()，导致请求取消后 goroutine 仍在跑 - 用
time.Sleep模拟异步，却不检查 context 是否已超时 - 把数据库查询扔进 goroutine，却没关闭返回的
*sql.Rows，连接池耗尽
真正该做的：
- 所有阻塞操作（DB 查询、HTTP 调用、IO）都应接受
context.Context - 用
ctx, cancel := context.WithTimeout(r.Context(), 5*time.Second)控制子任务生命周期 - goroutine 仅用于并行非阻塞逻辑（如同时查多个微服务），且必须有明确退出路径
复杂点在于：Go 的常驻模型要求你对每一个 goroutine 的起止、资源归属、错误传播都心里有数——没人帮你兜底。
