姓名脱敏不能只用substring，因无法识别复姓导致错误截断；需结合left、rpad及长度判断分情况处理，并优先采用数据库列级脱敏策略保障安全。
姓名脱敏显示为什么不能只用 SUBSTRING？
直接截取前1位再硬加**看似简单，但遇到「欧阳修」「司马相如」这类复姓就会漏掉第二个字，变成「欧**」而不是「欧阳**」。SQL 没有内置中文姓名结构识别能力，得靠长度规律+函数组合来逼近真实脱敏逻辑。
更关键的是，不同系统对「脱敏程度」要求不一：有的只要隐藏后两位，有的要求保留姓氏全称+名只显首字+其余打星。这时候LEFT()和RPAD()的组合比纯SUBSTRING()更可控。
LEFT + RPAD 拼接脱敏的通用写法
核心思路是：先用LEFT(name, 1)取姓氏首字（覆盖单姓），再用RPAD('', LENGTH(name) - 1, '*')补足剩余长度的星号。但这样会把复姓也砍成单字——所以实际要分情况处理：
- 若业务允许「统一显示为「张*」、「欧阳*」」，可用：
CONCAT(LEFT(name, LENGTH(name) - 1), '*')
（保留除末尾外所有字，末尾变星） - 若需「单姓留1字、复姓留2字、后面全星」，得配合字符长度判断：
CASE WHEN LENGTH(name) = 2 THEN CONCAT(LEFT(name, 2), '**')<br> WHEN LENGTH(name) = 3 THEN CONCAT(LEFT(name, 1), '**')<br> ELSE CONCAT(LEFT(name, 1), RPAD('', LENGTH(name) - 1, '*'))<br>END - MySQL 8.0+ 可用正则预判复姓（需维护常见复姓列表），但性能较差，线上慎用
RPAD 的长度陷阱：中文字符计数是否准确？
RPAD(str, len, pad) 的 len 参数是按「字符数」算，不是字节数——这点在 utf8mb4 编码下很关键。如果字段定义是 VARCHAR(10) 且存了 5 个汉字，LENGTH(name) 返回 5（不是 15），RPAD('', 4, '*') 就真补 4 个星号，不会多也不会少。
但容易踩坑的是：CHAR_LENGTH() 和 LENGTH() 在 MySQL 中对中文表现一致（都返回字符数），而某些旧版本或 SQL Server 里LEN()可能受排序规则影响。务必在目标数据库里先跑SELECT LENGTH('欧阳'), CHAR_LENGTH('欧阳');确认返回值都是 2。
- PostgreSQL 必须用
LENGTH()，CHAR_LENGTH()是别名，行为一致 - SQL Server 要用
LEN()，且它自动忽略末尾空格，但对中文无影响 - Oracle 用
LENGTH()，注意 NLS_LENGTH_SEMANTICS 设置（默认 CHAR）
生产环境必须加的防护层
脱敏不是前端或应用层的事，SQL 层做脱敏只是第一道防线。直接在查询里写RPAD暴露原始姓名字段，等于把风险交给了下游权限控制——万一视图被误授、日志没过滤、调试时打印了完整结果，就全漏了。
- 敏感字段一律走数据库列级脱敏策略（如 MySQL 8.0+ 的
DATA_MASKING插件，或 Oracle 的DBMS_REDACT） - 如果只能用 SQL 函数拼接，确保该查询只用于特定报表角色，且该角色无法查原始表
- 永远检查执行计划：含
RPAD和LENGTH的表达式无法走索引，大表分页查脱敏名时会慢，应避免在 WHERE 条件里用这些函数处理字段
真正难的从来不是怎么写出「张***」，而是确认「谁能看到张三，谁只能看到张**」——函数只是工具，权限链和数据流向才是脱敏落地的命门。
