必须由应用层显式传入业务用户标识，因CURRENT_USER和SUSER_SNAME()返回的是数据库主体而非业务ID；触发器需用CONTEXT_INFO()获取并校验owner_id，且须每次DML前重置。
不能靠 CURRENT_USER 或 SUSER_SNAME() 直接校验行归属，必须由应用层显式传入业务用户标识，再在触发器中做等值比对。
为什么触发器里拿不到真正的业务用户ID
SQL Server 触发器执行时，CURRENT_USER 返回的是数据库用户（如 app_user），SUSER_SNAME() 返回的是登录名（如 DOMAIN\jane），但业务系统通常用的是自定义用户ID（如 u789）——它和数据库主体完全无关。直接在校验逻辑里写 WHERE owner_id = SUSER_SNAME() 会导致所有操作被放行或全部拦截，根本不可控。
常见错误现象：INSERT 触发器里查 SUSER_SNAME() 得到 app_pool，结果所有插入都通过，实际应只允许员工本人插入自己的订单。
- 应用层必须在事务开始后、DML 前显式设置上下文变量：用
SET CONTEXT_INFO 0x75373839（ASCIIu789的十六进制） - 触发器中读取时需转换：
CONVERT(VARCHAR(128), CONTEXT_INFO())，注意返回值可能带尾部空格，建议加RTRIM() - 避免用
SESSION_CONTEXT()（SQL Server 2016+），因为 Navicat 等工具默认不支持，且跨连接不传递
AFTER INSERT/UPDATE/DELETE 中如何校验行级归属
核心不是“查权限”，而是“锁归属”：每条记录的 owner_id 字段必须与当前业务用户ID严格匹配，否则中断操作。
-
INSERT：只检查NEW.owner_id = 获取到的业务用户ID；若业务强制归属，禁止客户端传入该字段，改由触发器自动赋值 -
UPDATE：必须同时检查两项——OLD.owner_id = 当前用户ID（保证原属自己），且NEW.owner_id未被修改（除非业务允许转交，此时需额外白名单逻辑） -
DELETE：只检查OLD.owner_id = 当前用户ID；不要在DELETE触发器里尝试查inserted，它为空 - 所有判断必须用集合操作（
NOT EXISTS/EXISTS），禁用SELECT @uid = owner_id FROM inserted——多行操作会报错
为什么不能在触发器里查权限配置表
看似灵活的动态权限校验（比如查 user_dept_mapping 表判断“部门主管能否看本部门所有订单”），在触发器中实际极危险。
- 高并发下易引发锁争用：每次
INSERT都要 SELECT 权限表，可能阻塞全库写入 - 无法利用索引优化：权限规则越复杂，JOIN 越多，执行计划越难稳定
- 所有权链断裂风险高：权限表若不在同一 schema 或 owner 下，触发器会因权限检查失败而中断
- 真正可控的方案是把权限逻辑前置——应用层根据角色预计算出可操作的
owner_id列表，用IN条件下发，触发器只做简单等值校验
Navicat 编辑数据时触发器不生效的三个硬坑
不是触发器写错了，而是 Navicat 绕过了它。
- 确认
Use server-side cursors已关闭（路径：工具 → 选项 → 数据库 → 执行命令），否则它用UPDATE ... WHERE CURRENT OF游标方式更新，跳过所有 DML 触发器 - 检查触发器是否被禁用：
SELECT is_disabled FROM sys.triggers WHERE name = 'tr_check_order_owner' - 排查是否存在同名
INSTEAD OF触发器——它会完全拦截并替代AFTER触发器，导致你的校验逻辑根本不执行 - 报错必须用
THROW 50001, '无权操作他人订单', 1；用RAISERROR且严重级别 ≤10 时，Navicat 会静默吞掉错误，界面无提示也不回滚
最易被忽略的一点：CONTEXT_INFO 是连接级变量，不是事务级。如果应用用了连接池，必须确保每次执行 DML 前都重置它——上一个请求留下的旧值会导致权限误判。别指望它能自动清理。
