Odoo 19 后端前端基于 OWL。组件通信三条路：父子用 props；跨层用 env.services（orm、action、notification、dialog）；松耦合广播用总线。选错会导致「改一个角标、半个页面听不到」，或全局单例藏状态无法测试。本文给出选型表、生命周期注意点与可测性要求。
props：能抬升的状态就抬升
父传子数据与回调；子不直接改父状态，通过 callback 上抛。列表行组件保持纯展示，便于单测。避免在深层子组件偷偷读全局可变对象。
env.services：官方能力优先
数据访问走 orm 服务；跳转动作走 action；提示用 notification。自定义服务注册到 registry，注意依赖方向，避免 import 循环。服务应可在测试中 mock。
总线：适合广播，不适合传大对象
例如库存数量变化后刷新菜单角标。组件销毁必须取消订阅，否则泄漏与「幽灵更新」。总线事件名加模块前缀，避免冲突。
常见坑
- 直接操作 DOM 全局变量绕过 OWL 更新。
- 在 willUnmount 外残留 setTimeout/监听。
- 把 recordset 思想硬套到前端可变状态导致难追踪。
验收标准
- 关键交互无脏全局状态。
- 服务可 mock；销毁后无残留监听。
- 改 props 后面界面必更新（手工或单测）。
一个可维护的组件拆分例子
列表页容器负责拉取数据（orm service）与打开动作（action service）；
行组件只接收 props（显示字段 + onSelect 回调）；角标组件订阅总线事件刷新数量，
并在 onWillUnmount 取消订阅。通知失败用 notification 服务，不要 alert。
代码评审清单：有无直接 DOM 查询全局节点、有无未清理监听、服务是否可 mock。
复杂状态优先抬升到容器，而不是兄弟组件互相 bus 风暴。
前端性能：列表虚拟化与按需加载优先；总线事件频率高时做节流，避免角标刷新打满主线程。
代码评审与测试要点
PR 模板勾选：props 是否纯、是否经 env.services 访问 ORM/动作、总线是否成对订阅退订、
有无直接操作全局 DOM。关键交互补一条 Tour 或组件测试。性能上，避免在 render 路径同步打重查询；
列表用分页或懒加载。事件名加模块前缀，例如 chinaodoo-stock-qty-changed。
发现「幽灵刷新」先查未卸载监听。文档中给新人一张通信选型表：父子/跨层/广播。
与后端权限一致：前端隐藏按钮不够，服务端 ACL 仍要拦。
OWL 总线事件字典放模块文档，新增事件要登记消费方。
预生产勾选表需覆盖文章编号 319 全部验收点后再约生产窗口。
将文章编号 319 的配置变更记入发版说明，便于回滚对照。
将文章编号 319 的配置变更记入发版说明，便于回滚对照。
将文章编号 319 的配置变更记入发版说明，便于回滚对照。
将文章编号 319 的配置变更记入发版说明，便于回滚对照。
前端质量门禁
PR 必须回答：状态在哪一层、服务是否 mock、总线是否退订。禁止 alert 与裸 DOM 全局改。
列表性能用分页。事件名登记消费方。权限以后端 ACL 为准。Tour 覆盖关键按钮即可，深业务放 Python 测试。
发布后抽查角标与通知在慢网下的表现。
中国Odoo网｜对照 Odoo 19 企业版 OWL 实践：props / env.services / 总线按场景选型，销毁必退订。