很多国内 CRM 项目在做自开发 UI 时，会出现一种看似“顺手”、实则后患无穷的技术选择：伙伴团队因为熟悉 ABAP Web Dynpro，于是把它当作主要的自开发 UI 技术，再通过 Transaction Launcher 集成到 CRM WebClient UI 里。表面上能跑、能用，甚至在演示阶段还显得“挺快”；等到系统一上线，用户体验的割裂、稳定性隐患、运维与二次开发成本，就会像欠下的技术债一样连本带利地找上门。
这篇文章把常见问题一口气讲透：为什么会出问题、问题会如何表现、背后的框架机制是什么、以及如果你不得不用 ABAP Web Dynpro，至少要把风险控制在什么边界内。文末也会给出更可持续的路线建议，方便你在 On-Premise、Private Cloud 甚至逐步向 BTP ABAP environment 迁移时有一条清晰的技术决策链路。
误区从哪里来：熟悉感、性能直觉与“能用就行”的交付压力
在不少项目现场，选择 ABAP Web Dynpro 的理由常常是这些：
- 团队对 ABAP Web Dynpro 更熟，开发节奏更快，交付压力下容易倾向“用顺手的工具”
- 觉得 CRM WebClient UI 走 BOL/GenIL、BSP 渲染、组件框架较重，直觉上“性能不如” ABAP Web Dynpro
- 认为把 ABAP Web Dynpro 嵌入 CRM UI 只是一个页面集成，边界清晰，后续维护不会太复杂
问题在于：CRM WebClient UI 的“重”，恰恰是它把大量一致性、事务性、可配置性、可维护性的工作吸收掉了。BOL/GenIL 的分层与
