这一节非常重要。很多人不是不会写 Hono，而是拿着旧王朝的军规来用轻骑哨站。
#误区 1：把 Hono 当成 Express 替身
如果你的脑子里只有“路由、中间件、req、res”，那你会错过 Hono 真正的价值。
Hono 的灵魂不是“语法像不像 Express”，而是：
- Fetch 标准对象
- 多运行时移植
- 类型联动
- 边缘友好
#误区 2：过度分层，硬造 Controller
Hono 官方最佳实践已经说得很直白了：尽量不要做 RoR 风格 Controller。
不是不能分文件，而是不要为了“看起来像传统 MVC”而牺牲路由旁的类型推断。
#误区 3：把中间件顺序当成无所谓
在 Hono 里，注册顺序就是军令顺序。
你把：
authbodyLimitloggersecureHeaders
写乱了，行为就会乱。
#误区 4：忘记 Content-Type
尤其测试时最容易出这个问题：
- 你明明发了 JSON 字符串
- 但没带
Content-Type: application/json - 然后校验层里拿到
{}
这不是 Hono 坏，是你的文书没写制式封面。
#误区 5：想用 RPC，却不显式标状态码
如果你要吃 Hono RPC 的类型红利，尽量养成习惯：
return c.json(data, 200)
return c.json(errorBody, 404)别什么都靠默认 200，也别对 notFound() 的类型推断抱过高预期。
#误区 6：业务层过早绑定运行时私有 API
今天你在 Node 跑得很爽，明天想迁到 Workers，发现一半业务代码全焊在 req.socket 上。
那不是 Hono 不可移植，是你自己把马腿打断了。
#误区 7：route() 先挂后补
记住一句话：
先把子哨站修好，再挂到总哨站。