先说结论
Odoo 的视图继承不是“把父 XML 复制一份，再手工改几处”。
更准确地说，它做的是三步：
- 先找到整棵视图继承树
- 先把父视图和所有继承视图合成一个最终结构
- 再按 XPath 和
position规则逐层应用修改
所以，继承顺序、视图类型、position 取值、primary/extension 的先后，都会影响最终页面。
第一步：先把“树”找出来，而不是先改 XML
ir.ui.view._get_combined_archs() 不是只看当前这一个视图。
它会先沿着 inherit_id 一路向上找到 root，再把整棵树上的视图组织起来。
这一步的意义是：
- 先确定谁是父视图
- 再确定有哪些子视图会参与合并
- 最后才谈怎么应用具体改动
这就像先把一棵家谱画出来，再讨论谁改了哪一页。 如果家谱关系没搞对，后面的 XML 再“正确”，也可能拼出错误结果。
第二步：combined arch 是“最终草图”
在 _combine() 里，Odoo 会从根视图的 arch 开始，生成 combined_arch。
然后它按一个很关键的顺序遍历：
- 先处理 extension 视图
- 再处理 primary 视图
- 对每个视图，调用
apply_inheritance_specs()把修改打到当前树上
这里最值得记住的一句话是：
最终页面不是某个单一视图决定的，而是合并后的 combined arch 决定的。
这也是为什么你在源码里改了一个子视图，但页面表现会受别的继承视图影响。 不是你那段 XML 不生效，而是它只是整棵树中的一层补丁。
第三步：XPath 不是“找字符串”，而是在找节点
apply_inheritance_specs() 的核心不是字符串替换，而是把继承视图里的 spec 节点，按 XPath 定位到源树里的某个真实节点。
也就是说：
- XPath 找的是 XML 节点
position决定的是“在这个节点上做什么”- 整个过程是结构化 patch，不是文本拼接
常见的 position 你可以理解成：
before：插到前面after：插到后面inside：放到里面replace：直接替换attributes：改属性move：把节点挪位置
所以，真正的风险不只是 XPath 写错。
更常见的是：XPath 其实找到了，但你对 position 的后果理解错了。
为什么 primary 和 extension 很重要
Odoo 不是所有继承视图都以同样方式参与合并。
在 _combine() 的遍历里，primary 视图会被放到“后处理”的位置，而 extension 视图更像是补丁层。
这会带来一个实战规律：
- 想改“基础页面骨架”，优先确认主视图是谁
- 想做局部增强，优先确认你的继承视图是不是被别的视图覆盖
- 如果页面结果怪异，先查继承链，再查 XPath
很多人排查视图问题时会直接看自己的 XML。 但真正要看的，是：
你的补丁，是打在谁身上？打的时候，树已经长成什么样？
最容易误解的 3 件事
1. “我继承了视图，页面就一定按我写的顺序显示”
不一定。别的继承视图可能先改了同一个节点。 最终顺序取决于整棵树的遍历顺序。
2. “XPath 只要能找到元素就行”
不够。你还要知道这个元素后面会不会被别的视图继续改。
3. “position 只是语法糖”
不是。position 直接决定 patch 的语义，尤其在 replace 和 attributes 场景里，影响会非常大。
调试时最有效的思路
如果你在排视图问题，我建议按这个顺序看：
- 先确认 root view
- 再看 inheritance chain
- 再看你的 XPath 是否命中
- 再看
position的语义 - 最后看有没有别的继承视图覆盖了你的改动
这样排查，比盯着单个 XML 文件快得多。
最后一句话
Odoo 的视图继承本质上不是“复制 XML”，而是“沿继承树做结构化补丁”。
只要你把它理解成：
先合并树，再应用补丁
视图问题就会从“玄学”变成“可推理”。
DISCUSSION
评论区