先说结论
Odoo 的视图继承不是“我写了一个 XPath，系统就会自动替我改页面”这么简单。
真正的机制里至少有三件事：
- 视图本身有继承模式：
primary和extension - 系统会先验证你的 locator 能不能命中
- 最终合并顺序还会受到 priority、父子继承链和模块加载顺序影响
所以很多“明明 XPath 写对了却不生效”的问题，根本不是语法问题，而是定位、顺序或模式出了问题。
ir.ui.view 里最关键的两个字段
在 odoo/addons/base/models/ir_ui_view.py 中，两个字段决定了继承行为：
inherit_id = fields.Many2one('ir.ui.view', ...)
mode = fields.Selection([('primary', 'Base view'), ('extension', 'Extension View')], ...)
你可以把它理解成：
extension：当前视图是“补丁”，给父视图做增量修改primary：先把最近的主视图完整算出来，再把当前视图的继承规格叠上去
这就是为什么同一个 XML 文件，放在不同模式下，结果可能完全不一样。
Odoo 是怎么发现 XPath 失效的
ir.ui.view._compute_invalid_locators() 会先把视图的父链合成一个最终源，再逐条检查当前视图里的 spec。
它会调用 locate_node() 去找目标节点；找不到时，就把这个 locator 标成 invalid。
这意味着 Odoo 不是等你运行页面时才报错，而是尽量在视图计算阶段就把问题显性化。
这点对开发很友好，因为你能尽早知道：
- 你的 XPath 是否真的能命中父视图
- 你是定位错了节点，还是节点本身已经不存在
- 你的补丁是否依赖前一个补丁先执行
为什么 translated 属性不能拿来做 selector
_valid_inheritance() 里有一个很重要的限制：
不能用翻译字段作为继承选择器。
原因很好理解：
- 不同语言下文本会变
- 继承节点如果依赖翻译文本，就会变得不稳定
- 视图合并需要的是结构锚点，不是会漂移的文案
所以不要用“显示文本”去当 XPath 的根。尽量用稳定的 name、id、结构标签或者类名。
position 也会影响你是不是写对了 patch
Odoo 的视图继承不只有 xpath，还有 position：
insideafterbeforereplaceattributes
其中最稳的通常不是 replace，而是 attributes 或者局部 inside。
比如在 sale_stock 和 purchase_stock 里，你会看到很多很小的 patch：
- 在按钮后面插字段
- 给已有字段加属性
- 在特定
group里插入小块内容
这种改法比“整块替换 form”更稳，因为它更少依赖大结构。
primary 和 priority 为什么经常一起出问题
很多人只盯着 XPath，其实最后被盖掉的常常是顺序。
Odoo 会按继承链和 priority 合并多个视图。如果别的模块比你更晚应用 patch，或者另一个 primary 视图重算了结果，你的修改就可能被覆盖。
所以排查顺序问题时，要同时看：
- 目标视图是不是
primary - 继承链上还有没有别的 extension
- priority 谁更高
- 模块依赖是否让别的 patch 先执行
这比“再改一下 XPath”更重要。
实战里最稳的写法
如果你想让视图 patch 更耐改，优先遵守这几个原则：
- 用稳定锚点，不要依赖翻译文本
- 小改优先
attributes，别整块replace - 增加字段时尽量贴近现有结构，不要跨层插太深
- 复杂改动拆成几个小 patch，比一个超大 XPath 更稳
- 修改后记得看
invalid_locators，它能直接告诉你哪条 locator 有问题
一句话总结
Odoo 视图继承不是“写 XPath 就结束”，而是“定位 + 合并 + 校验 + 顺序控制”的组合题。
理解 primary/extension、invalid_locators 和 priority，比死磕某一条 XPath 更能解决真实问题。
DISCUSSION
评论区