只读API必须确保数据库连接用户对底层表完全不可见，否则视图形同虚设；需逐个回收基表SELECT权限、授予schema USAGE、显式裁剪字段与静态过滤、破坏视图可更新性、禁用SECURITY DEFINER，并锁定API连接用户为只读账号。
只读API 不能直接“查视图就完事”，必须让数据库连接用户对底层表**完全不可见**，否则视图只是个可绕过的装饰层。
为什么直接 GRANT SELECT ON view_name 不够用
PostgreSQL、MySQL 8.0+、SQL Server 都要求：视图能查 ≠ 底层表能查。如果只读账号 api_reader 已被授予过 SELECT 权限在 orders 或 users 表上，它就能绕过视图，直接 SELECT * FROM orders——敏感字段、删除标记、逻辑软删状态全暴露。
常见错误现象：SELECT * FROM v_order_summary 正常返回，但 SELECT payment_method, is_refunded FROM orders 也成功执行，说明权限没真正收窄。
- 先查依赖：用
\d+ v_order_summary（PostgreSQL）或SELECT definition FROM pg_views WHERE viewname = 'v_order_summary'确认视图实际引用了哪些表和字段 - 逐个回收：对每个基表执行
REVOKE INSERT, UPDATE, DELETE, SELECT ON TABLE public.orders FROM api_reader（注意别用REVOKE ALL，会连SELECT也撤掉） - 补 schema 权限：
GRANT USAGE ON SCHEMA public TO api_reader，否则即使有视图权限也会报permission denied for schema public
视图定义里必须显式裁剪 + 静态过滤
视图不是安全边界，是数据出口的“漏斗”。你控制不了调用方怎么写 SQL，只能控制它从这个漏斗里能拿到什么。
- 禁用
SELECT *：哪怕基表只加一列，SELECT *视图就会多吐一列，可能意外暴露updated_by或raw_payload - 跳过敏感字段：比如
SELECT id, order_no, total_amount, created_at FROM orders o JOIN users u ON o.user_id = u.id，不选u.email、o.ip_address - 行级固化：用
WHERE o.status IN ('paid', 'shipped')而不是WHERE o.status != 'cancelled'，避免未来新增状态（如'archived'）被意外包含 - 别用动态函数：避开
CURRENT_USER()、NEXTVAL()、pg_backend_pid()，否则可能泄露执行上下文或触发越权逻辑
PostgreSQL 中要关掉可更新性，而不是加 WITH CHECK OPTION
WITH CHECK OPTION 是给可更新视图用的校验机制，而你的目标是“彻底不可写”。在 PostgreSQL 中，只要视图满足单表、无聚合、主键完整等条件，is_updatable 就会是 'YES'，此时 INSERT INTO v_order_summary 会静默写入 orders 表——哪怕你没授写权限，只要定义者有权限且用了 SECURITY DEFINER，就可能生效。
- 检查现状：
SELECT schemaname, viewname, is_updatable FROM pg_views WHERE viewname = 'v_order_summary' - 强制只读：在视图定义中加入任意一个破坏可更新性的元素，例如
JOIN、GROUP BY、DISTINCT或字段表达式：total_amount::numeric(10,2) AS amount - 别碰
SECURITY DEFINER：默认是INVOKER，更安全；若误设为DEFINER，又没控制好定义者权限，等于开了后门
API 连接字符串里用户名必须锁定为只读账号
再严密的视图和权限设计，一旦 API 用 root、sa 或开发账号连接数据库，就全归零。SQL 注入点、日志打印、ORM 原生查询接口都可能成为突破口。
- 硬编码连接用户：在 Node.js 的
pg.Pool、Python 的sqlalchemy.create_engine或 Go 的database/sql中，user=api_reader必须写死，不能拼接环境变量 - 禁用原始执行：ORM 层关闭
execute()、raw()类接口，只允许select()或find()等受控方法 - 上线前手动验证：用
api_reader登录数据库，执行INSERT INTO orders VALUES (...)和SELECT * FROM pg_tables，确认全部报错
最易被忽略的一点：物化视图（MATERIALIZED VIEW）不是只读视图的升级版，它是快照，刷新需要额外权限，且数据非实时。如果你要的是“实时只读 API”，就别建它——那解决的是性能问题，不是权限问题。
