Echo 的 Context 取消“没反应”是因为开发者误以为自动生效，实则需手动监听 ctx.Done() 并在 I/O、sleep、HTTP 请求、DB 查询等处主动注入上下文；否则取消信号无法传播。
Echo 框架里直接用 ctx.Request().Context() 就行，但必须在每个可能阻塞的 I/O 或 sleep 前检查 ctx.Done()，否则取消信号根本不会生效。
为什么 Echo 的 Context 取消经常“没反应”
常见现象是用户关掉浏览器、客户端断连，或者调用方主动取消请求，但 Echo handler 里的 goroutine 还在跑、数据库查询没中断、HTTP 客户端还在等响应。根本原因不是 Echo 有问题，而是开发者误以为“用了 Echo 的 c.Request().Context() 就自动支持取消”——其实它只是把底层 net/http 的 context.Context 暴露出来，所有取消逻辑仍需你手动注入。
- net/http 在连接关闭或超时后会 cancel 自身的 request context，但这个信号不会自动传播到你开的 goroutine、
http.Client.Do、database/sql.QueryRowContext等地方 - Echo 的
c.Request().Context()是只读的，不能调用cancel()；你只能监听它 - 如果你在 handler 里启动了后台 goroutine（比如发异步通知），必须显式把该 context 传进去，并在内部做
select判断
HTTP 客户端请求必须带 Context
这是最常漏掉的一环：用 http.DefaultClient.Do 或自定义 client 发请求时，不传 context 就等于放弃取消控制。
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 错误写法：
resp, err := http.DefaultClient.Do(req)—— 完全忽略ctx - 正确写法：
req = req.WithContext(ctx)，再传给Do()；或者直接用http.NewRequestWithContext(ctx, ...) - 注意：即使加了 context，
io.ReadAll(resp.Body)本身也不响应取消，得在读之前加select { case ，更稳妥的是分块读 + 每次检查
数据库操作要用 xxxContext 方法
Go 标准库 database/sql 和主流驱动（如 lib/pq、mysql、pgx）都提供了带 Context 的方法，不用就等于裸奔。
- 别用
db.QueryRow("SELECT ...")，改用db.QueryRowContext(ctx, "SELECT ...") - 别用
tx.Exec("UPDATE ...")，改用tx.ExecContext(ctx, "UPDATE ...") - PostgreSQL 用户注意：
pgx的QueryRow默认不响应 cancel，必须用QueryRowContext；且连接池配置中要启用preferSimpleProtocol: false才能真正中断正在执行的语句
自定义 goroutine 必须显式监听 Done
Handler 里起 goroutine 做异步任务（比如记录日志、发消息、清理缓存）时，如果父 context 被取消，子 goroutine 不会自动停，除非你主动监听。
- 错误写法：
go func() { time.Sleep(5 * time.Second); doSomething() }()—— 完全脱离 context 生命周期 - 正确写法：
go func(ctx context.Context) { select { case - 更推荐封装成可取消的 helper：
if err := waitUntil(ctx, 5*time.Second, doSomething); err != nil { return }，其中waitUntil内部用select判断 - 特别注意 defer：不要在 defer 里依赖已取消的 context，比如
defer closeSomeResource(ctx)，应先判断if ctx.Err() == nil
真正难的不是“怎么加 context”，而是每个 I/O 调用点都要人工补上检查逻辑——没有银弹，漏一个点，整个链路就卡住。这也是为什么微服务里常见“请求已取消，但 DB 连接还占着、日志还在刷”。
