Composer全局配置文件必须用composer config --global --list确认路径后备份，因其位置受COMPOSER_HOME环境变量影响且新版只认config.json，默认不存在；硬编码路径易失败。
Composer 配置文件本身不包含项目逻辑，但一旦丢失或损坏，会影响全局行为（如镜像源、认证凭据、插件配置等），所以必须单独备份——它不能靠 composer.json 或 git 覆盖。
确认当前全局配置路径再备份
不同系统、不同安装方式下，Composer 全局配置位置不统一，直接硬编码路径容易失败：
-
composer config -g --list是唯一可靠方式，它会输出实际生效的配置文件路径（比如/home/user/.config/composer/config.json或/home/user/.composer/config.json） - 旧版 Composer（~/.composer/config.json，新版（≥2.0）默认迁移到
~/.config/composer/config.json - 若执行
composer config -g --list报错“Could not find config file”，说明尚未初始化全局配置，此时可跳过备份，或先运行composer config -g github-oauth.github.com "xxx"生成一个
备份时必须保留目录结构
Composer 的全局配置不只是 config.json 一个文件，还包括：
-
auth.json：存储私有仓库 token、OAuth 凭据，权限敏感，必须一起备份 -
keys/目录（如有）：存放 GPG 密钥，用于验证包签名 - 整个
.composer/或.config/composer/目录才是完整单元，只复制单个config.json会导致后续composer global install失败
推荐命令：cp -r ~/.config/composer ~/backup/composer-global-$(date +%Y%m%d)（Linux/macOS）；Windows 用户请用 robocopy 而非 copy，避免长路径和权限截断。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
避免覆盖已有备份的两个关键点
很多脚本用固定文件名（如 config.json.bak）覆盖旧备份，灾难发生时可能拿到的是上周的配置：
- 时间戳必须嵌入目录名，而不是文件名后缀——因为
auth.json和config.json需保持同级关系 - 不要用
$(date +%s)（秒级），CI 环境并发执行时可能冲突；改用$(date +%Y%m%d_%H%M%S)更安全 - 加一层存在性检查：
[ ! -d ~/backup/composer-global-$(date +%Y%m%d_%H%M%S) ] && cp -r ~/.config/composer ~/backup/composer-global-$(date +%Y%m%d_%H%M%S)
CI/CD 中备份容易被忽略的细节
在 GitHub Actions、GitLab CI 等环境里，~/.config/composer/ 默认不存在，也不会自动创建，所以：
- 不能假设
composer config -g总是成功，需前置判断：if [ -d "$HOME/.config/composer" ]; then cp -r "$HOME/.config/composer" "$BACKUP_DIR/"; fi - CI 中常用
COMPOSER_HOME环境变量重定向配置路径，备份前必须检查该变量是否设置，否则会漏掉真实位置 - 如果用了
composer self-update，记得也备份composer.phar本身——它的版本决定了config.json的解析规则，尤其跨大版本（1.x → 2.x）时
真正麻烦的不是备份动作本身，而是恢复时发现 auth.json 权限不对（必须 600）、keys/ 缺失导致 verify 失败，或者 COMPOSER_HOME 没还原导致新命令仍读旧位置——这些细节不写进备份脚本，就等于没备。
