动态SQL视图不能用参数化查询，因视图创建属DDL操作，而参数化仅适用于DML执行阶段；标识符（如表名、列名）必须白名单校验，查询时仍需参数化，优先用函数或物化视图替代动态拼接。
动态SQL视图为什么不能用参数化查询
因为视图定义本身是DDL语句（CREATE VIEW），而参数化查询只作用于DML（如SELECT、INSERT）执行阶段。数据库在创建视图时必须立即解析并固化SQL结构，? 或命名占位符在DDL中不被识别——它们不是语法合法的标识符位置。试图把 WHERE user_id = ? 塞进 CREATE VIEW v AS SELECT ... 会直接报错：ERROR 1064 (42000): You have an error in your SQL syntax。
表名/列名等标识符无法参数化，必须白名单校验
当视图需要按租户切换表前缀（如 tenant_a_users vs tenant_b_users），或按业务类型拼接列（如 SELECT id, name, status_<env>），这些部分属于SQL标识符，不能走参数绑定。此时唯一可靠的做法是：在拼接前强制比对输入值是否落在预设白名单内。
- 用正则严格匹配表前缀：
^[a-z][a-z0-9_]{2,31}$，拒绝含点号、反引号、连字符等非法字符 - 所有可选列名硬编码进字典：
{"prod": "status_prod", "staging": "status_staging"}，用户输入仅作键查找，查不到就拒掉 - 避免“允许字母数字+下划线”这种宽泛规则——
tenant_x`; DROP TABLE users; --仍能通过
运行时视图查询仍需参数化，别以为建完就安全了
很多人以为“视图建好了，后面查它就没事”，这是最大误区。视图只是封装了查询逻辑，一旦你在应用层用字符串拼接去调用它，比如：SELECT * FROM v_user_{tenant_id} WHERE id = '123'，那拼接点仍在应用代码里，漏洞照旧。
- 视图查询本身必须走参数化：用
SELECT * FROM v_user WHERE id = ?，而非拼接id值 - 如果视图名本身动态（如
v_user_{env}），那这个视图名也属于标识符，同样要白名单校验，不能靠过滤单引号解决 - 特别注意ORM场景：Sequelize的
sequelize.query("SELECT * FROM ?? WHERE id = ?", [viewName, id])中，第一个??是标识符占位符（需驱动支持），第二个?是值占位符——二者机制完全不同，混用会失效
替代方案：优先用函数或物化视图绕过动态拼接
真正需要“按需生成视图逻辑”的场景，往往暴露的是设计缺陷。比起在DDL层硬拼，更健壮的路径是把动态性上移到应用或数据库函数层。
- 用MySQL函数封装逻辑：
CREATE FUNCTION get_user_status(env VARCHAR(20)) RETURNS VARCHAR(20) READS SQL DATA ...，视图里直接调用get_user_status('prod') - PostgreSQL可用
pg_get_viewdef()动态检查视图定义，配合行级安全策略（RLS）控制数据可见性，而非靠多个视图隔离 - 若必须多视图，用部署脚本生成（CI/CD阶段），而非运行时拼接——视图名由发布流程决定，不接受用户输入
真正难防的从来不是1' OR '1'='1这种显性payload，而是开发者自己写的format_view_name(tenant_input)函数里，那个没做长度截断、没校验Unicode零宽空格、也没拒绝__双下划线前缀的分支逻辑。
