先说结论

Odoo 视图继承不是“把一堆 XML 片段拼在一起”这么粗糙。它真正做的是：

1. 先找到一个 primary view 作为根
2. 再按继承树把 extension / primary 子视图逐个合并
3. 每个子视图里的 <xpath> / position= 语句，都是对当前 combined arch 的一次局部修改
4. 最后再做 postprocess，把 groups、access rights、modifiers 等信息整理给前端

所以，视图继承的关键不是“写了多少 XPath”，而是：

• 你改的是哪棵树的哪一层
• 合并顺序会不会影响结果
• 你的定位表达式是不是足够稳

先理解 primary 和 extension

ir.ui.view 的 mode 只有两个核心角色：

• extension：默认模式。请求这个视图时，Odoo 先找到最近的 primary view，再把所有相关继承视图按顺序应用上去
• primary：先把父视图完整解析出来，再把自己的继承 specs 应用到结果上，最后把这个结果当成自己的实际 arch

这意味着，inherit_id 并不只是“谁继承谁”这么简单，它还决定了这个视图在合并树里是怎么被定位的。

如果把继承关系理解成树，primary view 像根节点，extension 视图像修改层；Odoo 会在合适的时候把这些修改层压到当前结果上。

_combine() 不是线性串接，而是深度优先遍历

源码里的 _combine() 很值得看。

它会：

• 从根视图的 arch 开始
• 维护一个队列
• 按继承层级做深度优先遍历
• 让 extension 更早生效，让 primary 子树在必要时后处理

这就是为什么同一个模块里多个继承视图，顺序不同，最后结果可能完全不同。

你不能只看“谁写在 XML 文件前面”，还要看：

• priority
• inherit 结构
• mode 是 extension 还是 primary
• 子视图是否会继续分叉

XPath 只是定位方式，不是合并本身

真正做修改的是 apply_inheritance_specs()，它把工作交给 odoo.tools.template_inheritance.apply_inheritance_specs()。

也就是说：

• <xpath expr="..." position="replace"> 只是告诉系统“去哪里改、怎么改”
• 真正的合并逻辑在模板继承工具里
• 如果定位失败，最后会抛出视图错误，而不是默默忽略

这也是为什么写继承视图时，XPath 要尽量“稳”而不是“凑巧能命中”。

实战建议

优先考虑这些定位方式：

• @name
• @id
• 语义明确的容器节点
• 相对稳定的 field / group / notebook 页签

少用这种过于脆的表达式：

• 纯靠位置序号
• 过深的嵌套路径
• 容易被别的模块插入节点打断的路径

position="attributes" 很适合做轻量改动

如果你只是想改标签、样式、readonly、invisible、required 之类的属性，position="attributes" 往往比整块 replace 更安全。

因为它：

• 对上游结构侵入更小
• 不容易把别的模块加进去的节点一并覆盖掉
• 便于后续模块继续继承

这也是 Odoo 视图开发里最常见的“少动结构，多动属性”的思路。

合并完成后，还要做 postprocess

很多人只盯着 XML 合并，忽略了后处理。

在 postprocess_and_fields() 里，Odoo 会继续处理：

• groups 相关的可见性
• model_access_rights 对 create / write / delete 的标记
• debug 相关节点
• field 解析和字段描述收集

所以，最终给前端看的，不只是“合并后的 XML”，而是“合并 + 解析 + 修饰后的结构”。

这也解释了一个常见误区：

groups 可以隐藏 UI，但它不是后端安全边界。

如果业务真的敏感，仍然要靠 ACL、record rule 和后端逻辑兜底。

为什么有时视图看起来“被别的模块改坏了”

常见原因通常不是 Odoo 随机抽风，而是下面这些：

1. XPath 过于脆弱：上游改了一个包装层，你的定位就失效了
2. 继承顺序冲突：多个模块同时改同一个节点，后应用的覆盖前面的
3. mode 用错：本该是 extension，却写成 primary，或者反过来
4. 结构改得太大：本来只想改属性，却把整块 replace 掉，导致后续继承点消失

一个好用的思维模型

你可以把 Odoo 视图继承想成三步：

• 找根：先找到最适合的 primary base
• 打补丁：用 XPath 做局部修改
• 再整理：postprocess 把权限、字段和 modifiers 统一收尾

只要这三步分清楚，视图继承就不再是“玄学 XML”。

总结

Odoo 的视图继承本质上是一条“先合并、后整理”的流水线：

• inherit_id 决定继承树
• _combine() 决定合并顺序
• apply_inheritance_specs() 决定怎么修改
• postprocess_and_fields() 决定最后给前端什么结果

所以，写视图时最重要的不是“能不能命中”，而是“命中以后会不会稳定、可维护、可继续继承”。

English sidecar

The short version

Odoo view inheritance is not just “concatenate a bunch of XML fragments”. It is a pipeline:

1. Pick a primary view as the root
2. Merge the related extension and primary children in order
3. Apply each <xpath> / position= spec on the current combined architecture
4. Run post-processing so the final result is ready for the client

The key question is not “did my XPath match?”, but:

• Which layer of the inheritance tree am I modifying?
• Does merge order change the outcome?
• Is the locator stable enough for future modules?

Primary vs extension

In ir.ui.view, mode has two meaningful roles:

• extension: the default. Odoo resolves the closest primary view, then applies all related inherited views
• primary: Odoo fully resolves the parent first, then applies this view’s inheritance specs and uses the result as the actual arch

So inherit_id is not only “who inherits whom”; it also determines how the view is positioned in the merge tree.

_combine() uses depth-first traversal

The merge is not linear. _combine() starts from the root arch and walks the hierarchy depth-first.

That means merge order matters:

• priority matters
• inheritance structure matters
• mode matters
• sibling extensions can affect each other

XPath is just the locator

apply_inheritance_specs() delegates the real work to odoo.tools.template_inheritance.apply_inheritance_specs().

So XPath does not perform the merge by itself. It only tells Odoo where and how to patch the current architecture.

For robust locators, prefer stable anchors such as:

• @name
• @id
• clear container nodes
• stable pages, groups, and fields

Avoid brittle paths that depend too much on exact nesting.

Post-processing still happens

After the XML merge, postprocess_and_fields() still handles things like:

• groups visibility
• model_access_rights flags
• debug nodes
• field metadata extraction

That is why the final client arch is more than just merged XML.

Also, groups hides UI elements, but it is not a backend security boundary.

Practical takeaway

Think of Odoo view inheritance as a three-step pipeline:

• find the root
• apply patches
• postprocess the result

If you keep those three layers separate, view inheritance becomes predictable instead of mysterious.