必须先回收基表dml权限再授予视图select权限，否则用户可绕过视图直写数据；postgresql需revoke insert/update/delete并显式grant视图权限，mysql依赖有效definer，sql server还需补函数和跨库权限。
只给视图 SELECT 权限，不等于用户就只能查视图——必须显式切断对基表的访问链。
PostgreSQL：先 REVOKE 基表权限，再 GRANT SELECT 视图
PostgreSQL 视图不自动隔离权限。如果用户对 orders 表仍有 INSERT 权限，哪怕你只给了 v_orders_summary 的 SELECT，他仍能绕过视图直写数据。
- 先查当前权限：
SELECT grantee, privilege_type FROM information_schema.role_table_grants WHERE table_name = 'orders'; - 回收基表 DML 权限（注意别用
REVOKE ALL，否则会误撤SELECT）：REVOKE INSERT, UPDATE, DELETE ON orders FROM readonly_user; - 再授视图权限：
GRANT SELECT ON v_orders_summary TO readonly_user; - 确认视图定义不含
WITH CHECK OPTION（只读场景不需要，反而可能引发意外报错）
MySQL：依赖 SQL SECURITY DEFINER + 显式 GRANT 视图
MySQL 视图默认以 DEFINER 身份执行，这是实现“仅视图可读”的关键前提。若 DEFINER 不存在或权限不足，SELECT 会直接失败。
- 建视图时必须显式指定有效
DEFINER：CREATE VIEW v_user_basic AS ... SQL SECURITY DEFINER; -
DEFINER账号（如'admin'@'localhost'）必须拥有底层表users的SELECT权限 - 只对视图授权：
GRANT SELECT ON mydb.v_user_basic TO 'reporter'@'%'; - 务必用
SHOW GRANTS FOR 'reporter'@'%'复核——结果里不能出现任何基表名（如mydb.users）
SQL Server：视图权限不继承，还要补 REFERENCES 和函数权限
在 SQL Server 中，即使你 GRANT SELECT ON [dbo].[v_customers]，用户仍可能报错 The SELECT permission was denied on the object——因为视图背后可能调用了函数或跨库引用。
- 检查视图定义：
SELECT OBJECT_DEFINITION(OBJECT_ID('v_customers')); - 若含自定义函数（如
dbo.fn_mask_email），需额外授权：GRANT EXECUTE ON dbo.fn_mask_email TO readonly_user; - 若引用其他数据库对象（如
OtherDB.dbo.Customers），目标库中该用户也得有对应SELECT权限 - 避免用
db_datareader角色批量放权，它会让视图级控制彻底失效
最易被忽略的一点：所有数据库都存在权限缓存。授完权后，用户可能需要断开重连，或执行 FLUSH PRIVILEGES（MySQL）/ DBCC FLUSHPROCINDB（SQL Server）才能生效。别在连接未重置的情况下反复测试权限是否生效。
