Composer 不处理行结尾转换，行尾由 Git 配置（如 core.autocrlf）或 .gitattributes 决定；vendor/ 和 composer.lock 的换行符需通过 .gitattributes 统一规范为 lf，避免跨平台问题。
Composer 本身不处理跨平台行结尾（CRLF vs LF）的自动转换，它既不会在安装包时重写文件换行符，也不会在生成 vendor/autoload.php 或其他产出文件时做规范化。行结尾由源码仓库（如 Git）或原始包发布者决定，Composer 只负责原样提取和复制。
Git 的 core.autocrlf 才是关键控制点
绝大多数 Composer 包通过 Git 获取（哪怕是 packagist.org 上的），而行结尾实际由 Git 的换行符策略控制：
- Windows 用户若未配置，Git 默认启用
core.autocrlf=true：检出时转 CRLF，提交时转 LF - Linux/macOS 默认
core.autocrlf=input：提交时转 LF，检出时不转换 - 若项目根目录存在
.gitattributes，它的规则（如* text=auto eol=lf）会覆盖全局设置 - Composer 安装的
vendor/内容受当前 Git 配置影响——比如你在 Windows 上composer install，且core.autocrlf=true，那 vendor 里 PHP 文件很可能含 CRLF
composer.json 中没有行尾相关配置项
不存在类似 "line_ending": "lf" 或 "normalize_eol" 这类字段。以下常见误操作需避免：
- 不要在
composer.json中添加自定义脚本试图批量替换换行符（如dos2unix vendor/**/*.php），这破坏可重现性且易漏文件 -
scripts中的 post-install-cmd 不应承担换行标准化职责——它无法保证所有开发者执行、也不解决 CI 环境差异 - 别依赖
composer dump-autoload --optimize来“修复”换行：该命令只优化类映射，不触碰源码内容
真正需要干预的场景与做法
仅当出现明确问题时才需介入，例如：CI 构建因行尾不一致导致 PHP 语法错误（极罕见，但某些旧版 PHP 解析器对 CR 敏感），或代码审查工具（如 PHPCS）报 Generic.Files.LineEndings.InvalidEOLChar 错误：
- 首选方案：统一用
.gitattributes声明文本文件规范，例如在项目根目录添加：
* text=auto eol=lf *.php text eol=lf *.json text eol=lf /composer.lock text eol=lf
- 次选方案：CI 脚本中强制标准化（仅限不可控第三方包）：
find vendor/ -name "*.php" -exec sed -i 's/\r$//' {} + 2>/dev/null || true - 注意：不要对
vendor/做 git add 或 commit——它不是你的源码，修改后下次composer install会被覆盖
最常被忽略的是：composer.lock 文件本身也受 Git 换行策略影响。如果它在 Windows 上被写成 CRLF，而 Linux CI 机器按 LF 解析，可能引发哈希校验失败或解析异常——所以务必确保 composer.lock 在 .gitattributes 中显式声明为 eol=lf。
