Composer没有export命令，“导出设置”实为误读；真正需导出的仅有composer.json和composer.lock两个文件，它们是依赖状态的权威声明，必须纳入版本控制并跨环境同步。
Composer 本身没有 export 命令，所谓“导出设置”实际是误读或混淆了配置持久化、镜像切换、锁文件生成等操作。真正需要导出的只有 composer.json 和 composer.lock，其他所谓“导出全局配置”“导出镜像源”都是徒劳——因为 Composer 配置不支持一键导出为可重播脚本。
为什么 composer config --list 不等于可导出配置
运行 composer config --list 看到的只是当前生效的配置快照，它混合了全局（-g）、项目级、环境变量、甚至 COMPOSER_HOME 下隐藏文件的叠加结果。这些值无法直接复制粘贴复用，原因包括：
-
auth.json中的 token 或密码字段默认被composer config屏蔽（显示为[hidden]），导出后缺失认证信息会导致私有包拉取失败 - 某些配置如
process-timeout或use-include-path是运行时行为开关，没有对应命令行参数，导出后也无法还原 - 镜像源地址若含变量（如
https://$USER:$TOKEN@my-private-repo.com），config --list显示的是展开后的值，但变量本身未导出
composer dump-autoload 不是导出，而是重建自动加载映射
新手常把 dump-autoload 当作“导出类加载规则”，其实它只是根据当前 composer.json 的 autoload 段重新生成 vendor/autoload.php 和相关映射文件。关键点：
- 它不输出任何新文件到磁盘外，也不生成可移植配置
- 若项目用了
psr-4但命名空间与目录结构不匹配，dump-autoload -o（优化模式）会静默跳过错误路径，导致后续class not found报错更难定位 - CI/CD 中应避免在部署阶段执行
dump-autoload：生产环境应使用composer install --no-dev --classmap-authoritative，它已内置高效映射，无需额外 dump
真正该“导出”的只有两个文件：composer.json 和 composer.lock
这两个文件才是项目依赖状态的权威声明，也是唯一需要纳入版本控制并跨环境同步的内容：
-
composer.json必须手动维护：删掉require-dev里 CI 工具链（如phpunit/phpunit）再提交，否则测试依赖会污染生产构建 -
composer.lock必须由composer install生成，禁止手工编辑；若需迁移锁定版本，直接复制该文件即可，无需“导出命令” - 想查看某包实际安装版本？用
composer show vendor/package，不是从配置里“导出”——它的版本来自lock文件，而非config
最易被忽略的一点：当你在 Docker 构建中用 composer config -g repo.packagist ... 设置镜像，这个操作不会写入镜像层——因为 -g 修改的是构建容器内的 ~/.composer/config.json，而该路径通常不在最终镜像的 root 用户家目录中。正确做法是在 Dockerfile 中用 RUN composer config --global repo.packagist composer https://mirrors.aliyun.com/composer/，并确保构建用户是 root 或显式指定 COMPOSER_HOME。
