在 SAP HANA 项目里写存储过程时，很容易遇到一种看起来相当普通的需求。业务希望把表名、列名、过滤条件，甚至准备创建的对象名称作为参数传进过程里，由程序在运行期间决定最终执行哪一条 SQL。如果只是普通查询，这件事通常不复杂。一个订单号、客户编号、日期范围或者状态值，都可以作为参数交给 SQLScript，再让数据库完成过滤。麻烦往往从表名开始。假设我们的程序收到一个表名，业务希望运行类似SELECT * FROM 某张表的逻辑。这里的表名不是普通数据，而是 SQL 语法结构的一部分。数据库在解析 SQL 时，需要知道它究竟要访问哪个对象，因此很多地方无法像普通WHERE条件那样直接绑定一个变量。再往前走一步，如果业务要求根据参数创建表，甚至动态决定 Schema、表名、列名，问题会更加明显。这正是 SAP 在SQLScript Security Considerations中专门讨论Dynamic SQL与Escape Code的原因。SAP HANA Cloud 当前的 SQLScript 安全文档仍然明确提醒，SQLScript 可以读写数据库内容，而某些命令与参数组合会制造数据泄露、数据篡改以及 SQL 注入风险。官方建议尽量使用静态 SQL、检查输入参数、限制过程能力，并谨慎处理动态 SQL。很多安全问题并不是因为 SQLScript 本身不安全，而是因为程序把原本属于数据的数据，拼进了 SQL 语法结构。理解这一点之后，Escape Code这个看起来