SQL注入防护需结合参数化查询与服务端敏感字段掩码，应用层应在ResultSet取值后立即脱敏并避免重复处理，数据库视图层掩码更彻底但需注意性能；掩码策略应配置化、分环境管控，并覆盖日志、缓存等所有数据出口。
SQL注入防护不能只靠参数化，敏感字段必须服务端掩码
参数化查询能防注入，但拦不住已登录用户的恶意查询。只要数据库权限没做列级隔离，攻击者用合法账号查出明文手机号、身份证号，掩码这事就绕不开——得在应用层或数据库视图层主动脱敏。
应用层掩码：Java里用MaskUtils处理ResultSet结果集
别在前端拼接掩码逻辑，后端取到数据后立刻处理。常见错误是只对返回JSON做正则替换，漏掉日志打印、缓存写入等环节的明文残留。
- 从
ResultSet取值后，立即调用掩码工具：比如MaskUtils.maskIdCard(rs.getString("id_card"))，而不是等到组装DTO时才处理 - 避免对同一字段反复掩码：先判断是否已脱敏（比如字段值含
"***"或符合掩码格式），否则可能把"110***1234"再变成"110******4" - 注意时区和字符集影响：
substring()在MySQL utf8mb4下对emoji可能截断乱码，优先用StringUtils.substring()这类安全切片工具
数据库视图层掩码：PostgreSQL用overlay()和left()/right()函数
适合读多写少、且DBA可控的场景。比应用层更彻底，连ORM生成的原始SQL都拿不到明文。但要注意函数开销和索引失效问题。
- 身份证掩码示例：
overlay(id_card placing '****' from 9 for 4)，比concat(left(id_card,8), '****', right(id_card,4))更高效 - 手机号统一掩码为
concat(left(mobile,3), '****', right(mobile,4))，别用replace(mobile, substring(mobile,4,7), '****')——后者在部分版本会报错 - 视图中禁止使用
SELECT *，必须显式列出字段，否则新增敏感列不会自动被掩码
掩码规则不是越严越好，得看业务上下文和合规要求
银行系统要求身份证前6位+后4位可见，而内部工单系统可能只需隐藏全部号码。硬编码掩码逻辑会导致审计不通过，也增加灰度发布风险。
- 把掩码策略抽成配置项，比如
mask.rule.id_card=front(6)+back(4)，运行时加载，避免改代码发版 - 区分环境：测试库可关掩码方便排查，但
application-prod.yml里必须强制开启，且配置项名带prod前缀防止误配 - 日志中所有敏感字段必须走统一脱敏入口，哪怕只是
log.info("user: {}", user)——重写toString()或用Lombok的@ToString.Exclude都不够，得拦截序列化过程
最常被忽略的是缓存穿透场景：Redis里存了明文用户信息，接口加了掩码，但下游服务直连缓存读出原始数据。掩码不是加一道filter就完事，得盯住数据流每个出口。
