很多人谈 Odoo 手机端时，注意力会放在 UI：菜单有没有适配、弹窗会不会太挤、某个视图在手机上好不好用。但 web_mobile 的一个更重要价值是：它提供了一组稳定的服务端契约，让 Android / iOS App 能先确认“这台 Odoo 能不能接”，再谈后续登录与会话。
主要参考：
enterprise/web_mobile/tests/test_mobile_routes.pyenterprise/web_mobile/static/src/js/mobile_service.js
一、为什么第一步不是登录，而是 version_info
测试里先打 /web/webclient/version_info，并确认 server_version_info 最后一个标记为 e。这说明移动端并不是盲目拿着账号密码就开始试，而是先探测：
- 这是不是真正可兼容的 Odoo 服务器
- 企业版能力是否存在
- 客户端是否应该继续握手
这类“先问版本、再谈登录”的设计，在 App 侧特别重要，因为它能把“不兼容服务器”尽早拦在门外。
二、数据库发现、认证与 session 获取是分层的
测试分别覆盖：
/web/database/list/web/session/authenticate/web/session/get_session_info
这反映出移动端契约不是“一条登录 API 包办所有事情”，而是把发现环境、校验账号、建立会话拆成三步。这样每一步的失败原因都更明确，兼容策略也更稳定。
三、JSON-RPC 结构稳定，比返回内容多少更重要
测试中反复校验返回是否是标准 JSON-RPC：成功必须有 result，失败必须有 error，并且错误结构里要带 name、message 等字段。
对移动端来说，这个稳定结构极其关键。因为 App 不怕出错，怕的是每个接口出错格式都不一样。只要契约稳，客户端就能写出统一的错误恢复逻辑。
四、session cookie 与后续请求是一条连续链
authenticate 成功后，测试会验证 session_id cookie 存在，再用它去打 get_session_info。这说明移动端和网页端共享了 Odoo 的同一套会话模型，而不是另起一套 token-only 体系。
这样做的好处是：
- 权限、上下文、用户信息都能复用
- 许多现有 JSON-RPC 接口不必为移动端重写
- 调试时网页与 App 行为更容易对齐
五、最容易忽略的点：这些测试本身就是契约文档
test_mobile_routes.py 不只是自动化测试，它还是一份很好的“移动端服务契约说明书”。哪些路由要存在、出错怎么返回、版本怎么判断、cookie 怎么建立，测试里全写着。
在企业项目里，这种测试往往比某张架构图更可靠，因为它描述的是“系统实际承诺什么”。
六、结论
web_mobile 的关键不只是手机端多了一层样式，而是它明确了移动 App 和 Odoo 服务端之间的握手顺序：版本探测 → 认证 → 会话信息 → 统一错误结构。
这套 contract 稳了，移动端体验才稳。否则再漂亮的 UI，也会败在连接与登录阶段。
DISCUSSION
评论区