Fiber不内置EncryptCookie中间件，需用第三方库gofiber/encrypt或手写AES加解密；该库仅自动解密请求Cookie，响应Cookie必须手动encrypt.Encrypt()后调用c.Cookie()设置。
EncryptCookie中间件在Fiber中怎么启用
Fiber本身不内置EncryptCookie中间件，它没有像Express的cookie-parser或Spring Boot的CookieSameSiteFilter那样的默认加密Cookie支持。你要用加密Cookie，得靠第三方库或自己封装——最常用的是gofiber/fiber/v2配合gofiber/encrypt（非官方但广泛使用的扩展）或者直接用标准库crypto/aes + crypto/rand手写加解密逻辑。
为什么不能直接用fiber.EncryptCookie
因为Fiber官方API里根本不存在这个函数或中间件名。搜EncryptCookie会返回404，常见错误是误把其他框架（如Gin的gin-contrib/secure）文档套过来，或者看错了社区示例里的自定义函数名。真实可用的加密方式只有两种：
- 用
github.com/gofiber/encrypt（注意：这不是Fiber官方维护，但被多个生产项目采用） - 自己实现一个
fiber.Handler，在c.Request().Header.Cookie()读取后解密，在c.Cookie(&fiber.Cookie{...})写入前加密
前者依赖外部包，后者完全可控但要处理IV、padding、密钥轮换等细节。
用gofiber/encrypt配置的实际步骤
这个包提供encrypt.New()返回一个fiber.Handler，但它只负责解密请求中的Cookie，并不自动加密响应Cookie——你仍需手动调用encrypt.Encrypt()和encrypt.Decrypt()。典型用法如下：
import (
"github.com/gofiber/fiber/v2"
"github.com/gofiber/encrypt"
)
func main() {
app := fiber.New()
// 1. 初始化加密器（密钥必须32字节，AES-256）
enc := encrypt.New(encrypt.Config{
Key: []byte("your-32-byte-secret-key-here-12345678901234567890123456789012"),
})
// 2. 注册中间件（仅解密入参，不加密出参）
app.Use(enc)
app.Get("/profile", func(c *fiber.Ctx) error {
// 3. 手动解密指定Cookie
raw, err := c.Cookies("session_id")
if err != nil {
return c.Status(400).SendString("no session")
}
decrypted, err := enc.Decrypt(raw)
if err != nil {
return c.Status(401).SendString("invalid session")
}
// 4. 处理业务逻辑...
// 5. 手动加密并设置响应Cookie
encrypted, _ := enc.Encrypt("user:123:admin")
c.Cookie(&fiber.Cookie{
Name: "session_id",
Value: encrypted,
Path: "/",
MaxAge: 3600,
HttpOnly: true,
Secure: true, // 生产环境必须开
SameSite: fiber.SameSiteLaxMode,
})
return c.SendString("OK")
})
app.Listen(":3000")
}
注意几个关键点：
-
Key必须严格为32字节，少一字节就panic；建议用sha256.Sum256([]byte("my-env-secret")).[:]生成 - 该中间件不会自动重写
Set-Cookie头，所有加密写入都得你自己调enc.Encrypt()+c.Cookie() - 如果Cookie值含
=或+，Base64编码后可能被URL解码破坏，建议用url.QueryEscape()包裹再存
容易被忽略的坑：Secure和SameSite组合失效
即使你加密了Cookie内容，如果没配对Secure: true和HTTPS，或者SameSite设成Strict导致跨站登录失败，整个加密就形同虚设。更隐蔽的问题是：
- 本地开发用
http://localhost时，Secure: true会让浏览器直接丢弃Cookie（不报错，静默失败） -
SameSite: Lax虽兼容大部分场景，但在POST跳转时仍会丢失Cookie，导致解密失败报invalid session - 加密后的Cookie体积变大（AES+Base64约膨胀1.3倍），超过4KB上限会被截断，解密必然失败
真正安全的Cookie不是“能不能加密”，而是“加密后有没有被正确传输和解析”。这两步出问题，前面所有加解密逻辑都白搭。
