最安全的敏感字段脱敏是在导出前用str_replace或preg_replace等函数对手机号、身份证、邮箱等字段值进行掩码处理，确保写入Excel或CSV的数据本身就是脱敏后的结果，而非依赖样式隐藏；需注意UTF-8 BOM输出、编码统一及避免日志泄露原始值。
导出前用 str_replace 或 preg_replace 替换敏感字段值
直接在生成 Excel 数据前，把手机号、身份证、邮箱等字段的原始值做掩码处理，是最轻量、最可控的方式。不是“导出后再隐藏”，而是“导出什么就显示什么”。
常见错误是试图在 Excel 文件里用样式“隐藏”内容——Excel 本身不支持真正意义上的字段级脱敏，用户复制粘贴或打开 XML 结构就能看到原文。
- 手机号脱敏：用
preg_replace('/^(\d{3})\d{4}(\d{4})$/', '$1****$2', $phone) - 身份证脱敏：用
substr_replace($id, '****', 6, 8)（保留前6位+后4位） - 邮箱脱敏：用
preg_replace('/^(.{1}).*?@(.*)$/', '$1***@$2', $email) - 注意：脱敏逻辑必须在
fputcsv、PhpSpreadsheet的setCellValue或导出 JSON 前执行，不能依赖前端或 Excel 软件功能
用 PhpSpreadsheet 时别直接写入原始数据到 setCellValue
很多人用 PhpSpreadsheet 导出时，习惯先组装好完整数组再循环写入，结果敏感字段没处理就进了单元格。这时候哪怕加了 setStyle 也毫无意义——样式只影响显示，不影响单元格实际值。
正确做法是在调用 setCellValue 前，对每个待写入的值单独判断并脱敏。
立即学习“PHP免费学习笔记（深入）”；
- 检查字段名是否在脱敏白名单中，例如：
in_array($key, ['phone', 'id_card', 'email']) - 对匹配字段调用对应脱敏函数，再传给
$sheet->setCellValue($cell, $masked_value) - 避免用
fromArray()一次性写入整个二维数组，除非你已提前处理完所有敏感值 - 如果用了模板 Excel，也要确认模板中没有预设公式或链接可能反向还原原始数据
导出 CSV 时别忽略 BOM 和编码导致中文脱敏乱码
用 fputcsv 导出含中文的脱敏内容（比如“张*”“李**”），若没加 UTF-8 BOM，Excel 默认用 GBK 打开，星号会变成乱码，反而暴露原始字节数——等于脱敏失败。
- 导出前输出 BOM：
echo "\xEF\xBB\xBF"; - 确保所有字符串已是 UTF-8 编码，脱敏函数不要混用
mb_substr和substr（后者按字节截取，中文下会切坏） - 避免在脱敏后用
iconv('UTF-8', 'GBK', $masked)转码——这会让星号错位，且无法保证兼容性 - 测试时务必用 Excel 双击打开，而不是用记事本或 VS Code 查看，否则看不出真实表现
不要依赖 Excel 的“单元格格式”或“条件格式”实现脱敏
有人尝试用自定义数字格式如 ;;; 隐藏内容，或用白色字体盖住文字——这些在 Excel 里确实“看不见”，但只要选中单元格，编辑栏里全暴露；导出为 CSV、PDF 或另存为 XLSX 后再打开，也会立刻还原。
-
;;;格式只影响显示，getCellValue()仍返回原文 - 设置字体颜色为白色 + 背景同色，属于障眼法，截图、打印、复制都会失效
- 条件格式无法对单个字符做掩码（比如只隐藏中间4位），只能整单元格控制显隐
- 真正安全的脱敏，只发生在数据写入前；任何“写进去再藏起来”的思路，在导出场景下都不可靠
脱敏不是视觉问题，是数据出口控制问题。最容易被忽略的是：日志、调试输出、临时数组缓存里还留着原始值，一不小心就随异常堆栈打出来。导出逻辑越简单，越要盯紧那几行赋值语句。
