先说结论
在 Odoo 里，一个页面或接口入口通常不会直接“跳进模型方法就结束”。
中间至少还有这几层：
http.Controllerrouterequest- 页面渲染或 JSON 响应
- 再和业务模型逻辑衔接
所以控制器开发讨论的其实不是“怎么写个 URL”，而是：
Web 请求如何被接住、解释、组织，再安全地转进业务逻辑。
为什么很多人一写控制器就容易把层次写乱
因为页面入口看起来很直接：
- 用户访问一个 URL
- 系统返回页面或数据
但开发时很容易把这些全揉在一起：
- 路由判断
- 权限处理
- 数据查找
- 业务规则
- 页面模板
- JSON 输出
最后控制器就会越来越胖。
所以控制器开发最重要的不是“能跑”，而是要先分清层次。
http.Controller 真正适合做什么
它最适合理解成：
Web 层入口接待员。
它负责：
- 接住请求
- 判断走哪个 route
- 组织参数和上下文
- 决定返回页面还是接口数据
但它通常不应该变成大型业务规则仓库。
否则后面会很难复用，也很难测试。
route 更像什么
route 更像：
声明这个入口在哪、接受什么类型请求、以什么方式暴露。
它回答的问题通常是：
- URL 是什么
- 是页面路由还是接口路由
- 需要什么认证方式
- 是返回网页还是 JSON
所以 route 的重点是“入口协议”，不是业务细节。
request 为什么这么关键
因为它承接的是“这次请求的现场”。
很多信息都在这里汇合：
- 当前用户
- 当前会话
- 请求参数
- 当前环境对象
- 返回响应需要的上下文
所以 request 是连接 Web 世界和 Odoo 业务环境的重要桥梁。
你如果不理解它，很容易把 Web 层和模型层关系看断。
为什么控制器里不该塞满业务逻辑
因为控制器的职责更偏：
- 收请求
- 做入口层判断
- 调合适的业务方法
- 返回合适的响应
如果把复杂业务逻辑都堆在控制器里，后面通常会出现：
- 别的入口没法复用
- 测试困难
- 权限和业务边界缠在一起
- 页面入口和核心规则高度耦合
最稳的做法还是：
控制器轻一点，业务模型重一点。
页面响应和 JSON 响应为什么要分开想
因为它们解决的不是同一类问题。
- 页面响应更关心模板、上下文、渲染
- JSON 响应更关心数据结构、接口契约、调用方消费
如果把两类思路混着写，接口和页面通常都会变得别扭。
所以就算它们都经过 controller，也最好先把输出目标分清楚。
实战里最容易踩的 5 个坑
1. 控制器里塞太多业务逻辑
后面会很难复用和维护。
2. route 只会配 URL，不想清认证和输出类型
接口边界会很模糊。
3. 把 request 当普通全局变量，不理解它是请求现场容器
很多上下文问题会看不清。
4. 页面渲染和 JSON 接口混着设计
两边都会难看。
5. 只从 Web 入口写代码，不把核心规则回收进模型层
技术债会涨得很快。
一句话记忆法
把这条链记成一句话：
http.Controller负责接住 Web 请求，route定义入口协议，request提供这次请求的上下文现场，而真正复杂的业务规则最好继续回到模型层。
理解这一句，Odoo Web 入口链会清楚很多。
DISCUSSION
评论区