Odoo 视图继承不是“把 XML 复制一份”：XPath、position 和 primary/extension 讲透
看懂 ir.ui.view 如何把继承链拼成最终 arch，为什么 XPath 找不到、position 失效，往往不是 Odoo 随机坏了。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 前端启动为什么不是“页面一开就全量跑完”：asset bundle、module loader 与 WebClient 引导链路讲透
很多人把 Odoo 前端启动理解成“浏览器把 JS 下载完就开始跑”。但从 module_loader.js、assets.js、env.js、start.js 到 main.js 的链路看，官方真正做的是一套分层引导系统：先解析模块依赖，再按需加载 bundle，最后把服务和 WebClient 挂起来。本文结合官方源码，讲清 Odoo Web 为什么能在大型插件化前端里避免“首屏全塞满”。
Odoo 企业版 Studio XML 编辑器为什么不是“打开 arch 直接改”：related views、t-call 与 keyed diff patch 讲透
Studio XML 编辑器拿到的并不是单个 arch 文本，而是一组 related views 与 t-call 资源；真正落库时也不是整段覆盖，而是 keyed diff 生成补丁。
Odoo 编辑器里的斜杠命令为什么不是“弹个菜单就行”：Powerbox、UserCommand 与搜索更新链路讲透
很多人第一次用 Odoo 编辑器里的“/”命令，会把它理解成一个普通下拉菜单。但从 powerbox_plugin.js、search_powerbox_plugin.js、user_command_plugin.js 和 Powerbox 组件来看，官方真正做的是一套命令层：先注册用户命令，再映射成 powerbox item，按分类与可用性过滤，用 overlay 承载，再根据输入中的 search term 实时模糊筛选。本文结合源码，讲清 Odoo 为什么把斜杠命令做成编辑器内部命令系统，而不是小组件效果。
Odoo 编辑器粘贴为什么不是“把 clipboard HTML 塞进 contenteditable”：ClipboardPlugin、白名单清洗与结构重写讲透
很多人做富文本编辑器时，最容易低估的就是粘贴：浏览器能拿到 HTML，插进去不就行了？但 Odoo 的 html_editor 在 clipboard_plugin.js 和 utils/clipboard.js 里做了远比“插入一段 HTML”更复杂的工作：识别 Odoo 自有 MIME、清洗外部内容、修正表格与样式、把 inline 根节点包成 base container，还要和 history、selection、split、sanitize 协同。本文结合官方源码，讲清 Odoo 为什么把粘贴当成编辑器内核问题而不是小功能。
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 里的 OWL 响应式为什么不等于“改了 state 就重渲染”：reactive、batched render 与 Scheduler 调度讲透
很多人学 OWL 时，会把响应式理解成“state 一变，组件立刻重渲染”。但从 Odoo 自带的 owl.js 看，真实机制远没这么直白：读取时订阅、更新时批处理、渲染时进 fiber、最终由 Scheduler 在 requestAnimationFrame 节奏里落 DOM。本文结合官方源码，讲清 Odoo 前端为什么能在复杂 Web Client 中把频繁状态变化收束成稳定 UI 更新。