websocket连接建立后日志未更新，因http.responsewriter被提前关闭；tail -f应使用github.com/hpcloud/tail；日志发送需用带缓冲channel+写超时；跨域和路径不匹配会导致握手失败；注意文件权限与inode复用问题。
WebSocket 连接建立后日志没更新？检查 http.ResponseWriter 是否被提前关闭
go 的 http.Handler 默认在 handler 函数返回时结束响应，而 WebSocket 升级需要复用底层 TCP 连接——如果 handler 里调用了其他中间件、defer 清理逻辑，或意外 panic 后恢复了 response，responseWriter 可能被关闭，导致后续 conn.WriteMessage 报 "use of closed network connection"。
- 确保只调用一次
upgrader.Upgrade，且之后不再访问http.ResponseWriter或http.Request - 升级成功后立即 return，避免任何 defer 操作影响 conn 生命周期
- 不要在 handler 外部 goroutine 中读写 conn；所有通信必须在 upgrade 后的 goroutine 内完成
tail -f 在 Go 里怎么安全等效？别直接 exec.Command(“tail”)
用 exec.Command("tail", "-f", path) 看似简单，但存在文件轮转丢失、进程僵死、编码不一致等问题。真实生产环境应使用 github.com/hpcloud/tail 或原生 os.OpenFile + syscall.Stat_t 轮询 inode 变化。
-
tail.TailFile支持Follow: true和MustExist: false，能自动处理 logrotate 场景 - 若自行实现，需对比
os.Stat().Sys().(*syscall.Stat_t).Ino判断文件是否被重命名/重建 - 每次读取后调用
file.Seek(0, io.SeekEnd)定位到末尾，再用bufio.Scanner按行读，避免缓冲区阻塞
日志行发到前端卡顿或乱序？注意 conn.WriteMessage 是同步阻塞的
WebSocket 发送不是“发完就丢”，conn.WriteMessage 会阻塞直到数据写入底层 socket 缓冲区。当日志高频输出（如每毫秒一行），而前端网络慢或未及时接收，发送 goroutine 会堆积，甚至拖垮 tail 监听。
- 给
conn.SetWriteDeadline，超时直接断开异常连接，防止积压 - 用带缓冲 channel 做日志行中转，tail goroutine 只负责往 channel 塞数据，发送 goroutine 从 channel 取并 write；缓冲大小建议 128–512，太大内存压力高，太小易丢
- 前端收到消息后应主动发 pong，服务端启用
conn.SetPingHandler并定期 ping，及时发现断连
浏览器控制台报 Failed to execute 'send' on 'WebSocket'？检查跨域和路径匹配
错误通常不是 WebSocket 协议问题，而是握手阶段失败：前端 new WebSocket(“ws://…”) 的 URL 路径没匹配到 Go 的 http.HandleFunc("/ws", ...)，或反向代理（nginx）没透传 Upgrade 头。
立即学习“go语言免费学习笔记（深入）”；
- 确认 Go 路由路径与前端 ws 地址完全一致，包括结尾斜杠（
/ws≠/ws/） - Nginx 配置中必须包含：
proxy_http_version 1.1;、proxy_set_header Upgrade $http_upgrade;、proxy_set_header Connection "upgrade"; - 开发时用
curl -i -N -H "Connection: Upgrade" -H "Upgrade: websocket" http://localhost:8080/ws手动测试握手是否返回101 Switching Protocols
最麻烦的其实是日志文件权限和 inode 复用——比如容器内挂载的 log 文件被 root 写入，而 Go 进程以非 root 用户运行，tail 会静默失败；或者多个实例 tail 同一个文件但没做 offset 同步，导致前端看到重复或跳变行。这些不会报错，只会让你对着空白页面发呆。