行级安全需将权限判断下沉至最外层WHERE并确保索引，用SECURITY DEFINER函数封装用户ID；WITH RECURSIVE须加路径去重防环；视图不可参数化，应改用函数；JOIN字段空值与重复值易致数据泄露，须严格校验。
WHERE里过滤用户ID比JOIN后过滤更安全
直接在最终 WHERE 子句中写 user_id = current_user_id()，比先 JOIN users u ON u.id = orders.user_id 再加 WHERE u.id = ? 更可靠——这不是“习惯问题”，而是防止数据库优化器提前展开JOIN，把本不该看到的订单数据拉进中间结果集。
- 常见错误现象：视图定义里写了完整JOIN，应用层再传入当前用户ID过滤，执行计划里却扫了全量订单表
- 正确做法：权限判断必须下沉到最外层
WHERE，且确保orders.user_id有索引 - PostgreSQL 推荐用
SECURITY DEFINER函数封装current_user_id()，避免应用伪造ID；MySQL 8.0+ 可用会话变量，但注意SQL SECURITY DEFINER下变量不可见，得改用函数
用WITH RECURSIVE做角色继承时必须防循环
当RBAC模型支持角色嵌套（比如A属于B、B属于C、C又属于A），WITH RECURSIVE 默认不会报错，而是无限递归直到超时或栈溢出——这会导致查询卡死、连接堆积，甚至拖垮整个数据库。
- 必须在递归CTE里加路径记录字段，如
ARRAY[role_id]，并在WHERE中检查NOT r.id = ANY(path) - SQL Server 的
MAXRECURSION 100只能防崩，不能防逻辑错误；真正要的是路径去重逻辑 - 测试时可故意构造环状配置，看是否返回错误或超时，而不是只查“看起来正常”的树形结构
视图不能带参数，但函数可以
CREATE VIEW user_orders AS SELECT * FROM orders WHERE user_id = ? 会直接报错：ERROR: syntax error at or near "?"。标准SQL视图不接受参数，硬塞只会失败。
- 替代方案：用
SECURITY DEFINER函数包装，例如CREATE FUNCTION my_orders() RETURNS TABLE(...)，内部调用current_user_id() - 函数调用时写
SELECT * FROM my_orders()，既安全又可复用 - 别在函数里拼接字符串或执行动态SQL——那会绕过权限封装，重开SQL注入口
JOIN字段重复或NULL多，容易隐式泄露数据
如果 orders.user_id 有大量重复值或NULL，而你又用 LEFT JOIN users u ON u.id = o.user_id，那么一个用户没关联上，就可能让其他用户的订单被错误地“挂”过去——尤其当后续还加了 WHERE u.status = 'active' 这类条件时，实际效果等价于INNER JOIN，但语义完全失真。
- 排查方法：对JOIN字段分别跑
SELECT COUNT(*), COUNT(DISTINCT user_id) FROM orders，若差距大，说明存在脏数据 - 临时验证：把
LEFT JOIN改成FULL OUTER JOIN（PostgreSQL/SQL Server支持），一眼看出哪边有孤立记录 - 空值处理：用
COALESCE(o.user_id, -1)填充前，先确认业务是否允许把NULL强行映射到某个伪ID——否则就是制造新泄露点
行级安全不是靠“加个WHERE”就完事的，真正难的，是让权限逻辑和JOIN行为在执行计划里始终对齐——而这点，往往只有看 EXPLAIN (ANALYZE) 才能确认。
