Odoo 视图继承不是“把 XML 复制一份”：XPath、position 和 primary/extension 讲透
看懂 ir.ui.view 如何把继承链拼成最终 arch，为什么 XPath 找不到、position 失效，往往不是 Odoo 随机坏了。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版 Studio XML 编辑器为什么不是“打开 arch 直接改”：related views、t-call 与 keyed diff patch 讲透
Studio XML 编辑器拿到的并不是单个 arch 文本，而是一组 related views 与 t-call 资源；真正落库时也不是整段覆盖，而是 keyed diff 生成补丁。
Odoo 字段组件为什么不是“拿到 value 渲染一下就完了”：field registry、props、parse/format 与输入提交链路讲透
很多人做 Odoo 字段二开时，会把 field widget 理解成“组件接个值、改一下模板”。但从 field.js、standard_field_props.js、input_field_hook.js、formatters.js、parsers.js 到具体字段组件的链路看，官方真正维护的是一整套值流系统：字段解析、组件选型、显示格式、输入脏态、提交时机与记录更新。本文结合源码，讲清 Odoo 字段为什么很少是“纯展示组件”。
Odoo 协同编辑为什么不是“大家共用同一份 DOM”：history step、snapshot 与分支合并讲透
很多人理解协同编辑时，会自然想到“把最新 DOM 广播给所有人”。但 Odoo `collaboration_plugin.js` 的做法完全不是这样：它站在 history step 之上同步分支、补缺失父步骤、定时做 snapshot，并在外部步骤进入后修正 selection。它真正同步的是可合并的编辑历史，而不是一坨最新 HTML。
Odoo 视图为什么不是“后端吐一段 arch 前端直接画出来”：get_views、ArchParser 与 ViewCompiler 管线讲透
很多人学 Odoo 前端时，会把视图渲染想成“后端返回 XML arch，前端照着生成界面”。但 `view_service.js`、`view.js`、`form_arch_parser.js` 与 `view_compiler.js` 告诉我们，真正发生的是一条多段管线：视图描述先被加载，再被 parser 提炼成字段/组件元数据，最后由 compiler 转成 OWL 可运行模板。
Odoo 弹窗为什么不是“new 一个组件显示出来”：dialog service、overlay 栈与关闭契约讲透
很多人做前端弹窗时，思路还停留在“创建组件、挂到页面、点关闭就销毁”。但 Odoo `dialog_service.js` 与 `overlay_service.js` 显示，真正稳定的弹窗系统要处理层级栈、激活态、滚动锁定、关闭回调与子环境注入。它本质上是一个运行时服务，而不是某个组件的小技巧。
Odoo patch 为什么不是“直接改原型就完了”：super、skeleton 与 unpatch 回滚机制讲透
很多人把 Odoo 前端的 `patch()` 理解成一个“官方版 monkey patch”。但 `core/utils/patch.js` 里真正精巧的地方，不是把方法盖上去，而是怎样保留原属性、重建 `super` 链、兼容 getter/setter，并在 unpatch 时按剩余扩展重新回放。它解决的是可维护补丁，而不是一次性篡改。