go http服务共享进程，需主动管理数据生命周期：禁止缓存r.url.query()或r.header结果、不跨请求复用r.context()、db/logger等全局实例须在main()初始化、session需手动安全处理、goroutine必须受context约束防泄漏。
Go HTTP服务不是“一次请求一个进程”，所有请求共享同一个进程和内存空间，必须主动管理数据生命周期，否则并发下必然出错。
别缓存 r.URL.Query() 或 r.Header 的结果
PHP里 $_GET 是请求快照，每次都是新数组；Go里 r.URL.Query() 返回的是 url.Values（本质是 map[string][]string），但它底层复用同一块内存——多次调用返回的可能是同一张 map 的引用。
- 错误写法：
var cachedQuery url.Values = r.URL.Query()放在 handler 外部或闭包里，下次请求读到的是上一次的值 - 正确做法：每次 handler 入口都重新调用
r.URL.Query().Get("id")，不存、不复用、不传递指针 - 特别注意：fasthttp 的
c.FormValue("id")是安全的，但 net/http 不是
别把 r.Context() 存到全局变量或包级变量
r.Context() 绑定当前 goroutine 生命周期，跨请求复用等于让两个用户共享 context，超时、取消、value 都会串。
- 常见错误：在 middleware 里
ctx = context.WithValue(r.Context(), key, user)，然后塞进全局currentUser变量 - 后果：并发请求下，
currentUser被反复覆盖，A 用户看到 B 用户的 session 数据 - 正确路径：通过 handler 闭包传参，或用结构体封装
http.Handler，把 context 作为方法参数显式流转
DB/Logger/Config 别在 handler 里初始化
PHP-FPM 每次请求新建进程，DB 连接可以懒加载；Go 进程常驻，连接池、日志实例、配置对象必须在 main() 启动时初始化完毕。
- 错误示例：
func handler(w, r) { db := sql.Open(...) }→ 每次请求新建连接池，fd 耗尽、连接泄漏 - 正确做法：在
main()里db, _ := sql.Open(...); db.SetMaxOpenConns(20)，再通过闭包或结构体注入 handler - 额外提醒：logrus/zap 实例也一样，不能每次请求 new 一个，否则日志输出乱序、内存暴涨
Session 和 Cookie 没有自动机制，必须自己控权
PHP 的 session_start() 是黑盒：解析 cookie、校验签名、读文件、挂载全局数组；Go 里你得亲手做每一步。
- 手写解析风险高：只读
r.Header.Get("Cookie")但没验证 HMAC，攻击者可伪造任意 session ID - 内存 map 存 session：没加
sync.RWMutex，高并发下 panic 或数据错乱 - 安全疏漏：cookie 缺少
HttpOnly和Secure标志，XSS 攻击可直接窃取 token - 推荐方案：用
gorilla/sessions（net/http）或fasthttp/sessions（fasthttp），它已处理加密、签名、过期、存储抽象
最易被忽略的点：goroutine 泄漏。PHP 不用管协程生命周期，Go 里每个 handler 启动的 goroutine 必须受 context.Context 约束，否则超时请求仍在后台跑，内存缓慢上涨，数小时后 OOM。这不是理论风险，是上线后第一周就会踩的坑。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
