先说结论
onchange 在 Odoo 里特别有用，但它最擅长解决的不是“持久规则”，而是：
用户正在编辑表单时，系统怎样即时给出联动反馈。
所以它更偏用户体验层，而不是最终业务规则落库层。
这层一旦没分清，表单会看起来很聪明，但数据规则却会越来越不稳。
为什么大家特别容易把 onchange 用重
因为它看起来很好用：
- 改一个字段
- 另一个字段立刻跟着变
- 用户马上看到结果
于是很容易觉得：
- 这不就能顺手把业务规则也一并做了吗？
问题就在这里。
即时表单反馈和最终持久规则，并不是同一层事情。
onchange 真正最擅长什么
它最擅长的是：
- 帮用户预填值
- 在表单里即时联动
- 减少手工输入
- 让界面交互更顺
所以它特别适合：
- 选择客户后自动带联系人
- 改数量后先预估金额
- 改产品后提示默认值
这些场景的共同点是：
- 它们首先服务的是编辑体验。
为什么它不该承担最终业务约束
因为用户体验层的变化，不等于最终数据库一定会按同样路径落下去。
很多对象并不一定通过同一个表单入口创建：
- 后台导入
- 定制代码 create/write
- RPC / API
- 批量操作
这些路径如果绕开了表单 onchange，你原本写在 onchange 里的“规则”就未必会生效。
所以把最终业务约束只写在 onchange 里，是非常危险的。
最稳的分工应该是什么
一个很稳的心智模型是：
- onchange：负责让用户填表更顺
- compute / constraints / create / write：负责真实规则和落库边界
这样分层的好处是：
- 用户体验有了
- 业务约束也不会只靠界面撑着
这比把所有自动化都塞给 onchange 稳太多。
为什么“表单上看对了”还不够
因为有些 bug 正是这样来的：
- 用户在界面上看起来没问题
- 一保存、导入或接口调用就出偏差
这类问题的根因通常就是：
- 你把界面联动结果误当成了系统最终规则
所以判断 onchange 是否合适时，最好先问：
- 这是不是只属于“编辑时反馈”
- 还是系统无论从哪个入口进来都必须保证的规则
实战里最容易踩的 5 个坑
1. 把最终业务规则只写在 onchange
其他入口一绕开就失效。
2. 只关心表单看起来顺不顺
忽略落库一致性。
3. onchange 写得太重，什么都想联动
界面会越来越难维护。
4. 误把即时预填当成最终可信数据来源
后面很容易出偏差。
5. 不分体验层和规则层
这是根本问题。
一句话记忆法
把它记成一句话：
onchange 最擅长的是“用户正在填表时的即时联动体验”，而不是“无论从哪个入口进入都必须成立的最终业务规则”。
理解这一句，onchange 就不容易再被你用成万能胶。
DISCUSSION
评论区