先说结论
在 Odoo 里，很多“系统设置页”并不是把值直接存进 res.config.settings 本身。
更常见的真实分工是：
res.config.settings：设置界面和交互入口ir.config_parameter：很多全局配置的真实持久存储位置
如果把这两层混了，就很容易出现：
- 页面看起来保存了
- 实际读配置的地方拿不到
- 或者值改了但下一次打开又不对
为什么这个主题特别容易踩坑
因为设置页的表面体验很像“我填一个表单，然后这个模型就把值存起来了”。
但 res.config.settings 很多时候更像一个：
配置界面的中转层。
它主要负责：
- 把设置展示出来
- 接收用户修改
- 在保存时把值写去真正该落的地方
所以你如果把它误当成最终配置仓库，后面就容易出现各种错位。
res.config.settings 真正适合什么
它最适合做：
- 设置页面字段定义
- 展示当前配置值
- 保存按钮背后的读写桥接
- 把配置项组织成用户可理解的界面
所以它更偏“配置表单层”，而不是“配置主数据库”。
ir.config_parameter 真正适合什么
它更适合：
存储这类“系统参数型配置”的最终值。
比如：
- 某个功能是否开启
- 某个默认阈值是多少
- 某个外部接口参数是什么
- 某个站点级配置项取什么值
它的价值在于：
- 读取方便
- 适合全局参数式存储
- 不需要为了几个设置值专门建复杂业务模型
为什么“设置页”和“配置存储”最好分层
因为它们面对的问题不同：
- 设置页关注：用户怎么填、怎么理解、怎么保存
- 配置存储关注：系统后续怎么稳定读到值
这两个层次如果拆清楚，代码会更稳。
否则你很容易写成：
- 页面逻辑和持久化逻辑缠在一起
- 设置项读写路径不统一
- 后续模块调用不知道该去哪里拿值
为什么不是所有配置都该塞 ir.config_parameter
这点也很重要。
如果配置项本身已经带有复杂业务结构，比如：
- 一堆关系字段
- 公司维度差异
- 多记录配置对象
- 明确的业务主数据语义
那它可能就不只是“一个参数”，而更适合独立模型。
所以 ir.config_parameter 很好用，但它不是万能收纳箱。
实战里最容易踩的 5 个坑
1. 以为 settings 模型自己就是最终存储
后面读取逻辑会错位。
2. 保存时写了值，打开时却没从真实存储层回填
用户会以为没保存成功。
3. 把复杂业务配置硬塞成参数字符串
后面维护会很难看。
4. 模块里到处各写各的读取 key
配置边界会越来越乱。
5. 只想着页面能改，不想着后续代码怎么稳定读取
这类问题上线后最常见。
一句话记忆法
把它记成一句话：
res.config.settings负责把配置做成用户可编辑的界面，ir.config_parameter负责承接很多全局参数型配置的真实持久化。
理解这一句，Odoo 设置开发会顺很多。
DISCUSSION
评论区