最稳妥的做法是备份过程中就排除或替换敏感字段，而非事后脱敏；需在导出环节用条件过滤或SQL表达式当场替换，注意字符集、字段名精确匹配、正则边界、脱敏后业务逻辑校验及索引唯一性。
备份时直接过滤敏感表或字段比事后脱敏更可靠
开发测试环境用生产数据备份，但不能带真实手机号、身份证、银行卡——最稳妥的做法不是“备份完再脱敏”，而是备份过程中就排除或替换。MySQL 的 mysqldump 不支持字段级正则替换，PostgreSQL 的 pg_dump 也不行，所以得在导出环节加一层处理逻辑。
- 优先用
SELECT ... INTO OUTFILE或COPY配合条件过滤（比如WHERE status != 'deleted'），避开全量 dump 后再清洗的冗余步骤 - 对必须保留的敏感字段（如用户昵称需保留格式但隐藏真实值），用 SQL 表达式当场替换：
CONCAT('user_', id)或MD5(email)，避免后续脚本多轮读写 - 注意字符集：如果数据库用
utf8mb4，但导出脚本默认用latin1，中文会变乱码，导致脱敏后字段长度异常或校验失败
Python 脚本做字段级替换要绕开 ORM 和 JSON 解析陷阱
很多团队用 Python 写脱敏脚本，但一加载成 dict 再改再序列化，容易踩坑：时间字段变成字符串、小数精度丢失、嵌套结构漏替换、NULL 值被转成 "null" 字符串。
- 别用
json.loads(json.dumps(...))过一遍，直接用csv.DictReader或pandas.read_csv处理导出的 CSV，按列操作更稳 - 敏感字段名要精确匹配：
'phone'和'mobile_phone'是两个字段，别靠模糊关键词（如包含'phone'）批量替换，否则把'phone_ext'也误杀了 - 正则替换留白格：手机号常用
r'1[3-9]\d{9}'，但得加\b边界符，否则会把'138123456789'（12位）中间截出一个虚假号码
脱敏后校验不是“有没有改”，而是“改得像不像”
脚本跑完输出“Success”不等于数据可用。测试环境连不上支付网关，可能只是因为脱敏后的银行卡号仍通过了 Luhn 校验（比如用固定前缀+随机数生成），结果被下游系统当成真卡拦截。
- 校验重点不在是否含原始值，而在业务逻辑是否通：邮箱域名是否统一改成
@example.com，而不是只换本地部分；日期字段是否保持合法范围（别把'2025-02-30'这种错值塞进去） - 用
SELECT COUNT(*)对比源库和脱敏库的行数可以发现漏表，但更要查COUNT(DISTINCT user_id)—— 如果脱敏脚本把所有user_id替换成同一值，数量就崩了 - 别跳过索引字段：如果
email是唯一索引，脱敏后重复值会导致导入失败，得提前加哈希或加序号后缀
Docker 环境下挂载脚本和配置要确认路径权限与编码
把脱敏脚本打包进 Docker 镜像或挂载到容器里执行，常见问题是脚本读不到 SQL 文件，或者读到了但中文注释乱码，最终字段名匹配失败。
- 挂载路径用绝对路径：
-v /host/dump:/container/dump:ro，别用相对路径，容器内当前目录不可控 - Python 脚本文件本身用
UTF-8 without BOM编码，Windows 下编辑容易带 BOM，导致#!/usr/bin/env python3第一行报错 - 容器内时区和宿主机不一致时，
datetime.now()生成的脱敏标记时间可能跨天，影响日志排查——显式传tzinfo=timezone.utc
/scripts/conf/dev-sanitize.yaml 里的正则表达式。 
