Odoo 模块交付笔记：模型、视图与扩展点

Odoo 以模块为单位扩展 ERP 能力：模型、视图、权限与数据文件一起版本化。企业定制常见诉求是「快上线、可升级」，这与少改核心、多走扩展点并不矛盾。本文从模块生命周期、ORM、视图继承与安全规则几方面做笔记。

模块与清单文件

__manifest__.py 声明依赖、版本与 data 加载顺序。依赖顺序错误会导致字段或记录未就绪就执行 XML。升级路径上，模型变更尽量配套迁移脚本或 init/post_init 钩子，避免手工改生产库。

命名空间与版本

自定义模块使用明确前缀，降低与社区模块或未来官方字段冲突的概率。版本号与变更日志帮助多环境对齐。

模型层优先

业务规则放在 models：字段定义、SQL 约束、@api.constrains、计算字段与 inverse。视图负责展示与交互，不要把复杂业务写进仅前端可见的逻辑里，否则 API 与其它入口会绕过校验。

继承模型

_inherit 扩展既有模型时，保持方法 super 链完整；新增字段命名避免与上游未来字段撞车。对重型计算字段，注意依赖与批量性能。

视图与 XPath

XML 继承通过 XPath 定位节点：选择稳定锚点（如 name 属性），避免依赖易变结构。attrs 控制可见与只读，与权限规则一致，避免出现「界面能点但服务端拒绝」的糟糕体验。

QWeb 与报表

报表模板可复用 QWeb 片段；性能上注意循环与大数据量分页。邮件模板与活动类型尽量走官方集成，减少私有补丁。

权限与多公司

ir.model.access 定义模型级 CRUD；记录规则限制行级范围。多公司场景下 company_id 与规则要一致，防止跨公司读写。调试时可用超级用户验证规则，再回落到真实用户测试。

审计与日志

关键写操作可接 mail.thread 或自定义消息，满足审计要求；敏感字段变更记录谁在何时改了什么。

与工作流和集成

优先使用官方 mail、activity、服务端动作与自动化规则；与外部系统对接时，把同步与重试放在队列或定时任务里，避免请求线程长阻塞。

小结

可持续的 Odoo 交付，关键是把业务约束沉到模型与权限层，把视图当作呈现。模块边界清晰，升级时才能少踩坑。