SQL视图本身无法动态嵌入当前用户ID做行级过滤，因CURRENT_USER等函数在创建时求值；PostgreSQL应使用行级安全策略（RLS）并配合current_setting()，MySQL需应用层拼接SQL或字符串替换，SQL Server推荐用SESSION_CONTEXT()配合sp_set_session_context。
SQL视图里怎么嵌入当前用户ID做行级过滤？
纯视图本身不支持动态获取会话用户信息，直接在 CREATE VIEW 里写 WHERE user_id = CURRENT_USER 是无效的——多数数据库（如 PostgreSQL、MySQL）的视图定义是静态的，CURRENT_USER 在创建时求值，不是查询时。真正可行的方式是结合数据库的行级安全策略（RLS）或使用函数封装视图逻辑。
PostgreSQL 中用 RLS 实现用户数据隔离最稳妥
PostgreSQL 的行级安全（Row Level Security）是原生支持且生产就绪的方案，比手动拼视图可靠得多。它在表级别启用后，所有对该表的读写都会自动套上策略条件，无需改应用代码。
- 先给目标表启用 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';（注意：必须在事务或会话中显式设置） - 策略生效后，哪怕直接
SELECT * FROM orders;也只返回该用户的行
不用视图，但效果等价；而且避免了视图无法参数化的硬伤。
MySQL 8.0+ 怎么模拟行级过滤？只能靠 SQL 视图 + 应用层配合
MySQL 没有 RLS，也没有会话级变量参与视图定义的能力，所以必须由应用控制视图名称或拼接 SQL。常见做法是为每个用户建一个专属视图（不推荐），或用存储函数动态生成结果（有性能代价）。
- 最简方案：应用在查询前拼出带用户 ID 的 SQL，例如：
SELECT * FROM orders WHERE user_id = 123;—— 这比依赖视图更直接、更可控 - 若坚持用视图，可建一个“模板视图”：
CREATE VIEW user_orders AS SELECT * FROM orders WHERE user_id = -1;，然后让 ORM 或中间层把-1替换为真实 ID（本质是字符串替换，非数据库行为） - 不要用
USER()或CURRENT_USER()做过滤依据——它们返回的是数据库登录账户，不是业务用户 ID
SQL Server 视图加 SUSER_SNAME() 能用吗？小心权限和映射错位
SQL Server 允许在视图中用 SUSER_SNAME()，但前提是数据库用户与 Windows/SQL 登录名能一对一映射到业务用户，这在 Web 应用中几乎不可行——通常所有请求都走同一个连接池账号。
- 如果真用：
CREATE VIEW my_orders AS SELECT * FROM orders WHERE user_login = SUSER_SNAME(); - 但你得确保每条订单记录的
user_login字段存的是数据库登录名，而不是业务系统的user_id - 更现实的做法是：应用在执行查询前，用
EXEC sp_set_session_context @key=N'user_id', @value=123;设置上下文，视图里用CONVERT(INT, SESSION_CONTEXT(N'user_id'))过滤（SQL Server 2016+）
这个方案有效，但要求所有查询都走同一连接，并且应用必须记得每次设置上下文——漏一次就全量泄露。
真正的难点不在语法，而在于“谁来保证用户标识从登录态准确传到数据库会话”。视图只是容器，背后的身份链路断一环，过滤就形同虚设。
