先说结论
在 Odoo 里，有一类字段看起来像普通字段，但背后并不一定按“就在当前表一列里老实存着”的方式工作。
这类机制经常会绕到：
ir.property- 属性字段
- 公司维度默认值 / 配置值
所以有些“这个字段为什么在不同对象/公司下表现不一样”的问题，并不只是普通字段赋值逻辑，而是属性机制在起作用。
为什么这类问题总让人感觉很隐形
因为前台看起来很正常：
- 这个字段就在表单里
- 用户能看到、能改
于是很容易以为：
- 那它肯定就是普通字段存储嘛
但属性字段的特别之处就在于：
它的值可能带有“按对象、按公司、按默认规则继承”的额外层次。
所以它经常让人觉得“值是从哪冒出来的”。
ir.property 更像什么
最通俗地说，它更像：
一层给某类字段提供按条件取值的属性配置仓。
它特别适合那些：
- 想按公司区分
- 想按对象类别给默认值
- 想在不把字段逻辑做死的情况下保留配置弹性
的场景。
为什么它在会计和伙伴场景里特别常见
因为这些场景很常遇到：
- 某类对象默认走哪个科目
- 不同公司默认配置不同
- 具体对象可以继承或覆盖默认值
如果全都硬编码进普通字段或死写逻辑，灵活性会很差。
所以 ir.property 这类属性层就很适合承接这种“带维度差异的默认值/配置值”。
为什么这类字段容易让人误判
因为你表面看到的是“一个字段值”， 但系统实际可能在做的是：
- 先看对象自己有没有专属值
- 再看有没有适用的属性配置
- 再看当前公司维度怎么解释
这就意味着它不像普通字段那样总是一眼到底。
如果你按普通字段脑回路排查，就很容易觉得：
- 这个值怎么忽然不一样了
- 为什么在这家公司下和另一家不同
为什么它和普通默认值机制不完全一样
因为普通默认值通常更像“新建时先给一个初值”； 而属性机制很多时候更像：
- 这个值本来就是要通过一层配置/继承规则去解释。
所以它不只是“新建瞬间”的事情，而经常还带着后续读取层的语义。
实战里最容易踩的 5 个坑
1. 把属性字段当普通字段排查
会一直觉得来源不明。
2. 忽略公司维度对属性值的影响
多公司下最容易踩坑。
3. 只看当前记录，不看属性配置层
很多根因会漏掉。
4. 以为这只是“默认值问题”
但它可能是持续读取语义的一部分。
5. 定制时粗暴覆盖，不理解原有属性继承机制
后面行为会越来越难解释。
一句话记忆法
把它记成一句话：
ir.property更像一层带公司与对象维度的属性配置仓，所以某些字段看似普通，实际取值却可能经过“对象专属值 + 属性配置 + 公司语义”三层解释。
理解这一句，很多属性字段问题就会不再像黑箱。
DISCUSSION
评论区