Go Web框架的核心在于控制权归属：用net/http自调度，或交由Gin/Echo接管路由与上下文生命周期；关键分歧在中间件模型、错误传播路径、请求体读取时机三处，任一踩错即致静默失败或空响应。
Go 构建 Web 框架不是“搭积木”，而是明确选择控制权交到谁手上：用 net/http 自己调度，还是让框架（如 Gin、Echo）接管路由分发和上下文生命周期。核心分歧不在功能多寡，而在中间件执行模型、错误传播路径、请求体读取时机这三处——踩错一个，服务就静默失败或返回空响应。
为什么 http.ListenAndServe 启动了却没响应？
常见现象是端口监听成功（netstat -an | grep 8080 能看到），但 curl http://localhost:8080 一直 pending。根本原因不是代码写错，而是没把请求真正“交出去”：
-
http.ListenAndServe(":8080", nil)中的nil表示用默认http.DefaultServeMux，但如果你没调过http.HandleFunc注册任何路由，它只会对所有路径返回 404 —— 连日志都不打，容易误判为“卡住” - 自定义
http.ServeMux实例后，必须显式传给ListenAndServe，比如http.ListenAndServe(":8080", mux)；漏掉第二个参数，等于还在用空的默认多路复用器 - 用
gin.New()或echo.New()时，框架实例本身不启动监听，必须调e.Start(":8080")或r.Run(":8080")；只写路由不调启动函数，进程就停在初始化阶段
路由参数提取不到（c.Param("id") 为空）的硬约束
路径参数不是正则模糊匹配，而是严格字符串前缀比对。Gin/Echo 的 /user/:id 路由能匹配 /user/123，但以下任一情况都会导致 Param 返回空：
Colly Golang Web Scraper and Crawler Framework
下载
Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。
- 请求 URL 带尾部斜杠：
/user/123/≠/user/:id，需改用/user/:id/*或前端统一裁掉末尾斜杠 - 大小写不一致：路由定义
/User/:ID，但请求是/user/123→ 不匹配（Echo 默认区分大小写，Gin 同样敏感） - 正则约束未配对：想限定
:id只接受数字，必须写成/user/:id([0-9]+)；否则:id会贪婪吞掉后续所有路径段，包括斜杠 - 结构体绑定时字段未加
json:"id"tag，即使c.Param("id")有值，c.ShouldBindJSON(&u)也序列化不出字段
中间件 panic 导致服务静默崩溃的两种典型场景
Go 的 panic 默认会终止 goroutine，但 HTTP handler 中的 panic 若未被捕获，结果取决于你用的是哪层抽象：
立即学习“go语言免费学习笔记（深入）”；
- 原生
net/http：panic 会触发http.Server的RecoverPanic（仅当Server.ErrorLog非 nil 时才打印堆栈），但连接直接断开，客户端收不到任何响应 - Gin：默认
gin.Default()包含gin.Recovery()中间件，能捕获 panic 并返回 500；但若你用了gin.New()却忘了router.Use(gin.Recovery())，panic 就会穿透到net/http层，表现同上 - Echo：必须显式设置
e.HTTPErrorHandler函数，否则 panic 直接终止 handler，无日志、无响应、无重试机会 - 自定义中间件里调用
c.Next()（Gin）或next(c)（Echo）后，若下游 panic，当前中间件若没 defer recover，也会连锁崩溃
最易被忽略的是：框架的“默认行为”只在开发期友好，生产环境必须显式关闭 debug 日志、替换 recovery 策略、并确保所有中间件都遵循同一错误传播契约——否则一个未处理的 time.Parse 错误，就能让整个 API 网关静默丢弃后续所有请求。
