导出前必须禁用预览和自动格式化，避免哈希被截断或转义：取消勾选“启用预览”，选SQL或CSV格式，用自定义SQL绕过敏感字段识别，导出后立即校验哈希完整性并安全传输。
导出前必须禁用自动格式化和预览
phpMyAdmin 默认会对 TEXT 或 VARCHAR 字段内容做 HTML 转义和截断预览，尤其对长哈希值（如 $2y$10$...）会显示为省略号或乱码，导致导出文件实际缺失完整哈希。这不是数据丢失，而是界面层遮蔽——但用户常误以为“导出了”，结果备份无效。
操作时务必在表页面右上角点击「导出」→ 展开「格式特定选项」→ 取消勾选 显示所有列的内容（不截断） 旁边的「启用预览」（如果存在），并确保 格式 选为 SQL 或 CSV，不要选 JSON（它默认转义双引号和反斜杠，破坏哈希结构）。
- 若用
SQL格式：勾选导出表结构和导出数据，取消使用十六进制表示二进制字段（除非哈希真存为BINARY类型） - 若用
CSV格式：设置字段分隔符为,，字段包围符为"，转义字符设为空（避免把\插入哈希中） - 导出前先执行
SELECT COUNT(*) FROM users WHERE password LIKE '$2y$%'确认哈希字段有值，再查一条完整记录验证显示是否被截断
避免 phpMyAdmin 自动解密或混淆哈希字段
某些 phpMyAdmin 版本（尤其是带「密码字段识别」插件的定制版）会将列名含 password、hash 的字段自动标记为敏感字段，在导出时替换为 *** 或尝试 Base64 解码——这完全不可逆，且无提示。
最稳妥方式是绕过列名判断：不直接导出整张表，改用自定义 SQL 导出：
立即学习“PHP免费学习笔记（深入）”；
SELECT id, username, CONCAT('HASH:', password) AS safe_password, email FROM users;这样既保留原始哈希字节流，又通过前缀明确标识字段用途，还能规避自动处理逻辑。
- 执行该 SQL 后点击结果页的「导出」按钮，此时导出的是查询结果而非表结构，phpMyAdmin 几乎不会干预内容
- 如果必须导出原字段名，可临时重命名为
pwd_raw（用AS pwd_raw），避开关键词匹配 - 检查导出文件头部是否有
-- Warning: Password field auto-obscured类注释（极少数版本会加），如有则说明已被篡改
导出后立即校验哈希完整性
导出不是终点，哈希一旦被截断、转义或编码就无法用于验证登录——而这种损坏往往只有上线恢复时才暴露。
校验方法很简单：取导出文件中第一行非注释的哈希值（比如 CSV 第二行第三列，或 SQL 中 INSERT 语句里的字符串），用命令行快速比对：
mysql -Nse "SELECT password FROM users WHERE id = 1" your_db
和导出文件里对应位置的值逐字符对比（注意空格、换行、引号）。重点看开头是否为 $2y$、$2a$、$argon2id$ 等标准标识，长度是否符合（bcrypt 固定 60 字符，Argon2 至少 30+）。
- 别依赖 phpMyAdmin 的「复制到剪贴板」功能校验——剪贴板可能被浏览器插件二次处理
- 如果导出的是 SQL 文件，用
grep -o '\$2y\$[^\']*' export.sql | head -1提取原始哈希片段，避免被 SQL 引号包裹干扰 - 导出后立刻用
sha256sum记录文件指纹，防止后续传输中损坏
权限与传输环节比导出格式更关键
即使导出完全正确，如果文件保存在 Web 可访问目录（如 /var/www/html/backup/）、用 HTTP 明文下载、或上传到公共云盘，哈希等于直接公开。phpMyAdmin 本身不提供加密导出选项，所以安全链最弱一环永远在外部。
- 导出时选择
保存到服务器上的文件并指定绝对路径（如/tmp/users_export_2024.sql），然后用scp或sftp拉取，禁止勾选保存到客户端后浏览器直下 - 导出完成后立刻执行
rm /tmp/users_export_2024.sql（确认已离线保存），phpMyAdmin 不会自动清理服务器端临时文件 - 如果必须邮件发送，请先用
gpg --encrypt加密，密钥不发邮件，走其他通道告知
哈希字段本身不需要额外加密处理，但它的载体（文件）必须受控——导出动作只是复制字节，真正的风险藏在你把它放在哪、怎么搬走、谁能看到。
