PHP转Go常驻内存开发：网络编程思维彻底转型-Golang-PHP中文网

go http服务无php式请求快照机制，需实时从r/w获取数据；无自动session，须手动处理cookie与jwt；db等资源应提前初始化并复用；goroutine需配合context控制生命周期。

php转go常驻内存开发：网络编程思维彻底转型

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")，校验签名，解密，反序列化，再决定是否允许访问。

使用场景：

需要用户登录态：用 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。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

示例对比：

// ❌ 错误：每次请求都重连 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(...)
})

关键点：