Revel适合中大型Web服务，需设revel.controller.reuse=true以避免高并发内存暴涨，并配置stack=50/maxstack=500；热重载时actionPathCacheMap不自动失效，应执行revel clean；Nginx反代必须透传X-Forwarded-Proto，否则session失效。
Revel 不适合追求“零学习成本+即插即用”的轻量 API 场景，但在中大型、需长期维护、强调开发体验与全栈一致性的 Web 服务中，它仍是少数能真正落地“约定优于配置”的 Go 框架之一。
revel.controller.reuse=true 必须手动开启，否则高并发下内存暴涨
Revel 默认不启用控制器对象池，每个请求都会 new 一个控制器实例。在每秒 1000 请求的压测中，禁用复用时 GC 次数达 23 次/分钟，内存占用 180MB；启用后降到 5 次/分钟、65MB。这不是可选项，是上线前必须配的项。
-
revel.controller.reuse必须设为true，否则revel.controller.stack和revel.controller.maxstack完全无效 - 推荐配置：
revel.controller.stack=50（保持 50 个空闲控制器）、revel.controller.maxstack=500（上限防突发流量打爆） - 该配置需写入
conf/app.conf，不是命令行参数，也不是代码里硬编码 - 验证是否生效：启动后看日志是否有
Controller pool initialized with stack size 50
路由缓存 actionPathCacheMap 对热重载有副作用
Revel 的 actionPathCacheMap 确实加速了路由匹配，但它的 key 是字符串路径 + 方法名拼接，且只在应用启动时初始化。当你在开发中频繁改路由（比如从 GET /api/v1/users 改成 GET /api/v2/users），旧缓存不会自动失效，可能返回 404 或错路由到其他 action。
- 热重载期间，Revel 并不主动清空
actionPathCacheMap，需手动触发或重启 - 生产环境无此问题，但 CI/CD 自动部署脚本里若跳过
revel clean，可能残留旧缓存逻辑 - 调试时遇到“明明改了路由却没生效”，先试
revel clean && revel run，而不是查 controller 名字拼写 - 不建议在
app.conf里关掉路由缓存（没有开关），而是接受它“启动即固化”的事实
proxy_pass 后 session 失效？X-Forwarded-Proto 缺失是主因
Revel 的 session 机制依赖 req.TLS 和 X-Forwarded-Proto 判断是否走 HTTPS，如果反向代理（如 Nginx）没透传这个 header，revel.Session().Get() 就会返回空，即使 cookie 已正确下发。
- Nginx 配置中必须显式加：
proxy_set_header X-Forwarded-Proto $scheme; - 不能只靠
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;，这个只管 IP，不管协议 - 若用 Cloudflare 或 ALB，确认它们默认透传
X-Forwarded-Proto；部分托管平台（如某些 Serverless 网关）会过滤该 header，需额外配置 - 本地
revel run -p 8089测试时，浏览器直连 http://localhost:8089 不受影响，但一旦套上 Nginx 就必须检查这一项
Revel 的“全栈”不是功能堆砌，而是各模块间隐含的耦合逻辑——比如模板里的 {{yield}} 行为会影响 layout 渲染顺序，而这个顺序又和拦截器执行时机交叉。这些细节不会报错，只会让页面局部不渲染或 session 值错乱，排查时容易绕进中间件或路由逻辑里，实际根源却在 conf/app.conf 的一行 header 配置或一个未开启的对象池开关。
