Studio 如果只是前端改个标签，那它根本撑不起生产环境；真正难的是每一次“点点点”都要对应一套可回放、可导出的后端变更。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/web_studio/models/ir_model.pyenterprise/web_studio/models/ir_ui_view.pyenterprise/web_studio/tests/test_approval.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
Studio 真正难的地方不是拖拽，而是拖拽之后这些改动如何变成可持久化、可导出、可缓存、可审计的系统配置。企业版 web_studio 在 xmlid、视图缓存、模型元数据和审批按钮上都做了不少防呆。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 web_studio 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. 自定义必须有稳定 xmlid
create_studio_model_data()、sanitize_for_xmlid() 与 ir_model_data 的 create/write 钩子说明，Studio 生成的对象不是匿名草稿，而要有稳定标识才能导出、升级与复用。
2. 视图缓存必须知道哪些改动会失效
ir_ui_view._get_view_cache_key()、_postprocess_debug_to_cache()、get_views() 说明 Studio 修改不会只改数据库一行，还要驱动正确的缓存键失效与视图重算。
3. 按钮审批不是“加个按钮属性”
studio_approval.py 里的规则解析、委托与测试用例表明，Studio 对按钮审批做的是流程约束，不是装饰性显隐。
三、最容易被误解的边界
- 把 Studio 当作纯前端配置，不为自定义生成稳定 xmlid。
- 改了视图却不理解缓存键与 postprocess，最终出现“明明改了却没生效”。
- 给业务按钮加审批时只看 UI，不看规则、委托和权限边界。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先查对应自定义对象有没有 studio xmlid。
- 再看 view cache key 是否因目标字段/视图变化而更新。
- 最后通过审批测试思路核对按钮规则是否真的拦截了动作。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
Studio 成熟的地方，在于它把“低代码改界面”翻译成一套能被 Odoo 框架长期承认的元数据操作。
DISCUSSION
评论区