Composer本身不处理视频导出或色彩管理，偏色问题源于下游工具链（如FFmpeg、php-ffmpeg、Ghostscript）的参数配置、色彩元数据缺失或系统时间偏差导致依赖降级。
Composer 本身不处理视频导出或色彩管理——它是个 PHP 依赖管理工具，没有视频编解码、色彩空间转换或监看输出能力。如果你在用 Composer 安装的某个包（比如 ffmpeg-php 封装、php-ffmpeg 或自研转码服务）导出视频后出现偏色，问题一定出在下游工具链，而非 Composer 本身。
为什么 composer install 后视频颜色变了？
这其实是典型的“责任错位”：Composer 只负责把代码下载到 vendor/ 目录，真正干活的是你调用的库或命令行工具（如 FFmpeg、Ghostscript、ImageMagick）。偏色往往来自：
- FFmpeg 默认不嵌入色彩元数据，导出的 MP4 可能被播放器按 Rec.709 解析，但原始素材是 Log 或 P3；
-
php-ffmpeg封装未显式设置-colorspace、-color_primaries等参数； - Ghostscript 转 PDF 为 PNG 时未指定
-dUseCIEColor或-sOutputICCProfile，导致 CMYK→RGB 映射失真； - 本地系统时间偏差超 15 分钟，触发 Composer 包签名验证失败，间接导致你回退到旧版有 bug 的转码逻辑（见
signature verification failed错误）。
如何定位是哪个环节导致偏色？
别猜，直接查输出源头：
- 如果用
exec('ffmpeg -i ...')，在命令末尾加-vstats_file stats.txt -v debug，检查日志里是否出现color_space:smpte170m或color_primaries:bt709等字段； - 如果用
php-ffmpeg，确认是否调用了$video->setVideoColorSpace('bt709')—— 它默认不设，由 FFmpeg 自行推断； - 如果用
org_heigl/ghostscript，检查是否传了setInputColorSpace('CMYK')和setOutputColorSpace('sRGB')； - 运行
date和timedatectl status，排除因时间不同步导致你误用了降级版依赖（例如 fallback 到一个没修 CMYK bug 的旧 commit）。
composer.lock 里藏着色彩配置线索吗？
不直接藏，但能帮你锁定问题版本。比如你发现升级 php-ffmpeg 后偏色消失，就用 git diff 对比前后 composer.lock 中该包的 dist.reference，再查对应 commit 的 CHANGELOG —— 常见修复点包括：add support for -color_trc flag、fix sRGB ICC profile embedding in PNG output。
提取线索的实操命令：
jq -r '.packages[] | select(.name == "php-ffmpeg") | "\(.version) \(.dist.reference)"' composer.lock
注意：别只看 require 版本号，dist.reference 才是真实加载的 Git 提交哈希。
真正要调的不是 Composer，而是你 require 进来的那个视频处理库的参数、FFmpeg 的命令行选项、以及系统级色彩描述文件是否冲突——Composer 只是那个递给你扳手的人，扳手拧哪儿、用多大力，得你自己决定。
