导言
如果你在 Odoo 中保存表单时看到某个输入框变成红色，那就是系统在告诉你“这个字段必须填写”。这个看似简单的界面提示，其背后是 Odoo 数据模型中一条重要的约束机制，用来保证业务流程中的关键信息不会被遗漏。
无论你是在为销售团队配置流程、为业务建模，还是在做技术层面的 Odoo 定制开发，弄清楚 required 属性的工作方式都有助于把系统搭建得更稳健、更少出错。
本文将从概念、界面表现、实现方法（无代码与代码）、典型场景与落地建议到容易踩的坑全面覆盖，帮助你在实际项目中正确使用必填字段。
什么是 Odoo 中的“必填字段”
在 Odoo 中，required 是一种字段级别的约束：只有当该字段有值时，记录才能被保存。几乎所有常见字段类型都支持它：文字、数字、下拉选择、many2one 关联、日期等。
它属于 Odoo 数据模型的核心属性之一，也是定制时最常用的约束手段。把关键信息设为必填，是防止数据库出现不完整或不一致数据的第一道防线。
界面上的表现方式
在 Odoo 的界面里，必填字段和可选字段在编辑状态下会有不同的提示。未填写必填字段时，保存操作会阻止并把该字段以红色或其它显著方式标示，同时给出验证提示，提醒用户补全内容。
这种即时、可见的反馈在 Web 端全平台一致，能显著降低因遗漏导致的错误提交。
静态必填与动态必填的区别
把字段设为必填有两种常见做法：一种是静态必填——始终必须填写；另一种是动态必填——只有在满足特定条件时才强制，例如依赖同一记录上其它字段的值。
两者在项目中都经常使用，选择哪种方式取决于具体业务规则和用户体验考量。
字段如何生效
从技术角度理解 required 的工作机制，可以帮助你更准确地应用它并在出问题时更快定位根因。
在应用层面的约束执行
很多人会误以为 required 会在数据库层面添加 NOT NULL。事实上，Odoo 的 required 是在应用层（ORM）检查的：当记录创建或更新时，ORM 在写入数据库之前进行验证。
默认情况下，给字段设置 required=True 并不会在 PostgreSQL 表列上自动添加 NOT NULL 约束；验证是在 Odoo 的 Python 层完成的。
这也就意味着如果有人绕过 Odoo 直接修改数据库（直接写入 PostgreSQL），那些绕过 ORM 的数据不会符合 required 的检查。因此，要保证数据完整性，务必通过 Odoo 的 ORM 或官方 API 与系统交互。
当约束被触发时会发生什么
用户在表单里留空必填字段并尝试保存时，会有两类后果：
- 界面上该字段被明显标红并弹出提示，
- 保存操作被阻止，直到补全字段为止。
若通过编程接口触发保存（例如 XML-RPC 或服务器动作），Odoo 会抛出一个 ValidationError，指出缺失的是哪个必填字段。
使用视图条件实现动态必填
在 Odoo 中，可以通过视图层的表达式让 required 成为有条件的。Odoo 16 及更早版本多用 view 的 attrs 来实现，示例写法如下：
<field name="x_delivery_date" attrs="{'required': [('order_type', '=', 'delivery')]}" />Odoo 17 之后在视图上支持更直观的 required 表达式：
<field name="x_delivery_date" required="order_type == 'delivery'" />这些条件只在视图层生效：它们影响用户在该视图中的编辑体验，但不能替代模型层的强制约束。模型层的 required=True 永远更严格、应用范围也更广。
与 ORM 和 API 的交互细节
在调用 ORM 的 create() 或 write() 时，系统会检查模型中所有 required=True 的字段；如果某个必填字段缺失或为 False，ORM 会抛出 ValidationError，阻止数据库操作。
同样规则适用于通过 XML-RPC 等 API 创建记录：如果模型定义里有必填字段，必须在传入的数据字典中包含对应值，否则调用会失败。
适用的业务场景
必填字段在标准 Odoo 模块中大量出现，也常用于自定义场景。下面举出五个常见且能显著改善业务数据质量的实例。
1）CRM：线索必须填写客户分类
销售团队希望每条线索都标明客户细分，否则后续按分组统计来源和转化率会变得不可靠。没有约束时，销售人员容易跳过这一步，导致分析失真。
把“客户分类”设置为 CRM 线索表单的必填项，能确保数据在录入时就到位，未填写则无法保存。
2）销售：订单必须填写收货地址
对有物流发货需求的企业来说，收货地址是能否完成发运的关键。有些默认配置并不会强制填写该字段，导致确认订单后再补地址引发错发或延迟。
将收货地址设为销售订单的必填字段，可以在订单确认前阻止任何遗漏，从而降低履行环节的错误率。
3）库存：入库时必须录入批次/序列号
在食品、医药或电子等受监管行业，入库必须记入批次或序列号以便追溯。Odoo 的产品追踪功能可以在移动库存时强制填写该信息。
对于自定义的入库字段（比如质检编号），设为必填能确保仓库人员在收货流程中不会忘记记录关键数据。
4）会计：供应商发票必须填写成本中心
财务需要所有费用都挂到成本中心以便预算与核算。若没人强制填写，账务记录会留下空白，影响报表准确性。
在供应商发票表单上添加一个指向成本中心模型的 many2one 必填字段，能确保每张发票都有对应的成本归属，提升报表完整性。
5）人力：入职前必须填写合同类型
HR 在办理员工入职时常需先确定合同类型。把合同类型设为员工表单的必填项，可以防止在繁忙的入职期间出现未完成记录。
如何创建或自定义必填字段
在 Odoo 中把字段设为必填主要有两种路径：使用 Odoo Studio 的无代码方式，或在自定义模块里用 Python 在模型层定义。两者各有适用场景。
用 Odoo Studio（无代码）
Odoo 自带的 Studio 工具让非开发人员也能修改表单字段。在 Studio 中选中字段后，右侧属性面板会有一个“必填”开关，切换后即可生效。
启用该开关会在视图中标记为必填，并在模型层记录该设置。对于快速交付或简单场景，这是最快的方式，无需写代码即可对标准字段或 Studio 新增字段生效。
不过 Studio 的限制是主要用于静态必填；若需根据其它字段动态控制必填逻辑，通常要直接编辑视图 XML 或采用技术方案来实现。
技术实现：在 Python 模型中声明
在自定义模块里声明必填字段很直接：在字段定义里加上 required=True 即可。这是 Odoo Python 开发中的标准做法。
示例：
通过在模型层设置 required=True，约束在模型级别生效——无论从哪个视图或 API 创建记录都无法绕过该限制，这比仅在视图层设置更安全可靠。
在视图 XML 中实现动态必填
如果仅在某些条件下才需要强制填写，应把规则放在视图层。例如在 Odoo 16 中：
<field name="x_cost_center_id" attrs="{'required': [('order_type', '=', 'invoiced')]}" />在 Odoo 17 中可改写为更直观的表达式：
<field name="x_cost_center_id" required="order_type == 'invoiced'" />这种约束仅在包含该视图的上下文中生效，模型层仍可被其它接口绕过，因此要根据需求选择放置位置。
通过 API 创建并设置必填字段
如果你通过 XML-RPC 或类似方式编程创建字段（例如自动化部署场景），可以在调用 ir.model.fields 的 create 接口时把 required 属性一并设定，从而在创建字段时同步生效。
这样的做法适用于希望用脚本化流程批量创建字段并确保约束一并到位的场景。
它在自动化部署和规模化定制中非常实用。
最佳实践建议
给字段设为必填看似简单，但要用得稳妥需要提前考虑场景与后果。下面这些建议能帮你减少用户摩擦并避免数据污染。
1）只有在确实必要时才设为必填
过度强制必填是常见错误：当用户在录入时信息并不可得，他们可能会用占位符或随意值来绕过限制，反而损坏数据质量。设为必填前，先确认信息在录入时是否总是可得；如果不能，考虑在流程后期再强制或使用阶段性校验。
如果不是百分百确定录入时有值，优先考虑在确认环节或特定阶段再校验，或采用动态必填。
2）在分阶段流程中使用阶段性校验而非一直强制
许多业务是多步骤的，例如商机或生产订单，更合理的做法是在关键节点（如“确认”或“发布”）再进行必填校验，而不是在创建时全部强制。可通过 Python 约束或自动化动作在记录进入特定阶段时检查必填项。
这种方式比一开始就把所有字段设为必填对用户更友好，也更灵活。
3）在合理情况下为必填字段设置默认值
如果某个必填字段大多数情况下都有一个合理默认值，就在字段定义里设置 default。这样既能保证字段不为空，又能减少用户需要手动填写的工作量。
4）关键数据优先在模型层强制
对于真正关键的数据（如会计字段、监管编号等），应在 Python 模型层设置 required=True，而不是只在视图层提示。视图层的约束容易被 API 调用、导入或其它视图绕过。
5）对终端用户明确说明新加的必填字段
在已有业务流程中新增必填字段会让正在执行中的用户遇到意外阻断。上线前应提前通知团队，尤其是当已有记录在下一次编辑时可能触发验证失败时。
6）在各种入口点测试空值与部分数据情况
上线前务必通过 Web 界面、API、导入以及自动化动作等所有可能的记录创建/编辑路径做测试，验证在缺失或部分数据的情况下系统表现是否符合预期。
常见问题与陷阱
即便是经验丰富的 Odoo 实施顾问也会在必填字段上遇到麻烦。了解常见陷阱能节省大量排查时间。
陷阱一：在已有大量记录的模型上直接设为必填
如果在已有海量记录的模型上新增 required=True，而这些记录并没有该字段的值，那么这些记录在下次编辑时会被阻止保存，用户体验会被严重破坏。
在部署这类变更前，应先核查历史数据并通过数据迁移脚本或批量更新将字段补齐，确保上线时不会造成大面积的保存失败。
陷阱二：混淆视图层与模型层的必填约束
仅在视图中设置必填（例如通过 Studio 或视图 XML）不会在模型层产生强制性约束。通过 API、不同视图或导入创建的记录可以绕过视图层的规则。
如果需要不可绕过的强制规则，应在模型定义中使用 required=True。这是许多项目中被误解并导致数据问题的关键点。
陷阱三：自动化或定时任务创建记录时忘记必填字段
当自动化动作或计划任务以编程方式创建记录时，必须为所有模型级必填字段提供值。如果在添加必填字段之前没有更新这些自动化脚本，任务会开始失败并抛出难以理解的错误。
在给模型新增必填字段后，应检查并更新所有相关的自动化脚本与第三方集成代码。
陷阱四：导入数据时遗漏必填字段
通过 CSV 或导入工具导入记录时，若模板中缺少必填字段，导入会失败。虽然这是正确的保护机制，但常常会让习惯导入部分数据的用户不适应。
在导入模板和数据导入说明中明确列出必填字段，避免用户使用不完整的导入文件。
陷阱五：把复杂的业务校验都寄希望于 required 属性
required 只能检验“非空”。对于更复杂的逻辑（例如日期必须在未来、两个字段必须互相一致等），应使用 Python 的 @api.constrains 或更复杂的验证机制来实现。
把业务逻辑强行塞进 required，会导致规则僵化、难以维护。用对工具恰当表达规则才是长期可持续的做法。
总结
必填字段是 Odoo 中最基础也最有影响力的工具之一。恰当地使用它，能确保关键数据在业务流程中被及时捕获；滥用或误用则会给用户带来阻力，并诱导出脏数据。
核心要点在于分清模型层与视图层约束的区别、有意识地决定哪些字段必须强制、并评估约束在自动化流程与 API 集成中的行为。
不论你是参考开发文档、做定制化项目，还是仅在 Studio 中微调表单，深入理解 required 属性能让你的 Odoo 实施更稳健，避免上线数月后出现连锁问题。
需要 Odoo 实施方面的帮助吗？
在 Dasolo，我们为企业提供 Odoo 实施、定制与优化服务，涵盖从数据模型设计、验证规则配置到定制模块开发的全流程。不论需求简单还是复杂，我们的团队都能把功能与业务流程结合起来，交付可维护且贴合实际的解决方案。
如果你对必填字段或 Odoo 的其它配置有疑问，我们可以提供咨询与实施支持。 联系我们获取专业建议， 让我们一起把你的 Odoo 项目做对。