如果你做过 Odoo 定制或与 ORM 打交道，大概率已经在代码或视图中见过“context”这个词。它看似无处不在：字段定义里、XML 视图属性中、Python 逻辑里。对许多人来说，context 常常像一个黑盒，平时没问题，出事时却很难排查。
理解 Odoo 的上下文并非学术演练——它实实在在影响表单的默认值、记录的筛选逻辑、以及计算字段的返回结果。无论是简单的界面调整还是完整模块开发，正确使用上下文能帮你省下大量调试时间。
本文把上下文的核心概念拆解开来，解释它如何在 Odoo 框架中传递，并给出可直接应用到项目中的做法与注意事项。
什么是 Odoo 中的 Context（上下文）
在 Odoo 中，上下文本质上是一个随请求和记录一起传播的 Python 字典。它不是传统意义上的字段类型——在 ORM 中找不到专门的 Context 字段。上下文更像是一种在运行时影响字段或方法行为的“额外信息”载体。
可以把上下文想象成一组隐形的配置项，随操作一起传递：告诉系统某个字段要用默认值、在查询时显示已归档记录、按特定语言计算文本，或在关联记录选择器里应用某个筛选规则。
上下文出现的位置
在 Odoo 的数据模型中，主要会在三类地方遇到上下文：
- Python 字段定义上：在 Many2one、One2many、Many2many 等关系字段声明时传入的 context 参数。
- In XML view attributes: The
contextattribute on<field>tags in form, list, and kanban views. - ORM 环境中：在 Python 代码中通过 self.env.context 读取，或用 self.with_context(key=value) 创建带修改后的上下文记录集。
无论在哪儿出现，context 的本质相同：携带额外信息以决定字段或记录在运行时的具体表现。
上下文在 Odoo 数据模型中的作用机制
上下文在一次用户操作的各个阶段都会流动：从打开表单、填写，到保存记录，都会影响系统如何处理数据。下面是几个常见机制与它们的实际运作方式。
带 default_* 的默认值模式
最常见的上下文用法之一是以 default_ 开头的键。当上下文中包含以 default_ 开头的键时，Odoo 会在新建记录时用它来预填对应字段。
例如，从某个按钮打开新销售订单并在上下文里传入 {"default_partner_id": 42}，那么客户字段打开表单时就已被填为 ID 为 42 的伙伴，用户无需额外步骤即可看到预填内容。
这种模式在构建模块或工作流导航时非常实用，能在不同记录间实现智能衔接而不需要额外后端逻辑。
关系字段上的 context 属性
定义 Many2one、One2many、Many2many 时可以传入 context 参数。这个上下文会在通过该字段的弹窗或下拉创建/加载关联记录时生效。
例如：如果一个指向 res.partner 的 Many2one 字段带有 context={"default_is_company": True}，用户从该字段直接创建新伙伴时，“是否公司”会被默认勾选，从而在不强制的前提下引导用户填写正确类型的数据。
视图 XML 中的上下文
在视图的 XML 里，field 标签上的 context 属性与字段级别作用相同，但它可以是动态的：可以借助 Odoo 的表达式语法引用其他字段的值。
这样你就能构建出一个字段依据另一个字段变化而改变行为的智能表单，这是许多定制场景下用来减少后端代码的常见技巧。
在 Python 中读取与修改上下文
任何模型方法中都可以通过 self.env.context 读取当前上下文字典，它反映了方法被调用时的上下文快照。
若需在调用链中使用修改过的上下文，应使用 self.with_context(key=value)。它返回一个带有新上下文的记录集，原始环境不被修改，是一种非破坏性的使用模式。
常见的内置上下文键
Odoo 自带若干保留键，会触发框架层面的特定行为：
- lang：控制翻译字段使用的语言。
- active_test：设为 False 时搜索结果包含已归档记录。
- no_recompute：阻止对存储型计算字段的重算。
- mail_notrack：在写入操作中禁用消息跟踪。
- allowed_company_ids：多公司环境下控制记录可见性。
- bin_size：让 Binary 字段返回文件大小而非内容本身。
熟悉这些内置键是每个 Odoo 开发者的基本功，因为它们能在不改逻辑代码的情况下控制系统行为。
实际业务场景举例
上下文不仅仅是开发者工具，它在多个业务场景里直接解决实际需求。下面列出常见的五类应用场景，帮助你在项目中快速落地。
1. CRM：在新建线索时预设销售团队
当销售经理在只看自己团队的看板里点击“新建”时，通过在动作上下文里传入 default_team_id，可以让新线索自动归入该团队，避免人工选择出错。
2. 销售：根据客户分组默认设置价目表
当从某个客户分组视图创建报价时，把 default_pricelist_id 放到上下文里可以为报价自动选择合适的价目表，既给出建议又不限制最终编辑权。
3. 库存：在调拨单中筛选出发库位
在仓库操作中，可通过在相关 Many2one 字段上传递带有 domain 的上下文，仅展示某仓库下的库位，确保操作界面简洁并减少错误选择，尤其适用于多仓库场景。
4. 会计：为不同语言的客户生成对应语种的发票行描述
利用 lang 上下文键，开给法国客户的发票可以在行项目中显示法语描述，即便系统内部默认语言是英语，从而提升客户体验与合规性。
5. 自定义模型：在特定视图里显示已停用的产品
运营团队需要同时查看停用和启用的商品时，可在该自定义列表视图的动作上下文里设置 active_test: False。无需改后端代码，就能在特定页面呈现归档记录。
在字段上创建与自定义上下文的方法
在 Odoo 中向字段添加或修改上下文有两条主路：无代码的 Odoo Studio，以及可完全自定义的 Python + XML。选择哪条取决于场景复杂度与可维护性要求。
使用 Odoo Studio
Odoo Studio 能让你在无需写代码的前提下调整字段属性。对于关系字段，Studio 提供了一个上下文配置项，可以设置在从该字段新建记录时应用的默认值。
这对简单的预填场景非常方便，比如默认公司、默认负责人或默认分类。但 Studio 对动态上下文（依赖其他字段值的表达式）支持有限，复杂场景仍需技术实现。
使用 Studio 时要注意：它把上下文直接存储在视图里。如果日后对同一视图做模块化的技术扩展，要先检查并处理 Studio 已定义的上下文，避免冲突。
在 Python 中为字段定义上下文
在自定义模块的字段定义里，可以直接通过 context 参数传入静态字典，例如在 Many2one 上设置固定的默认值：
这种静态上下文在每次加载或创建关联记录时始终生效，不会根据当前记录状态变化。若需动态响应记录状态，应把逻辑放到视图层。
在 XML 视图中定义上下文
视图 XML 的 context 属性接受一段在运行时求值的字符串，你可以引用其他字段、当前用户 ID(uid)、活动记录 ID(active_id) 等变量来构建动态上下文：
因此，视图级上下文比字段级上下文更灵活，是构建依赖关系字段行为的标准手段，也是让界面行为对用户更“自然”的常见做法。
通过窗口动作（Window Actions）传递上下文
上下文也可以配置在 ir.actions.act_window 记录上。菜单或按钮打开视图时，动作的 context 会合并到会话上下文里并应用于视图。
把上下文放在动作上通常是最干净的做法：不同入口（比如不同菜单或按钮）可以为同一视图提供不同默认值，而无需修改模型代码。
最佳实践要点
养成一致的使用习惯会让你在 Odoo 中操作上下文变得简单稳健。以下经验适用于模块开发与快速定制场景。
- 把上下文用作建议而非强制。Context 驱动的默认值是为了引导用户而不是约束他们；若需要硬性约束，应使用 domain、约束或 onchange。
- 把需要动态响应记录状态的上下文放在视图层，而不是字段定义上。字段级上下文通常是静态的，视图里的表达式更适合基于当前记录计算的情形。
- 使用 with_context() 而不是直接修改 env.context。Odoo 的环境在一次调用中应保持不可变性，用 with_context() 创建新环境是安全且推荐的做法。
- 有意图地传递上下文键。上下文会在调用链中累积，传入不必要的键可能在其它逻辑中产生副作用，保持上下文精简并只传最必要的信息。
- 利用上下文传递条件标志。常见模式是在上下文里传一个布尔标记（如 from_wizard: True），让某些 compute 或 onchange 在读取到该标记时改变行为，从而避免把工作流状态写入模型字段。
- 为自定义上下文键写注释或文档。上下文是隐形的，其他开发者不容易发现。把自定义键在模块文档或代码注释里记录清楚，便于日后维护。
常见错误与陷阱
与上下文相关的 bug 往往难查，因为上下文在界面上看不见。下面列出一些最常见的错误来源，帮助你快速定位问题。
把 default_* 当作强制默认值
通过上下文设置的默认值只会在通过表单创建记录时生效。如果用 ORM 在后端程序化创建记录但没有传入对应上下文，该默认不会被应用。不要把 context 默认与字段级 default 混淆：代码创建时要显式传入上下文。
直接修改上下文字典
self.env.context 是在调用链中共享的字典，直接修改它可能会无意间影响同一事务中其他代码的行为。应始终使用 self.with_context(new_key=value) 来创建带有改动副本的新环境。
在上下文里塞入过多信息
上下文里的每个键都会一路传递。有些框架方法会检查特定键并切换执行路径，过多或意外的键可能触发不需要的分支。尽量让上下文保持精简。
忘记在需要时传 active_test 来搜索归档记录
默认情况下，search()/search_read() 会过滤掉 active=False 的记录。如果你的逻辑需要包含已归档记录，必须显式传入 active_test: False。忘记这一点在商品和库存定制中非常常见。
Studio 与自定义代码之间的上下文冲突
若 Studio 在视图字段上已经设置了上下文，而你又通过视图继承为同一字段添加技术性上下文，两者可能冲突或被 XML 合并顺序决定性覆盖。在修改前请先检查视图中已有的 Studio 配置，特别是在混用 Studio 与模块化定制时。
总结要点
上下文在 Odoo 中承担了大量隐性逻辑。一旦你掌握了它在字段定义、视图属性和 ORM 环境中的流动方式，就可以更精细地控制数据模型的行为。
主要结论很明确：用 default_* 来给用户智能建议但不要强制；需要动态行为时把上下文放到视图而非字段定义；永远用 with_context() 而不是就地修改上下文；保持上下文精简，避免影响系统其它部分。
无论你是在看 Odoo 字段教程、开发自定义模块，还是排查某个字段的异常行为，理解上下文的工作原理都会是解决问题的关键一环。
在 Dasolo，我们帮助企业将 Odoo 与其业务流程深度匹配：实现、定制并优化系统。如果你在某个含上下文的定制上遇到疑问，或希望有人评估你的 Odoo 实施方案，我们可以提供支持。
请通过我们的 联系我们的页面 告诉我们你的需求。我们与各类规模的企业合作，帮助他们让 Odoo 真正按业务需要运转。