你在ADT里做server-driven UI的时候，最容易碰到一种别扭感，用户明明改了一个字段，界面上另外几个字段却还停在旧值，或者某个区域本来应该马上隐藏、禁用、缩小候选范围，结果还是一副没反应过来的样子。这个时候，真正救场的东西，不是多写几个前端事件，也不是把整页重新刷一遍，而是把side effect设计好。你给出的这份材料里，对它的定义很直接，用户在界面上做了某个交互之后，系统会自动触发一段逻辑，去调整数据模型，或者调整界面本身，例如改掉其他字段的值，或者把某些字段隐藏起来。这个定义很贴近开发现场，也很接近你在项目里真正会遇到的问题。把这个概念放到更大的SAP语境里看，就更清楚了。SAP官方在ADT的server-driven UI文档里说明，这类界面可以完全由ABAP在服务端构建，再在Eclipse里显示出来。另一条线是在RAP官方文档里，side effects被用于在草稿场景里重载数据、权限、消息，或者触发determine action，目的是让界面在用户改动数据后还能保持一致性。两者不是同一套技术外壳，但它们处理的是同一类工程问题，用户已经动了数据，你不能让界面继续装作没看见。(