Oracle是唯一在触发器中能直接获取客户端IP的主流数据库，必须用sys_context('USERENV','IP_ADDRESS')获取并显式赋值后比对，MySQL/PostgreSQL不支持；空值需判NULL，且真正有效的IP控制应在监听器或网络层实现。
BEFORE UPDATE 触发器必须结合 sys_context('userenv','ip_address') 判断
Oracle 是唯一在触发器中能直接获取客户端 IP 的主流数据库（MySQL/PostgreSQL 都不支持）。其他数据库无法在触发器里拿到真实连接 IP，硬加判断会失效。Oracle 中必须用 sys_context('userenv','ip_address') 获取当前会话来源 IP，再与白名单或黑名单比对。
常见错误是直接写 IF ip_address = '10.1.2.3' THEN ...——ip_address 不是变量，必须显式赋值：
DECLARE v_ip VARCHAR2(30) := sys_context('userenv','ip_address');- 再用
IF v_ip IN ('10.1.2.3', '192.168.5.10') THEN SIGNAL ...（注意 Oracle 用RAISE_APPLICATION_ERROR，不是SIGNAL） - 空字符串或未知 IP（如通过连接池、代理）时
sys_context可能返回 null，需加IS NULL判断，否则条件跳过
MySQL 和 PostgreSQL 不能靠触发器拦 IP，得换思路
MySQL 触发器里查不到客户端 IP；PostgreSQL 的 inet_client_addr() 只能在普通函数里用，触发器中不可调用（会报错 cannot be used in a trigger）。强行在触发器里读取网络信息，结果只有报错或静默跳过。
替代方案要分层落地：
- MySQL：改用
sql_mode+ 应用层标识 —— 要求所有合法更新 SQL 必须带注释/* app=finance-batch */，触发器用INFORMATION_SCHEMA.PROCESSLIST查当前会话的INFO字段（需PROCESS权限），匹配失败则SIGNAL - PostgreSQL：用
pg_stat_activity查application_name或client_hostname（后者依赖反向 DNS，不稳定），配合SECURITY DEFINER函数封装校验逻辑，撤掉直连UPDATE权限 - 通用兜底：数据库前加代理层（如 HAProxy、PgBouncer），在代理上做 IP 过滤，比 DB 层更早拦截
别忘了权限和部署闭环，否则触发器形同虚设
即使触发器逻辑完全正确，以下三点没做到，照样被绕过：
- Oracle 用户有
ADMINISTER DATABASE TRIGGER权限（比如DBA角色）时，触发器仍会执行但无法阻止登录或修改 ——RAISE_APPLICATION_ERROR报错后，该用户依然能继续操作 - MySQL 应用账号若被授予了
TRIGGER权限，就可能自己删掉防护触发器；生产环境应只给EXECUTE权限，且触发器由 DBA 统一维护 - PostgreSQL 中，如果应用连接串用了
options=-c%20session_preload_libraries=...加载恶意库，或 DBA 启用了track_activities = off，pg_stat_activity就查不到真实客户端信息
真正起效的 IP 控制，90% 发生在数据库之外
触发器只是最后一道防线，不是第一道。IP 级控制最有效的位置永远是监听器或网络层：
- Oracle：改
$ORACLE_HOME/network/admin/sqlnet.ora，加TCP.VALIDNODE_CHECKING = YES和TCP.INVITED_NODES = (10.1.2.0/24,172.16.0.5)，重启监听器即生效 - MySQL：用系统防火墙（
iptables或ufw）限制3306端口只允许指定网段访问，比任何 DB 内逻辑都快、都稳 - PostgreSQL：在
pg_hba.conf里写明hostssl all all 10.1.2.0/24 md5，拒绝其他 CIDR 段，reload 配置即可
触发器查 IP 的动作本身就有性能开销，且依赖会话上下文完整。一旦连接经过 NAT、负载均衡或连接池，拿到的 IP 往往是中间节点地址，不是真实来源 —— 这种情况下，还执着于在触发器里做 IP 判断，不如先确认链路是否透明。
