Gin更适配绘图板场景：其直观的中间件链与路由分组便于处理鉴权、文件上传及WebSocket同步；Context直接暴露底层细节（如原始Body读取）利于base64/protobuf数据解析；实际QPS差距不足8%，但调试与生态优势显著。
为什么用 Gin 而不是 Echo 或 Fiber？
因为 Gin 的中间件机制和路由分组对绘图板这类需要鉴权、文件上传、WebSocket 实时同步的场景更直观；Echo 的错误处理链略隐晦，Fiber 在非标准 HTTP 场景（比如自定义二进制协议握手）下调试成本更高。实际压测中，三者 QPS 差距不到 8%，但 Gin 的 Context 对象暴露了更多底层细节（如 c.Request.Body 可直接读取原始字节），画板数据常以 base64 或 protobuf 传输，这点很关键。
- 别用
gin.Default()：默认日志和 recovery 中间件会干扰 WebSocket 连接生命周期，改用gin.New()+ 手动注册 - 禁用
GIN_MODE=release时的调试提示——绘图板前端频繁发预检请求（OPTIONS），没提示容易误判 CORS 失败 -
gin.Engine.Use()注册中间件顺序不能错：鉴权 → CORS → body 解析 → 路由，否则c.ShouldBindJSON()可能读空Body
如何安全接收和存储 SVG/JSON 格式的画板数据？
用户导出的画板通常是压缩后的 JSON（含路径点、颜色、图层），或内联 SVG 字符串。直接 BindJSON 风险高：恶意构造超深嵌套对象可触发栈溢出，或超大字符串耗尽内存。
- 用
c.GetRawData()代替c.ShouldBindJSON()，手动限制长度：if len(data) > 2 * 1024 * 1024 { c.AbortWithStatus(413); return } - JSON 解析前先用
json.RawMessage做结构校验：只允许layers、width、height等白名单字段，忽略其余键 - 存储时别存原始字符串——用
zlib压缩后写入 SQLite 的 BLOB 字段，避免文本索引膨胀；PostgreSQL 用户注意关闭TOAST自动触发，否则小画板也走外部存储 - SVG 必须剥离
<script></script>和onerror=属性，用golang.org/x/net/html解析后重建 DOM，而非正则替换
WebSocket 实时同步为什么总断连？
Gin 本身不支持 WebSocket，得靠 gorilla/websocket 拦截连接。常见断连不是代码逻辑问题，而是 HTTP 协议层被中间件污染。
- 确保升级请求走独立路由：
router.GET("/ws", wsHandler)，且该路由前**不能挂任何修改 Header 或 Body 的中间件**（包括 CORS） - 客户端发起 WS 请求时，
Origin头必须与后端域名严格一致，开发时若用localhost:3000访问127.0.0.1:8080的 API，会因 Origin 不匹配被拒绝 -
Upgrader.CheckOrigin = func(r *http.Request) bool { return true }仅用于开发，生产必须校验r.Header.Get("Origin")是否在白名单内 - 心跳必须由服务端主动发
Ping（不是TextMessage），客户端收到后立即回Pong；gorilla/websocket默认 60s 超时，建议设为upgrader.KeepAlive = 30 * time.Second
SQLite 作为存储后端有哪些坑？
轻量级绘图板选 SQLite 合理，但并发写入和文件锁行为和 PostgreSQL 完全不同——尤其多人同时保存同一画板时。
- 打开 DB 时必须加
_busy_timeout=5000参数：sql.Open("sqlite3", "draw.db?_busy_timeout=5000")，否则冲突直接报database is locked - 所有写操作包在
transaction中，且用PRAGMA journal_mode=WAL开启 WAL 模式，否则读写互斥严重 - 别用
INSERT OR REPLACE更新画板——它会删除再插入，触发完整行锁；改用UPDATE ... WHERE id = ?，配合SELECT ... FOR UPDATE显式加锁 - SQLite 不支持 JSON 函数，解析画板元数据（如作者、创建时间）需在 Go 层完成，别指望
json_extract()
Gin 的简洁性在绘图板这种 IO 密集型服务里是把双刃剑：它不帮你管连接池、不自动重试、也不封装 WebSocket 生命周期。最易被忽略的是——所有 WebSocket 连接都持有 *gin.Context 引用，如果在 goroutine 里直接用它写日志或调用 c.JSON()，大概率 panic。得把必要字段（如 c.Param("boardId")）提前拷贝出来。
