入行Odoo开发这些年我经常被刚接触框架的同事问一个问题“self.env到底是什么”很多人能照葫芦画瓢写出self.env[res.partner].browse(id)但一旦遇到权限异常、上下文错乱、性能下降就卡住了。今天干脆把self.env的属性和方法摊开讲一遍每个点都带上实际项目中的使用场景和踩坑记录保证你读完能少走很多弯路。1. 先搞懂一个概念self 不总是同一个东西1.1 模型、记录集和环境三者各管什么在Odoo里有三样东西经常被混在一起模型Model、记录集Recordset和环境Environment。模型是类的定义比如res.partner、sale.order它决定了数据有哪些字段、哪些方法。记录集是一批具体记录的集合可以是空集、单条记录也可以是一堆记录。环境则是这段代码执行时所在的“运行场景”——它包含当前是哪个用户、连接哪个数据库、上下文里有什么参数、公司在哪。self.env就是当前记录集所处的那个环境对象。在普通模型中你写self.env就是拿到当前执行的用户、语言、数据库连接状态然后在它上面调用各种方法去查数据、写数据。可以把它理解成一个“带权限和上下文的数据库会话助手”它知道自己是以什么身份在操作也清楚操作时应该遵守哪些规则。1.2 不同方法里self是什么样的这里有个新手必踩的认知盲区不是所有方法里的self都是同一个东西。在create、write这类ORM内置方法中self往往是具体操作对应的当前记录集。在compute计算字段中self是所有需要计算的那批记录。在onchange中self是一份内存模拟的记录它只包含视图上加载了的字段值并不完整。而default默认值方法中self通常是空记录集。不管self是哪种形态self.env始终存在并且指向同一个运行环境。所以当你在一个方法里不确定self到底有没有记录时优先用self.env去拿模型和环境可读性和安全性都会好很多。1.3 为什么Odoo把环境单独拿出来设计Odoo没有把环境信息做成全局变量而是每个记录集都携带一个env引用。这种设计的核心原因是Odoo在同一个请求里可能会切换不同的用户身份、不同的公司、不同的语言和上下文如果做成全局变量切换时容易出现数据串线。比如一个操作需要临时以管理员身份读取一条伙伴数据只需要self.env[res.partner].sudo().browse(id)这个sudo()并不会影响别处的代码因为sudo()返回了一个新的环境原环境仍然是原样。这种隔离机制让权限切换、上下文变化都可以精确控制在极小的代码范围内不用全局考虑状态恢复问题。2. 环境自带的核心属性日常开发中最值钱的信息2.1 env.cr数据库游标双刃剑env.cr是当前环境的数据库游标它可以让你直接执行原生SQL。最常见的用法是self.env.cr.execute(SELECT id, name FROM res_partner WHERE name ILIKE %odoo%) rows self.env.cr.dictfetchall()我推荐优先用dictfetchall()而不是fetchall()因为前者返回字典列表字段名一目了然代码可读性高很多。但cr是一把双刃剑。直接用SQL绕过了ORM的权限机制、缓存机制和记录规则稍不注意就容易出现数据越权问题。另外在Odoo的请求生命周期里事务是由框架统一管理的你不需要也不应该自己加commit()否则会出现事务边界混乱。一个折中方案是能用ORM查的尽量用ORM只有遇到ORM写起来特别费力、而SQL又明显更合适的场景才用cr。比如排名统计、跨多表的复杂聚合报表这种场景直接写SQL反而清晰。2.2 env.uid和env.user到底该用哪个env.uid是一个整数比如2env.user是res.users的一条记录集。两者都能拿到当前用户区别在于使用场景。如果你只需要判断“当前用户是不是管理员”可以用env.uid 1这种数值比较性能好、不用查库。如果你需要读用户的某些字段比如邮箱、所属组、语言偏好那就应该用env.useruser_email self.env.user.email这里有个细节要提醒你如果一个用户被删除了env.user访问时可能会抛MissingError但env.uid仍然只是个数字不会报错。所以做底层工具类代码时优先保留uid的判断逻辑可以省去很多异常处理。2.3 env.company和env.companies多公司数据隔离的关键在Odoo的多公司场景下env.company返回当前公司env.companies返回当前用户有权限访问的公司集合。这个差异如果没注意很容易造成数据错配。比如你要创建一条公司相关的记录但某些字段值是从另一家公司复制过来的此时如果用env.company容易忽略用户实际可以访问的范围。在记录规则依赖公司列表时env.companies尤其重要visible_companies self.env.companies再比如你需要在代码里判断当前记录是否属于用户可见公司if record.company_id in self.env.companies: # 可以显示或操作很多权限规则里搜索不到的记录往往不是没权看而是company_id不在env.companies范围内。排查权限问题时优先看一下这两者的值。2.4 env.context和env.lang上下文里藏着的坑env.context是一个字典包含请求的上下文信息比如语言lang、时区tz、用户ID等。另外还有大量以default_开头的默认值键比如default_partner_id。我在项目里遇到过这样一个案例前端某个按钮跳转并传了{default_type: customer}到上下文后端在向导页面创建记录时一切正常但只要在哪里一次search把这段上下文带过去了后续代码再create一条记录这条记录的类型也会莫名其妙被默认成customer排查了很久才发现是上下文泄漏。所以记住一个原则永远不要直接修改env.context。需要调整上下文时用with_context()生成新环境。读上下文字段时也要用self.env.context.get(key)而不是直接访问避免KeyError。env.lang则是上下文中语言部分的快捷方式大部分场景下等价于self.env.context.get(lang)。做多语言数据匹配或需要按语言取值时这个属性很实用。2.5 env.ref()用XML ID定位记录的底层逻辑你常在模块数据文件里看到XML ID但代码里要用XML ID找记录时靠的就是env.ref()admin_user self.env.ref(base.user_root) delivery_product self.env.ref(product.product_delivery_01)env.ref()内部会去ir_model_data表里查外部ID对应的模型和记录然后返回该记录。它的一个隐藏特性是如果找不到会抛出ValueError所以在外界输入可能不存在的情况下建议加个保护record self.env.ref(my_module.my_xml_id, raise_if_not_foundFalse)另外要注意env.ref()返回的已经是带环境权限的记录集如果当前用户没有权限读同样会报权限错误。需要绕过权限时记得用self.env.ref(xxx).sudo()。3. 主要方法的内在逻辑查询、写入与环境切换3.1 env[model.name]拿到模型的空记录集env[res.partner]返回res.partner的一个空记录集这是后续一切操作的入口。用空记录集调search、browse、create是Odoo最标准的写法。Partner self.env[res.partner] partners Partner.search([(is_company, , True)]) new_partner Partner.create({name: 测试公司})有个习惯值得养成当同一个模型被反复使用时先用一个变量接收空记录集比如上面的Partner不仅减少代码重复也能避免每行都去env[res.partner]查找模型定义带来的小幅性能开销。需要说明的是在Odoo中env[model_name]和env[model_name]本质上都会走到Environment.__getitem__区别只在于如果你传入的是一个变量省去了字符串引号比如从方法参数拿到的模型名时直接写self.env[model_name]即可。此时如果模型不存在Odoo会抛出KeyError定位问题很容易。3.2 search和browse两种读取方式的分工在日常数据读取中search负责按域条件筛选记录browse负责按ID获取记录。# 搜索所有类型为customer的伙伴且只取前10条 partners self.env[res.partner].search( [(is_company, , True)], limit10, ordername asc ) # 通过ID列表获取记录 partner self.env[res.partner].browse(partner_id)这里有几个使用技巧第一如果只需要统计数量用search(..., countTrue)它不会加载记录集速度会快很多count self.env[res.partner].search_count([(is_company, , True)])第二browse接收的可以是单个整数、整数列表、元组也可以是已存在的记录集。它是惰性加载的——browse本身不会立刻查库只有当你访问字段时才真正查询。这就意味着在循环里用browse并不一定比批量search慢但要注意不要在循环里反复browse同一条记录那样会产生重复查询。第三search_read是一个高效的组合操作直接返回字典列表data_list self.env[res.partner].search_read( domain[(is_company, , True)], fields[id, name, email], limit50 )这种写法在写接口和报表服务时非常好用可以避免构造大量临时记录集而且只读取你需要的字段对性能更友好。3.3 create、write和unlink写操作的正确姿势create在单个模型上接收一个字典批量创建也可以接收字典列表批量创建partners self.env[res.partner].create([ {name: 公司A, is_company: True}, {name: 公司B, is_company: True}, ])write是批量更新方法名本身已经说明它是按多个ID生效的partners.write({phone: 12345678})unlink删除记录同样支持批量self.env[res.partner].browse(ids).unlink()写操作有几个容易忽略的细节。其一create和write会触发计算字段、约束、自动化动作这在某些场景下会拖慢性能如果只是写底层数据且确定不动业务逻辑可以考虑直接SQL但不建议新手这么做。其二create返回一个包含新记录的空记录集随后操作新记录时直接基于返回值继续做不要重新browse。其三删除记录要小心关联数据优先考虑归档字段或状态字段而不是物理删除。3.4 sudo、with_user、with_context、with_company环境切换四件套这四个方法是我认为env里最需要吃透的方法它们分别解决权限、用户、上下文和公司四个维度的问题。# sudo: 生成一个跳过权限检查的新环境 partner self.env[res.partner].sudo().browse(pid) # with_user: 模拟另一个用户执行代码 demo_env self.env.with_user(self.env.ref(base.user_demo)) products demo_env[product.product].search([]) # with_context: 在指定上下文中执行 lang_product self.env[product.product].with_context(langen_US).browse(pid) # with_company: 指定公司环境 company_a self.env.ref(base.main_company) product_with_company self.env[product.product].with_company(company_a).browse(pid)这些方法返回的都是新环境对象不会影响原环境。在写代码时最好把环境切换控制到最小范围。比如下面两种写法# 不推荐的写法整个模型都给了sudo权限 all_products self.env[product.product].sudo().search([]) # 推荐的写法只对读取这条记录用sudo product self.env[product.product].sudo().browse(pid)范围控制得越小越不容易把权限漏洞带到整个业务流程里。3.5 在非模型代码里手动构造envself.env并不是永远都能直接拿到的。在定时任务入口、外部脚本、自定义命令行工具里你需要手动构造环境。最常见的写法是通过odoo.registry拿数据库连接from odoo import api, SUPERUSER_ID db_name your_database registry odoo.registry(db_name) with registry.cursor() as cr: env api.Environment(cr, SUPERUSER_ID, {}) partners env[res.partner].search([])在旧版《Odoo开发入门与精通》相关的资料里还经常看到openerp.api.Environment这种写法在新版本中都已经统一到odoo.api.Environment了。采用with registry.cursor()的好处是事务结束自动提交或回滚不用手动干预。如果你在模型方法内部需要拿到一个全新的环境比如完全脱离当前上下文做一次干净查询也可以用new_env api.Environment(self.env.cr, self.env.uid, {})不过这种写法要看清楚cr还是同一个游标还是会在当前事务内执行并不会开启新事务。4. 我在实际项目中踩过的坑4.1 N1查询循环里search的危害一开始写Odoo模块时我特别容易写出这种代码for order in orders: partner self.env[res.partner].search([(id, , order.partner_id.id)]) partner_name partner.name看起来逻辑没毛病但每条search都会发起一次数据库查询循环100条订单就查100次伙伴表。此时更合理的做法是一次性把伙伴ID收集起来然后一次性查询partner_ids orders.mapped(partner_id.id) partners self.env[res.partner].browse(partner_ids)或者干脆直接通过关联字段读取比如order.partner_id.name本身已经懒加载并缓存了不需要专门去search。在问题定位阶段Odoo自带的日志模式非常好用。启动服务时加上--log-leveldebug_sql就能看到每一条SQL查询。如果发现某个页面请求后SQL数量异常多先别急着看代码逻辑直接从SQL数量往回找循环。4.2 上下文泄漏default_开头的key引发的问题前面提到过default_开头的上下文键这里再展开讲一个真实案例。有一次我处理一个销售订单用户从某个对账单页面跳转到新建订单URL里带了default_partner_id123。我在这段业务逻辑里有一段代码读取了self.env.context并把它塞进了后续的create调用ctx self.env.context order self.env[sale.order].with_context(ctx).create(vals)结果新订单里partner_id被自动带上了123而用户本想在界面上自己重新选择客户。因为视图字段的default实现机制就是读取上下文中的default_键当你把整个上下文原封不动传给create时默认值会重新应用一遍。后来我改成只把必要参数放进去不再全程携带default_键问题才彻底消失。所以经验是上下文不是越大越全越好传递时要有意识过滤掉default_开头的键。如果你只是想把语言、时区之类的信息带过去直接保留少量键或新建一个小字典即可。4.3 sudo()的范围控制权限放太宽会出事sudo()非常强大但也非常危险。它本质上是让代码绕过权限规则去操作数据适合用来处理系统底层的、用户不应干预的数据。有一次我写了一个自动同步合同状态的定时任务因为涉及多个模型我图省事在方法开头直接加了def _sync_contracts(self): self.sudo() # 这种写法是无效且危险的等等很多资料告诉你self.sudo()是让整个记录集切换环境但实际它返回一个新记录集原self并不会变。要想对当前记录集生效需要写成self self.sudo()。而往往有人误以为调用过一次就全局生效导致后续校验权限的代码失效普通用户能通过某些路径触发管理员权限的逻辑。正确的做法是把sudo()收敛到最小范围比如只对某个模型查询用sudocontracts self.env[contract.contract].sudo().search([...])4.4 onchange里的env操作让表单卡了半天onchange方法在表单视图里触发非常频繁用户每改一个字段就可能触发一次。我在一个客户项目里在某个onchange里顺手用self.env[sale.order].search([])统计历史订单每次切换客户都触发全表搜索页面卡得让人怀疑人生。排查后发现onchange建议只做内存级的字段联动计算不要做重量级的搜索和创建。如果确实需要展示统计信息可以考虑用计算字段并通过api.depends控制重算时机或者把统计逻辑放到服务端方法中由按钮触发而不是每次字段变化都跑。另外onchange中的self是一份模拟记录集访问它上面未在视图里加载的字段可能取到空值或不可预期的值所以尽量只依赖当前已经改变的字段和视图上已有字段。5. 一些实用习惯和项目建议5.1 代码规范env相关写法的一些约定我在带团队开发Odoo项目时会特别强调几条关于env的代码约定这些约定看起来琐碎但非常有效。第一所有模型类名和记录集的变量命名要清晰。比如self.env[res.partner]不要到处写封装成局部变量Partner self.env[res.partner]后续统一用Partner。第二凡是调用sudo()、with_user()、with_company()切换环境的地方一定要加注释说明为什么需要切换否则半个月后自己再看都不一定记得。第三不要在compute方法里频繁创建记录计算字段是幂等优先的里面写create会引发幽灵数据问题。5.2 怎么快速排查env相关的问题当你怀疑env相关的问题时我有几个快速定位手段。先看self.env.context里是否有奇怪的键值特别是default_和active_id等。再确认sudo()是否出现在不该出现的位置with_user切换的用户是不是预期用户。接着用日志模式跑一遍请求看SQL数量和耗时集中在哪个模型上。如果你在排查权限问题时建议临时写一个方法打印当前环境信息api.model def debug_env(self): print(uid:, self.env.uid) print(user:, self.env.user.login) print(company:, self.env.company.name) print(companies:, self.env.companies.mapped(name)) print(context:, self.env.context)这种方式比反复打断点来得更快尤其在服务端日志环境下一眼就能看清当前代码到底以什么身份在跑。5.3 为什么国内Odoo社区里env的问题反复被问作为一个经常在社区里翻帖子的人我发现关于self.env的问题在国内社区出现频率非常高。究其原因一方面是Odoo国内资料本来就参差不齐很多讲解只给代码不给原理新手对着教程抄完能跑一旦环境发生变化就懵了另一方面是Odoo本身学习曲线比较陡模型、记录集、环境这三层概念和传统MVC框架里的“模型层”不是一个东西很多人拿Django、Rails的思维套Odoo自然觉得别扭。另外国内很多项目并没有成熟的中文Odoo人才梯队很多开发者是半路转过来的基础概念没有系统梳理过。所以遇到环境、上下文、权限这类偏底层问题时只能靠一次次试错积累经验。这篇关于self.env的文章也算是我把这几年的积累做一个系统性的梳理希望后来者能少踩一些我当年踩过的坑。环境这套机制一旦理解了它在程序中的角色再回头看那些sudo、with_context、search代码你会觉得一切都顺理成章。建议你下次写模块前先把自己代码里所有self.env的用法拉出来看一遍该封装的封装、该清理的清理、该控制范围的控制好范围代码质量会直接上一个台阶。
Odoo开发核心：self.env原理、方法与踩坑实战指南
入行Odoo开发这些年我经常被刚接触框架的同事问一个问题“self.env到底是什么”很多人能照葫芦画瓢写出self.env[res.partner].browse(id)但一旦遇到权限异常、上下文错乱、性能下降就卡住了。今天干脆把self.env的属性和方法摊开讲一遍每个点都带上实际项目中的使用场景和踩坑记录保证你读完能少走很多弯路。1. 先搞懂一个概念self 不总是同一个东西1.1 模型、记录集和环境三者各管什么在Odoo里有三样东西经常被混在一起模型Model、记录集Recordset和环境Environment。模型是类的定义比如res.partner、sale.order它决定了数据有哪些字段、哪些方法。记录集是一批具体记录的集合可以是空集、单条记录也可以是一堆记录。环境则是这段代码执行时所在的“运行场景”——它包含当前是哪个用户、连接哪个数据库、上下文里有什么参数、公司在哪。self.env就是当前记录集所处的那个环境对象。在普通模型中你写self.env就是拿到当前执行的用户、语言、数据库连接状态然后在它上面调用各种方法去查数据、写数据。可以把它理解成一个“带权限和上下文的数据库会话助手”它知道自己是以什么身份在操作也清楚操作时应该遵守哪些规则。1.2 不同方法里self是什么样的这里有个新手必踩的认知盲区不是所有方法里的self都是同一个东西。在create、write这类ORM内置方法中self往往是具体操作对应的当前记录集。在compute计算字段中self是所有需要计算的那批记录。在onchange中self是一份内存模拟的记录它只包含视图上加载了的字段值并不完整。而default默认值方法中self通常是空记录集。不管self是哪种形态self.env始终存在并且指向同一个运行环境。所以当你在一个方法里不确定self到底有没有记录时优先用self.env去拿模型和环境可读性和安全性都会好很多。1.3 为什么Odoo把环境单独拿出来设计Odoo没有把环境信息做成全局变量而是每个记录集都携带一个env引用。这种设计的核心原因是Odoo在同一个请求里可能会切换不同的用户身份、不同的公司、不同的语言和上下文如果做成全局变量切换时容易出现数据串线。比如一个操作需要临时以管理员身份读取一条伙伴数据只需要self.env[res.partner].sudo().browse(id)这个sudo()并不会影响别处的代码因为sudo()返回了一个新的环境原环境仍然是原样。这种隔离机制让权限切换、上下文变化都可以精确控制在极小的代码范围内不用全局考虑状态恢复问题。2. 环境自带的核心属性日常开发中最值钱的信息2.1 env.cr数据库游标双刃剑env.cr是当前环境的数据库游标它可以让你直接执行原生SQL。最常见的用法是self.env.cr.execute(SELECT id, name FROM res_partner WHERE name ILIKE %odoo%) rows self.env.cr.dictfetchall()我推荐优先用dictfetchall()而不是fetchall()因为前者返回字典列表字段名一目了然代码可读性高很多。但cr是一把双刃剑。直接用SQL绕过了ORM的权限机制、缓存机制和记录规则稍不注意就容易出现数据越权问题。另外在Odoo的请求生命周期里事务是由框架统一管理的你不需要也不应该自己加commit()否则会出现事务边界混乱。一个折中方案是能用ORM查的尽量用ORM只有遇到ORM写起来特别费力、而SQL又明显更合适的场景才用cr。比如排名统计、跨多表的复杂聚合报表这种场景直接写SQL反而清晰。2.2 env.uid和env.user到底该用哪个env.uid是一个整数比如2env.user是res.users的一条记录集。两者都能拿到当前用户区别在于使用场景。如果你只需要判断“当前用户是不是管理员”可以用env.uid 1这种数值比较性能好、不用查库。如果你需要读用户的某些字段比如邮箱、所属组、语言偏好那就应该用env.useruser_email self.env.user.email这里有个细节要提醒你如果一个用户被删除了env.user访问时可能会抛MissingError但env.uid仍然只是个数字不会报错。所以做底层工具类代码时优先保留uid的判断逻辑可以省去很多异常处理。2.3 env.company和env.companies多公司数据隔离的关键在Odoo的多公司场景下env.company返回当前公司env.companies返回当前用户有权限访问的公司集合。这个差异如果没注意很容易造成数据错配。比如你要创建一条公司相关的记录但某些字段值是从另一家公司复制过来的此时如果用env.company容易忽略用户实际可以访问的范围。在记录规则依赖公司列表时env.companies尤其重要visible_companies self.env.companies再比如你需要在代码里判断当前记录是否属于用户可见公司if record.company_id in self.env.companies: # 可以显示或操作很多权限规则里搜索不到的记录往往不是没权看而是company_id不在env.companies范围内。排查权限问题时优先看一下这两者的值。2.4 env.context和env.lang上下文里藏着的坑env.context是一个字典包含请求的上下文信息比如语言lang、时区tz、用户ID等。另外还有大量以default_开头的默认值键比如default_partner_id。我在项目里遇到过这样一个案例前端某个按钮跳转并传了{default_type: customer}到上下文后端在向导页面创建记录时一切正常但只要在哪里一次search把这段上下文带过去了后续代码再create一条记录这条记录的类型也会莫名其妙被默认成customer排查了很久才发现是上下文泄漏。所以记住一个原则永远不要直接修改env.context。需要调整上下文时用with_context()生成新环境。读上下文字段时也要用self.env.context.get(key)而不是直接访问避免KeyError。env.lang则是上下文中语言部分的快捷方式大部分场景下等价于self.env.context.get(lang)。做多语言数据匹配或需要按语言取值时这个属性很实用。2.5 env.ref()用XML ID定位记录的底层逻辑你常在模块数据文件里看到XML ID但代码里要用XML ID找记录时靠的就是env.ref()admin_user self.env.ref(base.user_root) delivery_product self.env.ref(product.product_delivery_01)env.ref()内部会去ir_model_data表里查外部ID对应的模型和记录然后返回该记录。它的一个隐藏特性是如果找不到会抛出ValueError所以在外界输入可能不存在的情况下建议加个保护record self.env.ref(my_module.my_xml_id, raise_if_not_foundFalse)另外要注意env.ref()返回的已经是带环境权限的记录集如果当前用户没有权限读同样会报权限错误。需要绕过权限时记得用self.env.ref(xxx).sudo()。3. 主要方法的内在逻辑查询、写入与环境切换3.1 env[model.name]拿到模型的空记录集env[res.partner]返回res.partner的一个空记录集这是后续一切操作的入口。用空记录集调search、browse、create是Odoo最标准的写法。Partner self.env[res.partner] partners Partner.search([(is_company, , True)]) new_partner Partner.create({name: 测试公司})有个习惯值得养成当同一个模型被反复使用时先用一个变量接收空记录集比如上面的Partner不仅减少代码重复也能避免每行都去env[res.partner]查找模型定义带来的小幅性能开销。需要说明的是在Odoo中env[model_name]和env[model_name]本质上都会走到Environment.__getitem__区别只在于如果你传入的是一个变量省去了字符串引号比如从方法参数拿到的模型名时直接写self.env[model_name]即可。此时如果模型不存在Odoo会抛出KeyError定位问题很容易。3.2 search和browse两种读取方式的分工在日常数据读取中search负责按域条件筛选记录browse负责按ID获取记录。# 搜索所有类型为customer的伙伴且只取前10条 partners self.env[res.partner].search( [(is_company, , True)], limit10, ordername asc ) # 通过ID列表获取记录 partner self.env[res.partner].browse(partner_id)这里有几个使用技巧第一如果只需要统计数量用search(..., countTrue)它不会加载记录集速度会快很多count self.env[res.partner].search_count([(is_company, , True)])第二browse接收的可以是单个整数、整数列表、元组也可以是已存在的记录集。它是惰性加载的——browse本身不会立刻查库只有当你访问字段时才真正查询。这就意味着在循环里用browse并不一定比批量search慢但要注意不要在循环里反复browse同一条记录那样会产生重复查询。第三search_read是一个高效的组合操作直接返回字典列表data_list self.env[res.partner].search_read( domain[(is_company, , True)], fields[id, name, email], limit50 )这种写法在写接口和报表服务时非常好用可以避免构造大量临时记录集而且只读取你需要的字段对性能更友好。3.3 create、write和unlink写操作的正确姿势create在单个模型上接收一个字典批量创建也可以接收字典列表批量创建partners self.env[res.partner].create([ {name: 公司A, is_company: True}, {name: 公司B, is_company: True}, ])write是批量更新方法名本身已经说明它是按多个ID生效的partners.write({phone: 12345678})unlink删除记录同样支持批量self.env[res.partner].browse(ids).unlink()写操作有几个容易忽略的细节。其一create和write会触发计算字段、约束、自动化动作这在某些场景下会拖慢性能如果只是写底层数据且确定不动业务逻辑可以考虑直接SQL但不建议新手这么做。其二create返回一个包含新记录的空记录集随后操作新记录时直接基于返回值继续做不要重新browse。其三删除记录要小心关联数据优先考虑归档字段或状态字段而不是物理删除。3.4 sudo、with_user、with_context、with_company环境切换四件套这四个方法是我认为env里最需要吃透的方法它们分别解决权限、用户、上下文和公司四个维度的问题。# sudo: 生成一个跳过权限检查的新环境 partner self.env[res.partner].sudo().browse(pid) # with_user: 模拟另一个用户执行代码 demo_env self.env.with_user(self.env.ref(base.user_demo)) products demo_env[product.product].search([]) # with_context: 在指定上下文中执行 lang_product self.env[product.product].with_context(langen_US).browse(pid) # with_company: 指定公司环境 company_a self.env.ref(base.main_company) product_with_company self.env[product.product].with_company(company_a).browse(pid)这些方法返回的都是新环境对象不会影响原环境。在写代码时最好把环境切换控制到最小范围。比如下面两种写法# 不推荐的写法整个模型都给了sudo权限 all_products self.env[product.product].sudo().search([]) # 推荐的写法只对读取这条记录用sudo product self.env[product.product].sudo().browse(pid)范围控制得越小越不容易把权限漏洞带到整个业务流程里。3.5 在非模型代码里手动构造envself.env并不是永远都能直接拿到的。在定时任务入口、外部脚本、自定义命令行工具里你需要手动构造环境。最常见的写法是通过odoo.registry拿数据库连接from odoo import api, SUPERUSER_ID db_name your_database registry odoo.registry(db_name) with registry.cursor() as cr: env api.Environment(cr, SUPERUSER_ID, {}) partners env[res.partner].search([])在旧版《Odoo开发入门与精通》相关的资料里还经常看到openerp.api.Environment这种写法在新版本中都已经统一到odoo.api.Environment了。采用with registry.cursor()的好处是事务结束自动提交或回滚不用手动干预。如果你在模型方法内部需要拿到一个全新的环境比如完全脱离当前上下文做一次干净查询也可以用new_env api.Environment(self.env.cr, self.env.uid, {})不过这种写法要看清楚cr还是同一个游标还是会在当前事务内执行并不会开启新事务。4. 我在实际项目中踩过的坑4.1 N1查询循环里search的危害一开始写Odoo模块时我特别容易写出这种代码for order in orders: partner self.env[res.partner].search([(id, , order.partner_id.id)]) partner_name partner.name看起来逻辑没毛病但每条search都会发起一次数据库查询循环100条订单就查100次伙伴表。此时更合理的做法是一次性把伙伴ID收集起来然后一次性查询partner_ids orders.mapped(partner_id.id) partners self.env[res.partner].browse(partner_ids)或者干脆直接通过关联字段读取比如order.partner_id.name本身已经懒加载并缓存了不需要专门去search。在问题定位阶段Odoo自带的日志模式非常好用。启动服务时加上--log-leveldebug_sql就能看到每一条SQL查询。如果发现某个页面请求后SQL数量异常多先别急着看代码逻辑直接从SQL数量往回找循环。4.2 上下文泄漏default_开头的key引发的问题前面提到过default_开头的上下文键这里再展开讲一个真实案例。有一次我处理一个销售订单用户从某个对账单页面跳转到新建订单URL里带了default_partner_id123。我在这段业务逻辑里有一段代码读取了self.env.context并把它塞进了后续的create调用ctx self.env.context order self.env[sale.order].with_context(ctx).create(vals)结果新订单里partner_id被自动带上了123而用户本想在界面上自己重新选择客户。因为视图字段的default实现机制就是读取上下文中的default_键当你把整个上下文原封不动传给create时默认值会重新应用一遍。后来我改成只把必要参数放进去不再全程携带default_键问题才彻底消失。所以经验是上下文不是越大越全越好传递时要有意识过滤掉default_开头的键。如果你只是想把语言、时区之类的信息带过去直接保留少量键或新建一个小字典即可。4.3 sudo()的范围控制权限放太宽会出事sudo()非常强大但也非常危险。它本质上是让代码绕过权限规则去操作数据适合用来处理系统底层的、用户不应干预的数据。有一次我写了一个自动同步合同状态的定时任务因为涉及多个模型我图省事在方法开头直接加了def _sync_contracts(self): self.sudo() # 这种写法是无效且危险的等等很多资料告诉你self.sudo()是让整个记录集切换环境但实际它返回一个新记录集原self并不会变。要想对当前记录集生效需要写成self self.sudo()。而往往有人误以为调用过一次就全局生效导致后续校验权限的代码失效普通用户能通过某些路径触发管理员权限的逻辑。正确的做法是把sudo()收敛到最小范围比如只对某个模型查询用sudocontracts self.env[contract.contract].sudo().search([...])4.4 onchange里的env操作让表单卡了半天onchange方法在表单视图里触发非常频繁用户每改一个字段就可能触发一次。我在一个客户项目里在某个onchange里顺手用self.env[sale.order].search([])统计历史订单每次切换客户都触发全表搜索页面卡得让人怀疑人生。排查后发现onchange建议只做内存级的字段联动计算不要做重量级的搜索和创建。如果确实需要展示统计信息可以考虑用计算字段并通过api.depends控制重算时机或者把统计逻辑放到服务端方法中由按钮触发而不是每次字段变化都跑。另外onchange中的self是一份模拟记录集访问它上面未在视图里加载的字段可能取到空值或不可预期的值所以尽量只依赖当前已经改变的字段和视图上已有字段。5. 一些实用习惯和项目建议5.1 代码规范env相关写法的一些约定我在带团队开发Odoo项目时会特别强调几条关于env的代码约定这些约定看起来琐碎但非常有效。第一所有模型类名和记录集的变量命名要清晰。比如self.env[res.partner]不要到处写封装成局部变量Partner self.env[res.partner]后续统一用Partner。第二凡是调用sudo()、with_user()、with_company()切换环境的地方一定要加注释说明为什么需要切换否则半个月后自己再看都不一定记得。第三不要在compute方法里频繁创建记录计算字段是幂等优先的里面写create会引发幽灵数据问题。5.2 怎么快速排查env相关的问题当你怀疑env相关的问题时我有几个快速定位手段。先看self.env.context里是否有奇怪的键值特别是default_和active_id等。再确认sudo()是否出现在不该出现的位置with_user切换的用户是不是预期用户。接着用日志模式跑一遍请求看SQL数量和耗时集中在哪个模型上。如果你在排查权限问题时建议临时写一个方法打印当前环境信息api.model def debug_env(self): print(uid:, self.env.uid) print(user:, self.env.user.login) print(company:, self.env.company.name) print(companies:, self.env.companies.mapped(name)) print(context:, self.env.context)这种方式比反复打断点来得更快尤其在服务端日志环境下一眼就能看清当前代码到底以什么身份在跑。5.3 为什么国内Odoo社区里env的问题反复被问作为一个经常在社区里翻帖子的人我发现关于self.env的问题在国内社区出现频率非常高。究其原因一方面是Odoo国内资料本来就参差不齐很多讲解只给代码不给原理新手对着教程抄完能跑一旦环境发生变化就懵了另一方面是Odoo本身学习曲线比较陡模型、记录集、环境这三层概念和传统MVC框架里的“模型层”不是一个东西很多人拿Django、Rails的思维套Odoo自然觉得别扭。另外国内很多项目并没有成熟的中文Odoo人才梯队很多开发者是半路转过来的基础概念没有系统梳理过。所以遇到环境、上下文、权限这类偏底层问题时只能靠一次次试错积累经验。这篇关于self.env的文章也算是我把这几年的积累做一个系统性的梳理希望后来者能少踩一些我当年踩过的坑。环境这套机制一旦理解了它在程序中的角色再回头看那些sudo、with_context、search代码你会觉得一切都顺理成章。建议你下次写模块前先把自己代码里所有self.env的用法拉出来看一遍该封装的封装、该清理的清理、该控制范围的控制好范围代码质量会直接上一个台阶。
