每家企业的数据需求各不相同，标准系统往往漏掉那些对你重要的信息。Odoo 的自定义字段就是为了解决这个差距，让你在系统里记录业务特有的数据而无需改动核心代码。
与其把业务流程强行套进死板的数据结构，不如在需要的记录上新增字段——客户、销售订单、产品或发票都可以。你来决定要采集什么信息，Odoo 会把它和原有数据一起保存并可用于搜索与报表。
本指南带你全面了解自定义字段：什么是它们、底层如何运作、如何用无代码或有代码两种方式创建、以及如何建立便于维护的字段体系。
什么是 Odoo 的自定义字段
自定义字段本质上是向现有 Odoo 模型添加的数据库字段，存储某个记录的一项特定信息，行为与内置字段无异。
在 Odoo 里，自定义字段的技术名通常以 x_ 开头。通过 Odoo Studio 创建的字段常见前缀为 x_studio_，而开发者在项目中可能会用公司或模块专属前缀，比如 x_dasolo_cost_center。
对终端用户来说，自定义字段在界面上看上去就像标准字段：可以出现在表单、列表、筛选器、分组和报表中。不了解技术细节的同事通常分辨不出两者差别。
可用字段类型一览
Odoo 支持多种字段类型，基本能覆盖绝大多数业务数据需求：
- 文本（Char）：短文本，如编码或标签
- 长文本：多行备注或描述
- 整数（Integer）：用于计数或评分的整数值
- 浮点数（Decimal/Float）：带小数的数值，用于比例或测量
- 货币（Monetary）：与币种字段关联的金额
- 布尔（Boolean）：是/否复选框
- 日期 / 日期时间：日历日期或时间戳
- 选择（Selection）：固定选项的下拉列表
- Many2one：指向另一模型的单项关联
- One2many：来自另一模型的多项关联列表
- Many2many：与多条其他模型记录互关联
- 二进制（Binary）：文件或附件
- HTML：富文本内容
从一开始就选对类型可以省下很多麻烦。当可能值是已知且有限时，优先用 Selection（下拉）而不是自由文本，能避免后续数据不一致的问题。
字段的工作原理
Odoo 基于一个叫 Odoo ORM（对象关系映射）的框架构建。界面上的每个表单、视图和记录背后对应一个 Python 模型并映射到数据库表。添加自定义字段时，Odoo 会在 ORM 中注册它，并自动在 PostgreSQL 中创建相应列。
这就是 Odoo 数据模型灵活的关键：你不是去改核心源码，而是通过存放在 ir.model.fields 表里的元数据扩展模型。Odoo 在启动时读取这些元数据并动态构建字段。
代码定义的字段 vs. 数据库记录的字段
在传统 Odoo 开发中，字段通常在 Python 模型类里声明，使用 Odoo 提供的字段类型与参数。这是面向开发者的常规做法。
例如在模块代码里可能会这样声明字段：
from odoo import models, fields
class SaleOrder(models.Model):
_inherit = 'sale.order'
cost_center = fields.Char(string='Cost Center')
而通过界面或 API 创建的字段则以 state = 'manual' 的形式记录在 ir.model.fields 中，运行时加载。两种方式都会在数据库产生真实的列，并且对用户的使用体验没有差别。
关联字段与双向关系
当你新增一个指向另一个模型的 Many2one 字段时，Odoo 通常期望在目标模型上存在对应的 One2many 字段。这个配对并非形式主义，而是 ORM 在界面与关系导航上正常工作的基础。
比方说，如果在销售订单上添加了一个 x_project_id（指向 project.project 的 Many2one），最好在项目模型上也有 x_sale_order_ids（回指 sale.order 的 One2many），这样才能从项目界面直接看到其关联的订单。
计算类自定义字段
计算字段是通过代码根据其它字段自动算出值的字段，不由用户直接填写。开发者在字段定义里用 compute 参数绑定一个 Python 方法，字段通常为只读且在依赖项变更时自动更新。
计算字段功能强大但需要编程实现；通过 Odoo Studio 在不启用开发者模式的情况下无法创建这类字段。
常见的业务场景
在我们的 Odoo 项目中，自定义字段几乎无处不在。下面列出五类常见业务实例，帮助你快速对号入座。
1. CRM：更精细的线索分类
标准线索数据通常只包含联系方式与阶段，但很多销售团队需要更多维度。添加一个“行业”选择框或一个指向内部“市场细分”模型的 Many2one，可以让销售更快筛选线索，并让管理层按细分市场统计销售漏斗。
2. 销售：记录内部项目编码
按项目计费的公司常常需要在报价或订单上记录内部项目编码或预算号。只需在 sale.order 上加一个 Char 字段“项目编码”，就能在打印单据、筛选报表或做对账时直接使用，而无需整合复杂的项目管理模块。
3. 库存：产品专属属性管理
除了 Odoo 原生的属性外，某些行业需要记录特有的技术指标。制造企业可能会为“保修期（月）”（Integer）、“认证标准”（Selection）或“原产国”（Many2one 指向 res.country）添加字段，这些信息会自然出现在产品表单并可用于库存报表。
4. 财务：预算与成本中心分配
财务团队经常需要把发票或分录标记到成本中心或预算线上。给 account.move 添加一个指向自定义“成本中心”模型的 Many2one，可以在不改变分析会计结构的前提下实现精细成本分配，筛选、数据透视和导出会立即生效。
5. 人力：入职时的特定资料采集
HR 在员工入职时会采集一些标准字段无法覆盖的信息：某国特有的合同类型、内部技能分类或车辆分配编号等。把这些自定义字段放在 hr.employee 中，比把数据散落在表格里更利于检索与报表。
如何创建或定制字段
在 Odoo 中创建自定义字段有两条主路：选择无代码的 Studio 或者走开发/API 路线。哪种合适取决于你的技术能力与字段的复杂度。
方案一：Odoo Studio（零代码）
使用 Odoo Studio 是业务人员最快上手的方式。有 Studio 权限后，几步就能把字段放到任何视图上：
- 在你要放字段的应用和记录类型（如销售订单表单）中打开页面，
- 点击铅笔图标进入 Studio 编辑模式，
- 从左侧面板拖拽一个字段类型到表单上，
- 填写字段标签、技术名及其他属性，
- 保存并退出 Studio。
Studio 会在 ir.model.fields 中创建带 x_studio_ 前缀的字段，并把字段直接加到视图里，无需部署或重启服务器。对于不需要自定义逻辑的简单字段，这是推荐做法。
方案二：通过 API 或代码进行技术定制
对于需要长期维护、纳入版本控制或实现复杂逻辑的场景，建议通过 XML-RPC API 或编写 Python 模块来创建字段。这适用于计算字段、复杂 Domain 过滤器，或希望把变更放到代码仓库管理的情况。
用 API 创建字段可以将字段定义写成脚本，在远程配置或自动化部署中非常实用。举例说明在销售订单上创建一个选择字段的步骤：
示例脚本展示了如何先查出模型 ID，然后在 ir.model.fields 中创建字段，包括字段名、描述、所属模型、类型与选项等。
这种做法是标准的 Odoo 开发者流程的一部分，用于在不修改源文件的情况下添加字段，特别适合远程配置与自动化部署脚本。
若采用完整的 Python 模块方式，则在模型类里声明字段并通过模块加载。这是最利于维护且能在升级时持久化的方案，也便于在版本控制中跟踪变更。
将字段添加到视图
仅创建字段并不会自动显示在界面上。你还需要把字段添加到对应的表单或列表视图。使用 Studio 时通常会在创建时同时完成；在技术定制中，你要修改视图 XML 或创建继承视图把字段注入到合适位置。
最佳实践指南
自定义字段容易创建，但缺乏规划的字段体系会带来长期维护成本。下面是一些能保持整洁的实战建议。
尽量用选择字段替代自由文本
如果可能值是固定的，一定优先用 Selection 而不是 Char。自由文本会导致输入不一致（例如“Client”“client”“CLIENT”），进而破坏筛选和统计。下拉列表能以最低成本强制一致性。
字段命名要清晰且统一
技术名（如 x_project_type）应反映字段含义，而不是在表单上的位置。像 x_field_1 这类名字六个月后没人知道是干什么的。建立命名规范并记录每个字段的用途。
避免滥用原生模型扩展
在 sale.order 上堆十几个自定义字段通常意味着你需要一个新的自定义模型。如果一组字段共同描述了一个独立实体（例如项目、合同或认证），考虑建模为独立模型并用 Many2one 关联更合适。
始终在预演环境测试
在生产库直接动手之前，先在数据库副本上测试。虽然创建字段通常安全，但搞错模型或类型可能需要手工清理。预演环境可以在早期发现问题。
记录你的自定义字段清单
把每个自定义字段的模型、技术名、用途和提出人记录下来。随着时间推进，Odoo 实施项目会积累大量字段，没有文档时很难判断哪些字段还能用，哪些可以删除。
为计算逻辑选对工具
如果字段值依赖于其它字段，优先用计算字段而不是要求用户手动填写，这样能避免不一致并减少录入错误。计算字段是 Odoo Python 字段功能的一部分，官方技术文档有详细说明。
常见错误及陷阱
即使是有经验的团队也会遇到自定义字段相关的问题，下面列出最常见的陷阱与避免方法。
忘记为 Many2one 创建对应的 One2many
这是最常见的技术错误。如果在模型 A 上添加了指向模型 B 的 Many2one，却未在模型 B 上创建对应的 One2many，从模型 B 无法列出关联的 A 记录，用户体验受损。添加这类字段时要同时考虑双向关系。
删除含有数据的字段
删除自定义字段会永久移除数据库列及其所有数据，无法恢复。如果数据有可能未来还能用，应该将字段归档或在界面隐藏，而不是直接删除。
在生产环境直接创建字段
在生产系统上直接修改而不先做测试存在风险——即使是简单的字段也可能因视图配置问题导致用户报错。务必先在测试环境验证。
与标准字段的命名冲突
Odoo 会拒绝模型中已存在的字段名，但你也可能无意中创建一个与未来安装模块冲突的字段。采用公司前缀（例如 x_acme_）能大幅降低此类风险。
把字段加到视图却不考虑用户体验
能放到表单不等于应该默认展示。表单过于拥挤会拖慢用户操作。若字段只在特定场景有用，考虑放到单独标签页或用条件可见规则控制显示。
混用 Studio 字段与代码字段而无统一策略
当项目同时采用 Studio 与代码定制时，可能会产生功能重叠或命名冲突。项目一开始就确定策略：简单无代码字段用 Studio，复杂逻辑用代码；或者全部通过代码管理。没有明确规则会增加后续维护成本。
总结
自定义字段是把 Odoo 与业务需求对齐的最直接、影响最大的手段之一。它们不需改动源码，可自然融入平台，并让用户按需采集准确数据，摆脱繁琐的替代方案。
关键在于先规划再实施：选对字段类型、规范命名、遵守关联字段约定并做好文档。良好的字段设计会让你的 Odoo 系统更容易维护，也更能随着业务成长而演进。
无论你是用 Odoo Studio 快速添加无代码字段，还是在更大的定制项目里编写 Python 模块，底层原则始终如一：字段要与数据匹配，模型保持清晰，并在部署前充分测试。
在 Dasolo，我们帮助企业实施、定制和优化 Odoo，使其真正贴合业务流程。无论你只是需要在现有系统中添加几项自定义字段，还是要从零开发完整模块，我们都能提供支持。
如果你希望我们评估当前 Odoo 配置并给出简洁可行的改进建议，欢迎联系我们——我们很乐意提供专业指导。