E04通过 gRPC 适配原服务。本篇仍在同一个任务服务里做另一项局部替换：给 HTTP 应用端口换路由适配器，不复制任务提交、SQL 领取或 worker。选定 Go 1.27.1 和 github.com/go-chi/chi/v5 v5.3.2，具体依赖及 chi 源码 SHA 随完整实验包交付；另有SHA-256和独立复跑方法。

路由框架不替业务提交状态

taskstats serve 新增 --http-adapter stdlib|chi，缺省仍为原标准库 ServeMux。chi 路由器把 POST /tasks 交给原 taskHTTPService.create，GET /tasks/{id} 与 POST /tasks/{id}/cancel 只把框架取到的 ID 填回 PathValue 再交给原 lookup/cancelTask。因此 JSON/字段限制、队列容量、SQL 写入与终态仲裁还是前 39 章那一份服务。--http-adapter unknown 在监听前退出 2；单独的管理 listener 不随 HTTP 适配器一起放出诊断路由。

把两个 handler 放到同一张表里复跑比「框架更方便」有用。十轮表驱动对照同样的 Go one：两个入口都先接纳 202，再按响应实际 ID 得到 SUCCEEDED/words=2；空白输入 400、未知 ID 404、终态再取消 409、用 GET 错调提交端点 405。原协议的过载和错误体积等用例也单独回归。chi 使用 middleware.RequestID，在已给定 X-Request-Id: known-request 的请求上返回 X-Task-Request-ID: known-request；标准库入口没有这项头。中间件负责路由周边信息，不能据此说它提供鉴权、限流或业务幂等。

运行中取消是另一条必要对照。原 SQL 服务的分析器停在受控闸门，走 chi 提交任务并请求取消，HTTP 返回 202 时数据库仍是 RUNNING/cancel_requested=true；释放分析器并等待原 Close 后才有 CANCELED/words=0。框架没有改变「取消请求不等于 worker 退出」的状态契约。测试筛选最初只匹配 TestChiAdapter 这个完整名称、漏跑真实新测试，修正为 TestChiAdapter.* 并单独检查两项 PASS 后才计入本篇。

不仅是 httptest：独立 goe05live PostgreSQL 16.15 下真实构建并启动 serve --http-adapter chi，逐个保存坏配置的退出 2、HTTP 400/405/404、请求 ID 中间件响应头、POST 202、实际 ID 的 GET SUCCEEDED、SQL task[0]|SUCCEEDED|2、错误输入未入库以及 SIGTERM 退出 0。应用端 /debug/health 为 404、管理端为 200；换框架没有打通两个端口。所有命令、双流、HTTP body/header、退出码和任务 ID 均在 evidence/E05/，不能把页面可下载当成协议验收。

练习：①chi.URLParam 读到 ID 后直接重写 SQL 查询行不行？答：不行；这会复制业务状态机，应该将 ID 适配到原 PathValue，继续调用已有 handler。②收到框架中间件头能否将请求视为已鉴权？答：不能；RequestID 只是关联标识，未做用户身份或权限验证。③只复跑标准库 handler 的原测试，可以宣布 chi 路由兼容吗？答：不能；至少要让 chi 真正接收 method/ID/错误/中间件请求，再查数据库与 worker 退出。

独立解包会在新数据库、新模块/编译缓存复跑十轮双入口与 SQL 取消、真进程 chi 提交和旧 CLI，并独立检查页面/下载。race 没有报告只限执行路径；TLS、远端、其他平台、全站构建及发布 NOT_RUN。E06再问 profile 是否真能改善这一服务负载。

参考资料