Odoo 视图继承不是“把 XML 复制一份”：XPath、position 和 primary/extension 讲透
看懂 ir.ui.view 如何把继承链拼成最终 arch，为什么 XPath 找不到、position 失效，往往不是 Odoo 随机坏了。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 列表页为什么翻页、切动作后还能记住位置：Layout、Pager Hook 与滚动状态契约讲透
很多人把 Odoo Web Client 里的分页、控制面板和滚动位置恢复，当成三个互不相干的小功能：上面一个工具栏，中间一个 pager，离开页面再回来时顺手记住滚动条。但从 `layout.js`、`pager_hook.js` 与 `action_hook.js` 看，官方其实做的是一份页面状态契约：Layout 负责壳层，Pager 通过 sub env 注入统一分页状态，而 action hook 负责把本地状态与滚动位置纳入动作切换生命周期。本文讲清这三者为什么必须一起看。
Odoo 前端模板为什么不是“后加载覆盖前加载”：QWeb 继承、运行时合并与翻译上下文讲透
很多人把 Odoo 前端模板继承理解成“谁最后加载，谁把前面的模板盖掉”。但从 `template_inheritance.js` 和 `templates.js` 来看，官方做的是一套运行时模板合并机制：先注册 primary template，再登记 extension，再按 blockId、URL 过滤、XPath/属性匹配与翻译上下文把节点补进最终模板。本文结合源码，讲清 Odoo 为什么敢在浏览器里继续做模板继承，而不是只依赖服务端把模板一次性编平。
Odoo 前端为什么不只靠截图回归：web_tour、Hoot 与非确定性检查讲透
Odoo 的前端回归保护不是单一测试框架，而是把交互步骤、自动化执行、记录器和 Hoot 运行时拼成一整套机制。更关键的是，官方还专门检查 trigger 的非确定性，避免“今天过、明天挂”的脆弱测试。
Odoo 为什么把提示、庆祝和彩蛋分成两条线：notification、effect 与 display_notification 动作讲透
很多系统把“提示用户”做成一个组件，最后成功提示、错误消息、庆祝动画和操作按钮全搅在一起。Odoo 则把 notification、effect 和客户端动作拆开，让业务逻辑、视觉反馈和降级策略各自承担不同责任。
Odoo 下拉层为什么总能“贴着目标走”：Popover、usePosition 与 AutoComplete 定位链路讲透
前端悬浮层看似只是“放对位置”，真正难的是滚动、缩放、RTL、iframe、点击外部关闭和动画期间重新测量这些细节。Odoo 把这些通通收进 `Popover` 与 `usePosition` 钩子里，连 AutoComplete 都走同一套定位语义。
Odoo 热键为什么不会变成“全站抢键盘”：hotkey service、overlay 提示层与派发优先级讲透
热键系统最怕两件事：输入框误触，和多个组件互相抢快捷键。Odoo 的 `hotkey_service.js` 没有把快捷键做成一堆散落监听，而是做成了带作用域、可视提示和 DOM 回退的统一分发器。本文讲清它如何避免键盘交互失控。