导出用户信息前须确认后端是否支持全量拉取，分页接口无法获取全部用户；需检查专用导出接口、验证鉴权方式、确保响应头含charset=utf-8，并按新系统要求适配字段与密码策略。
导出用户信息前先确认后端接口是否支持全量拉取
很多权限系统（比如基于 spring security + rbac 的管理后台）的用户列表接口默认带分页，/api/users?page=1&size=20 这类请求根本拿不到“所有”用户——它只返回第一页。直接调前端“导出当前页”按钮，等于只备份了 20 个账户。
得先查清楚后端有没有提供无分页、带 export=true 或 all=true 参数的专用导出接口，比如：/api/users/export?format=csv。没有的话，前端强行拼接多页请求容易触发限流，或漏掉刚新增/删除的用户。
- 打开浏览器开发者工具 → Network 标签页 → 点击页面上的“导出”按钮 → 找到发起的请求，看 URL 和响应内容
- 如果响应里有
"total": 137但 body 只有 20 条，说明是分页接口，不能直接用 - 联系后端确认是否有
/api/users/all或支持?page=-1这类绕过分页的路径
用 curl 或 Postman 调用全量导出接口时注意鉴权方式
权限系统通常要求登录态才能访问用户数据，而浏览器里点导出能成功，是因为 Cookie 自动带上去了；curl 默认不带，会直接返回 401 Unauthorized 或跳转到登录页。
必须显式传入有效凭证，常见方式有三种，优先级从高到低：
- 用浏览器复制当前有效的
Authorization: Bearer <token>请求头，curl 加-H "Authorization: Bearer xxx" - 若用 Cookie 鉴权，从 Application → Cookies 里复制
JSESSIONID或token字段，curl 加-H "Cookie: JSESSIONID=abc123" - 不推荐：把账号密码写进 curl 用
-u user:pass，基本会被后端拦截（HTTP Basic 在现代权限系统中极少启用）
示例命令：curl -H "Authorization: Bearer eyJhbGciOi..." -o users.csv https://admin.example.com/api/users/export?format=csv
导出 CSV 文件后字段缺失或乱码的常见原因
拿到的 users.csv 打开可能缺列（比如没导出角色、部门字段），或者中文显示为方块、问号——这往往不是导出逻辑问题，而是接口返回时没设对 Content-Type 或编码。
- 检查响应头是否有
Content-Type: text/csv; charset=utf-8，缺charset=utf-8是 Excel 打开中文乱码的主因 - 如果后端返回的是
application/octet-stream，Excel 会按 ANSI 解码，此时用记事本另存为 UTF-8 编码再打开即可 - 字段缺失大概率是后端导出逻辑写了白名单，比如只允许导出
username,email,status，不包含created_time或自定义扩展字段，需改后端代码或配置
账户迁移时别直接导入原始 CSV 到新系统
备份出来的 CSV 是“快照”，但账户迁移不是文件搬运。新环境的密码加密方式（BCrypt vs MD5）、用户状态字段含义（enabled 是布尔值还是字符串 "1"/"0"）、必填字段校验规则（比如新系统强制要求手机号）都可能不兼容。
最稳妥的做法是走新系统的标准导入流程，而不是用数据库 INSERT 或后台脚本硬塞 CSV 数据：
- 先在新系统文档里找
user import template.xlsx，对照字段名和格式重排你的 CSV - 密码字段不要导出明文（正常系统也不会存明文），迁移时统一设初始密码，或让用户首次登录强制修改
- 如果新老系统用不同 ID 生成策略（比如 UUID vs 自增整数），别依赖原
id字段，用username或email作为关联键
跳过校验直接灌库，很可能导致部分账户导入失败却无报错，等真正登录才发现一堆“账号不存在”。
