Echo handler 中直接起 goroutine 易导致任务丢失、panic 静默退出、无重试监控、资源复用错误；应改用数据库+Worker 模式，通过 async_task 表解耦请求与执行，共享 infra 工具链，严格管控上下文、超时与租约。
Echo 框架本身不提供内置的异步任务后台执行能力，必须自行集成外部任务队列或启动独立 goroutine —— 但直接用 go func() 处理业务任务极易丢失、崩溃、无法重试、难以监控。
为什么不能直接在 Echo handler 里起 goroutine
常见错误是这样写：
e.POST("/import", func(c echo.Context) error {
go func() {
// 调用医保接口、写 DB、发通知...
}()
return c.JSON(200, map[string]string{"task_id": "xxx"})
})
问题很实在：
-
panic发生时整个 goroutine 静默退出，无日志、无上报 - 进程重启或 Pod 重建，正在跑的任务直接消失（无持久化）
- 无法查询进度、无法重试失败项、无法限流并发
- DB 连接、HTTP 客户端等资源未显式传入，容易复用 handler 中已 close 的上下文或连接
推荐方案：用数据库 + Worker 模式补全 Echo
Echo 只负责「接收请求并落库」，真正的执行交给独立的 AsyncTaskWorker 进程。这是医疗系统中已验证的可靠路径：
Echo框架 5.1.0
下载
Echo框架 5.1.0 版本源码包下载，适合关注 RealIP 行为变化、StartConfig.Listener、NewDefaultFS 和观测性中间件入口的开发团队。
- 定义任务表
async_task，字段含id、task_type、payload（JSON）、status、retries、created_at - handler 中只做三件事：校验参数 → 插入
async_task记录 → 返回task_id - Worker 进程定时轮询（如每 500ms）查
status = 'pending'的任务，用租约机制防重复领取 - 执行失败时更新
status = 'failed'并记录error_message，支持人工触发retry
关键点：payload 必须是纯数据结构（如 MedicalInsuranceImportPayload），不能含任何 handler 实例、context 或闭包引用。
如何让 Echo 和 Worker 共享配置与工具链
避免两个进程各自维护一套 DB 连接、HTTP client、日志器：
- 把数据库初始化、Redis 客户端、全局 logger 封装进
pkg/infra包，Echo 主程序和 Worker 都 import 它 - 使用统一的配置加载方式（如
viper读config.yaml），Worker 启动时也加载相同环境变量 - HTTP client 必须设置超时：
http.Client{Timeout: 30 * time.Second}，否则一个卡死的医保接口会让整个 Worker 线程阻塞 - Worker 执行任务时，用
context.WithTimeout(ctx, 5 * time.Minute)控制单任务最长执行时间，超时主动中断
前端查进度时，Echo 怎么安全返回状态
别直接 SELECT * FROM async_task —— status 字段可能被 Worker 更新中，产生脏读。正确做法：
- 提供
GET /api/v1/tasks/:id/status接口，只返回精简字段：id、status、progress（百分比）、failed_count - progress 不依赖 Worker 实时上报，而是根据已完成子任务数 / 总数计算（总数存在 payload 里）
- 对
status = 'running'的任务，加一层缓存（如 Redis TTL=5s），避免高频轮询压垮数据库 - 禁止返回原始
payload或error_message给前端，敏感信息需脱敏或仅限内部查看
真正难的不是“怎么跑起来”，而是“怎么不让它在半夜三点悄悄失败又没人知道”——租约续期失败检测、Worker 心跳告警、任务积压监控，这些才是上线后最常救火的地方。
