视图本身不防SQL注入，但通过仅授予视图SELECT权限并收回基表权限，可限制注入能获取的数据范围；需配合参数化查询、最小权限和错误屏蔽才有效。
用视图限制 SQL 注入能查到的数据范围
视图本身不防注入，但能大幅缩小攻击者通过注入拿到的数据边界。关键不是“用了视图就安全”，而是把 SELECT 权限只给视图、不给基表，让注入语句只能查到视图定义里暴露的字段和行。
- 必须显式收回用户对基表的
SELECT权限，否则视图形同虚设 - 视图不能带参数，所以动态过滤（比如按当前用户 ID）得靠
CURRENT_USER()或SESSION_USER()实现，且数据库要支持在视图中用这些函数（PostgreSQL 支持，MySQL 5.7 不支持，8.0+ 部分支持） - 如果视图用了
UNION或聚合函数，注入后ORDER BY或UNION SELECT可能报错或被截断，反而暴露逻辑——这不是保护，是副作用
MySQL 中创建带行级过滤的视图示例
假设业务表 orders 有 user_id 字段，想让每个用户只能看到自己的订单。MySQL 8.0+ 可以这样写：
CREATE VIEW my_orders AS SELECT id, amount, status, created_at FROM orders WHERE user_id = CAST(SUBSTRING_INDEX(CURRENT_USER(), '@', 1) AS UNSIGNED);
注意：CURRENT_USER() 返回 username@host，这里假设用户名就是数字 ID；若用的是 UUID 或邮箱前缀，得换更稳妥的提取方式（比如用应用层传入 session token 并存入 USER() 注释区，再配合自定义函数解析）。
- MySQL 5.7 不允许视图
WHERE中调用CURRENT_USER()，强行创建会报错ERROR 1351 (HY000): View's SELECT contains a subquery in the WHERE clause -
DEFINER必须是有权限读基表的高权限账号（如'admin'@'%'），否则视图执行时会因权限不足失败 - 视图上不能建索引，
WHERE条件里的字段如果没在基表上建索引，查询性能会明显下降
PostgreSQL 中用行级安全策略（RLS）替代视图更可靠
视图在 PostgreSQL 里也能用，但 RLS 是更直接、更可控的方案。它作用于基表，不需要重写所有查询为视图引用。
- 先启用 RLS：
ALTER TABLE orders ENABLE ROW LEVEL SECURITY; - 再加策略：
CREATE POLICY user_orders_policy ON orders FOR SELECT USING (user_id = current_setting('app.current_user_id', true)::bigint); - 应用需在每次连接后执行：
SET app.current_user_id = '123';（或用连接池自动注入） - RLS 策略优先级高于视图，即使攻击者绕过视图直查基表，RLS 仍生效——这是比视图更硬的隔离
视图无法防御的注入类型和盲点
视图只约束 SELECT 的结果集，对其他操作完全无效。只要注入点在 UPDATE、INSERT 或存储过程里，视图毫无作用。
- 如果应用用
EXECUTE IMMEDIATE（Oracle/PLpgSQL）或PREPARE+EXECUTE（PostgreSQL）拼接 SQL，且参数未绑定，视图挡不住任何操作 - 错误信息泄露仍是大问题：即使视图限制了字段，
AND 1=(SELECT COUNT(*) FROM pg_user)这类布尔盲注仍可探测系统表存在性 - 视图字段名若与基表一致，攻击者可能通过
(SELECT 1 FROM information_schema.columns WHERE table_name='orders')推出原始结构——别依赖“字段名隐藏”来安全
真正起效的永远是参数化查询 + 最小权限 + 错误信息屏蔽。视图只是其中一层窄带隔离，不是银弹，尤其当 DBA 把 SELECT 权限同时给了视图和基表时，这层就彻底失效了。
