sql server中应使用session_context而非user_name()实现视图级动态行过滤，因其支持应用层设置业务上下文（如tenant_id），且需配合isnull(cast())处理未设值情况，并在连接复用时严格重置以避免上下文残留。
SQL Server 中用 SESSION_CONTEXT 实现视图级动态行过滤
SQL Server 本身不支持 Oracle 那样的 Virtual Private Database（VPD），但可以通过 SESSION_CONTEXT + 视图 + CONTEXT_INFO（旧方式）或更推荐的 SESSION_CONTEXT（SQL Server 2016+）实现轻量级动态权限过滤。核心是：视图定义里嵌入对当前会话上下文的判断，让同一张视图对不同用户返回不同行。
为什么必须用 SESSION_CONTEXT 而不是 USER_NAME() 或 SUSER_SNAME()
单纯靠 USER_NAME() 或 SUSER_SNAME() 只能区分登录主体，无法表达「当前操作代表哪个业务租户/部门/角色」——比如一个 DBA 账号可能要临时切换为「财务部」身份查数据。而 SESSION_CONTEXT 是可由应用层主动设置的键值对，生命周期绑定会话，且支持任意字符串键名（如 'tenant_id'、'dept_code'），这才是动态过滤的关键载体。
-
SESSION_CONTEXT必须在会话中显式设置，未设置时SESSION_CONTEXT(N'tenant_id')返回NULL，视图 WHERE 条件需处理该情况（否则可能漏数据或全拒） - 不能用
APP_NAME()或HOST_NAME()替代：它们不可控、易伪造、无业务语义 - 设置后仅对当前连接有效，断开即丢失，安全性依赖应用层每次连接后正确初始化
视图中怎么安全引用 SESSION_CONTEXT 做过滤
直接在视图定义里写 WHERE tenant_id = CAST(SESSION_CONTEXT(N'tenant_id') AS INT) 很危险：一旦 SESSION_CONTEXT 未设或类型不匹配，整个查询会报错或返回空。正确做法是显式判空 + 类型兼容 + 默认兜底逻辑。
- 用
ISNULL(CAST(SESSION_CONTEXT(N'tenant_id') AS INT), -1)避免转换失败；若业务上tenant_id不可能为负数，-1 可作为“未授权”标识 - WHERE 条件建议写成：
tenant_id = ISNULL(CAST(SESSION_CONTEXT(N'tenant_id') AS INT), -1) OR ISNULL(CAST(SESSION_CONTEXT(N'tenant_id') AS INT), -1) = -1—— 这样未设上下文时仍可查全部（或按需改为= -1 AND 1=0强制无结果） - 避免在视图里用
TRY_CAST：SQL Server 视图定义不支持TRY_CAST（2022 才部分支持），老版本务必用CAST+ISNULL组合 - 示例视图片段：
CREATE VIEW dbo.vw_orders AS SELECT order_id, customer_name, amount, tenant_id FROM dbo.orders WHERE tenant_id = ISNULL(CAST(SESSION_CONTEXT(N'tenant_id') AS INT), tenant_id);
（最后这个tenant_id = tenant_id是让未设上下文时退化为无过滤）
应用端怎么可靠设置 SESSION_CONTEXT 并防止覆盖
设置必须在每次获取连接后、执行业务 SQL 前完成，且不能被后续代码无意覆盖。常见错误是多个模块重复调用 sp_set_session_context 导致键值被冲掉。
- 用
sp_set_session_context @key=N'tenant_id', @value=123, @read_only=1设置只读模式，防止中间件或存储过程意外修改 - 设置前先检查是否已存在：
IF SESSION_CONTEXT(N'tenant_id') IS NULL EXEC sp_set_session_context ...，避免重复设置开销 - .NET 中推荐在
SqlConnection.Open()后立即执行设置语句，而不是放在 Repository 层每次查询前——连接池复用下，会话上下文不会自动清空 - 注意：
SESSION_CONTEXT在连接归还到池后仍保留，所以必须确保每次从池取连接后都重置（或至少校验），否则可能残留上一个用户的上下文
最易被忽略的是连接池场景下的上下文残留问题：一个连接被 A 用户使用并设置了 tenant_id=100，归还池后被 B 用户复用，若 B 没重新设置，就会误查 A 的数据。这点没有银弹，只能靠应用层严格管控连接初始化逻辑。
