结论先行
“问卷结果导出成表格”听上去像一个一次性导出功能，但企业版做的是可协作、可分享、可持续刷新的 survey dashboard。它同时踩了 survey、documents、spreadsheet collaboration 三条链，所以绝不是把答案塞进一张静态 Excel。
第一层：入口或表面动作
squarey_survey 这边，get_survey_results_for_spreadsheet() / _build_spreadsheet_data() 会把问卷结果组织成二维结构，并直接在单元格 A1 放入 =ODOO.SURVEY(<id>) 公式。重点在这里：Spreadsheet 并不把问卷结果拷贝成死数据，而是通过 Odoo 公式把 survey 当成一个数据源。这就意味着后续的展示、刷新、透视都可以留在表格引擎内部做。
第二层：真正的业务护栏
文档层负责分享与只读访问。documents_spreadsheet.controllers.documents.documents_spreadsheet() 会基于 access_token 返回序列化快照与 revisions；documents_document._check_spreadsheet_share() 又会校验 link sharing 权限、frozen spreadsheet 可写性、token 是否匹配。于是浏览器拿到的不是一个裸 JSON，而是一份受文档权限保护的协作状态。
第三层：状态落点与边界
协作层在 spreadsheet_edition.spreadsheet_mixin.dispatch_spreadsheet_message() 里更明显。每个协同消息都带 serverRevisionId，服务端只接受顺序正确的更新；save_spreadsheet_snapshot() 若发现 revision 不一致，就抛并发更新错误。换句话说，Survey dashboard 不是“后台重生成一次表格，前端覆盖掉”，而是在协同表格协议里持续承载 survey 数据。
为什么这套设计更稳
这条链特别适合前端分类，因为它的核心不在 ORM，而在“浏览器拿到的是哪一种状态”。是快照？是 revisions？是只读 token？是可编辑链接？企业版把这几层拆开后，用户既能把问卷变成 live dashboard，又不会因为多人同时打开文档就把结果写乱。
实战启示
如果你想二开类似能力，最危险的做法就是每次问卷提交后直接重写整张 spreadsheet JSON。那会绕开 revision 顺序控制，也会让分享 token 与文档权限失去意义。企业版真正优雅的地方，是让 Survey 只提供数据源，让 Documents 守访问边界，让 Spreadsheet 协议守并发一致性。
DISCUSSION
评论区