触发器不能自动同步权限列表，尤其禁止执行GRANT/REVOKE；组织架构变更仅可触发日志或状态标记，权限分配必须由应用层、中间服务或异步任务完成。
直接说结论：触发器不能自动同步权限列表，尤其不能执行 GRANT 或 REVOKE；组织架构变更（如部门调整、汇报关系更新）可以触发日志或状态标记，但权限分配必须交由应用层、中间服务或异步任务完成。
MySQL 触发器里调 GRANT 会报错，不是写法问题，是引擎禁止
哪怕你用 CURRENT_USER() 拿到用户名、拼出 GRANT SELECT ON orders TO 'alice'@'%'，执行时也会立刻失败，报 ERROR 1357 (HY000): Cannot use GRANT in stored function or trigger。这不是权限不足，是 MySQL 在语法层硬性拦截所有 DDL 语句——包括授权类操作。
- 别试存储过程包装再调用，同样被拦
-
INSERT INTO user_perms_log这种写日志行为是安全的，可用 - 若真要数据库内闭环，只能建视图（如
emp_scopes_v），用WHERE dept_id = @current_dept_id做行级过滤，而非改用户权限
PostgreSQL 可间接授权，但必须绕过触发器直连权限上下文
PostgreSQL 允许触发器调用函数，而函数可声明 SECURITY DEFINER，从而以函数所有者身份执行 GRANT。但这要求两点：函数所有者本身具备目标权限，且用户名等输入必须经 %I 安全转义。
- 错误写法：
EXECUTE 'GRANT SELECT ON orders TO ' || NEW.username—— SQL 注入高危 - 正确写法：
EXECUTE format('GRANT SELECT ON TABLE orders TO %I', NEW.username) - 函数创建必须由超级用户执行，且不能在事务块中建
EVENT TRIGGER - 仍需注意：
NEW.username来源是否可信？建议从应用层通过SET LOCAL app.emp_id = 'e1001'注入，而非依赖USER()
SQL Server 的 xp_cmdshell 方案已被证实不可靠
有人试图让 DML 触发器调用 xp_cmdshell 去跑 sqlcmd -Q "GRANT ..."，这条路在 2026 年已明确失效：一是 xp_cmdshell 默认禁用且需高权限开启，二是 Windows 安全策略普遍拦截子进程启动，三是无法可靠捕获执行结果，失败即静默丢弃。
- 替代方案只有两个：用
SQL Server Agent Job轮询emp_changes_log表，或发NOTIFY到监听服务（需自建 .NET/Python 后台） - DDL 触发器（
ON DATABASE FOR CREATE_TABLE等）可用于捕获组织表结构变更，但不适用于数据行变动 - 组织架构同步的关键字段（如
manager_id、dept_path）变更后，触发器只应更新sync_status = 'pending'或插入队列表，绝不应阻塞主事务
真正能落地的“自动同步”其实是轻量级状态驱动
所谓“自动”，是指组织表（如 employees）变更后，系统无需人工干预即可最终达成权限一致。这靠的是解耦：触发器只做最轻的事——记一笔、标一个状态、发一个通知。
- 推荐模式：触发器向
perm_sync_queue插入一行（含emp_id、event_type、updated_at），由外部消费者（如 Celery 任务或 Kafka 消费者）拉取并调用权限中心 API - 避免在触发器里查
roles表或联表判断“该给什么权限”——锁表风险高，且权限逻辑常随业务迭代，硬编码进 DB 很难维护 - 如果必须 DB 内闭环，用物化视图或递归 CTE 预计算
emp_dept_tree，再让应用查询该视图决定可见范围，比实时授予权限更稳定
最常被忽略的一点：组织架构变更往往跨多行（比如批量调岗），而 FOR EACH ROW 触发器会为每一行单独触发——若没加去重或批处理机制，可能引发上百次重复同步请求。
