企业官网建设流程全解析

1. 为什么偏偏是Windows会撞上这个坑：从换行符差异讲起

先说个我自己的真实经历。前几年在一家做跨平台工具链的公司，某个周五下午，运维那边突然拉了一条告警：CI 构建出来的 Linux 包，里面有个 Python 脚本一执行就报\r相关错误。我当时第一反应是“又有人用记事本改代码了”，拉下来一查，果然，某个同事在 Windows 上改了那个脚本文件，提交的时候 Git 没有任何提示，但工作区里的换行符已经悄悄变成了CRLF。这个问题的恶心之处在于：在我电脑上看一切正常，代码高亮、缩进、对比完全没有异常，但只要这个文件被 Linux 上的解释器跑起来，\r就会被当成字符的一部分，轻则多打一句警告，重则直接No such file or directory。从那天起，我就彻底明白了换行符这件事不是“小事”，它属于那种能在半夜把人折腾疯的隐性问题。

换行符这件事的历史，得从上世纪讲起。早期计算机网络协议里，因为物理终端控制特性的原因，不同系统选择了不同的“一行结束”标记。Unix 系用LF（\n，ASCII 码 10），老派 Mac 用CR（\r，ASCII 码 13），Windows 从 DOS 时代继承下来的则是CRLF（\r\n，两个字符一起）。这三套体系本身谈不上谁好谁坏，问题出在它们共存于同一个软件开发流程里。Git 诞生于 Linux 生态，默认的世界观是“文本行应该以LF结尾”，所以当你把一份CRLF的文本文件提交进 Git 仓库时，Git 会面临一个选择：是原样保存，还是启动自动转换。

Git 的自动转换机制，本质上是为了解决“同一份代码，在不同系统上 checkout 出来之后，能不能让各自平台上的编辑器、编译器都舒服地使用”。理想状态是：仓库内部存LF，Windows 用户 checkout 时自动转成CRLF，提交时再转回LF。但如果这个机制没有被正确配置，就会出现两类经典问题：一类是“警告污染”，Git 每次提交都提示warning: LF will be replaced by CRLF；另一类是“全量变更”，某个文件明明只改了一行，提交记录里却显示几百行都被改掉，因为 git diff 把换行符变化当成了内容变化。前一个问题只是烦人，后一个问题会对 Code Review 造成实质性的干扰，严重的还会引发合并冲突——两个人各自改了同一份文档，一个改在CRLF文件上，一个改在LF文件上，合并时 Git 可能连一个字节都匹配不上。

所以，Windows 开发者最先要建立的一个认知是：换行符不只是“显示层”的问题，它直接参与文件内容比对、合并算法、脚本执行结果的判断。处理这一个问题的过程，说白了就是学会让 Git 在“仓库内存储格式”和“工作区实际格式”之间做正确转换。后面几节我会把所有主流的配置方式、适用场景和隐藏的坑全部铺开讲。

2. 最常用的autocrlf方案：先搞清楚三种配置模式

2.1 autocrlf的三个值：true、false、input分别做了什么

大多数教程会直接告诉你“在 Windows 上设置git config --global core.autocrlf true”，但这个建议其实非常粗糙，因为它没有考虑你的使用场景。core.autocrlf一共有三个值，搞清楚每个值在 checkout 和 commit 两个阶段分别做了什么，你就具备了自己判断该用哪个的能力。我做了个表格，方便对照：

看完这个表格你可能已经发现了一个关键点：input和false在“拉取”阶段都是“不转换”，区别在于提交阶段。input会在提交时把 CRLF 转换成 LF，所以它适合那些“开发机是 Windows，但团队规范是仓库里只允许 LF”的场景。false则是真正的“放任不管”，你工作区是什么样，仓库就是什么样——如果 Windows 上用默认编辑器保存了一个 CRLF 文件，commit 进仓库后仓库里也是 CRLF。

基于我的实际经验，true这个值有一个非常容易被忽略的副作用：它会在 checkout 时把你仓库里的所有文本文件都转成 CRLF。如果这个仓库里有 shell 脚本、Makefile、.gitattributes这样的特殊文本文件，而它们的实际内容对换行符敏感（比如 shell 脚本第一行的#!/bin/bash后面如果带了\r，在某些发行版上会直接报bad interpreter），那么true模式反而会成为问题的制造者。这也是为什么后来很多团队干脆激进地选择false，把所有换行符决策权交给开发者自己。

2.2 不同项目的配置建议：Windows专用、跨平台、每行结尾都敏感的项目各自该选什么

我见过太多人拿着同一个true配置走天下，结果在 A 项目里正常，在 B 项目里却引发了一堆 diff。实际上，你应该根据自己的项目类型，而不是个人的操作系统偏好来决定配置。我把常见情况分成三类来说明：

第一类是纯 Windows 项目。整个团队都用 Visual Studio 或某个只认 Windows 的工具链，代码仓库也只在 Windows 上使用，这种情况下core.autocrlf true是最省心的。因为 .NET 原生模板、部分旧式配置文件的默认格式就是 CRLF，你用true可以让 Git 在拉取时自动补上 CRLF，提交时再还原成 LF，避免“我明明没改，文件却显示全变了”的问题。

第二类是跨平台项目，尤其是带前后端分离、CI 跑在 Linux 上的项目。我强烈建议你设置core.autocrlf input，而不是true。为什么？因为input模式下，仓库内始终是 LF，checkout 到 Windows 工作区时又保留 LF，这样你在 Windows 上编辑文本文件时，编辑器大概率会按 LF 保存。这会让整个团队的 diff 基线保持干净。对于 CI 里要跑 lint 脚本、单元测试的项目，这种配置能直接把“Windows 上明明好好的测试，Linux 上却因为换行符失败”这一类问题的概率降到最低。

第三类是内容即代码的项目，例如 Markdown 文档仓库、配置文件仓库、脚本仓库。这些仓库对换行符的敏感度比普通代码还高，因为文档片段比对、配置项逐行解析都对字符级差异敏感。我的建议是直接core.autocrlf false，并且同时配合下面要讲的.gitattributes做仓库级规范。这个组合的好处是：仓库内容完全稳定，任何人拉下来看到的东西和 CI 里构建出来的东西完全一致，连"warning"都不会有。

2.3 实操示例：设置命令与核心配置核验

光说理论没有意义，我把实际操作命令也列一遍。这些命令都只需要敲一行，但我见过很多人敲完之后根本不检查结果，导致配置没生效也不知道。

# 查看当前全局配置 git config --global core.autocrlf # 查看当前仓库级配置（优先于全局配置） git config --local core.autocrlf # 设置全局为 input 模式（适合跨平台开发） git config --global core.autocrlf input # 为某个仓库单独设置 false 模式 cd /path/to/your/repo git config --local core.autocrlf false

另外还有一个很容易被忽视的关联参数叫core.eol，它决定的是“仓库内没有设置换行符属性时，checkout 出来用什么”。常见组合是git config --global core.eol lf，表示即使仓库里有未标注的文本文件，checkout 出来也尽量用 LF。如果你设置了core.autocrlf true，core.eol反而会被忽略，两者同时存在时，autocrlf的优先级更高。实际建议是：新项目完全可以只依赖.gitattributes，把core.autocrlf设成false，core.eol设成lf，这样行为最可预测。

提示：不要只改全局配置却忽略仓库级配置。仓库里的.gitattributes和本地git config --local都会覆盖全局配置，排查问题时先看仓库内部设置，再看全局设置，这个顺序能节省大量时间。

3. 团队协作时的终极解法：用.gitattributes强制统一

3.1 为什么光有autocrlf不够，还需要.gitattributes

core.autocrlf有一个致命缺陷：它是“本地个人配置”。同一个仓库，A 同事设了true，B 同事设了false，C 同事干脆没设置——三个人的工作区换行符行为完全不一致。而 Git 仓库是一个多人协作的共享空间，个人配置无法保证团队层面的统一。所以 Git 提供了仓库级的解决方案：.gitattributes。

这个文件一旦提交到仓库根目录，就会对仓库内所有匹配路径的文件生效，而且它的优先级比任何本地core.autocrlf都要高。这意味着只要团队review了这个文件的改动，每个人拉下来之后就会自动适用同一套换行符规范。我自己经历过一次印象深刻的转变：某项目有十几个开发者，Windows 和 macOS 各半，之前一直在群里争论“为什么你的提交会把我刚整好的格式全打乱”，后来我把.gitattributes一加，半个月内此类争论直接归零。这就是仓库级规则和本地个人偏好之间的本质区别：前者是制度，后者是习惯。

.gitattributes的判断逻辑是“按路径匹配规则”，类似于.gitignore的语法。Git 在每次 checkout、add、merge 的时候都会读取它，然后根据匹配到的规则决定是否进行换行符转换。利用这一点，我们不仅可以强制所有文本文件统一为 LF，还可以精准地排除二进制文件，避免 Git 对图片、压缩包做任何换行符处理——因为二进制文件一旦被转换，整个文件就损坏了。

3.2 .gitattributes的常用写法与字段详解

我直接给出一份经过多项目验证的模板，然后逐行解释关键点：

# 所有文件先走 Git 自动检测 * text=auto # 源码文件统一 LF *.c text eol=lf *.h text eol=lf *.js text eol=lf *.ts text eol=lf *.py text eol=lf *.java text eol=lf *.go text eol=lf *.sh text eol=lf # 文档与配置文件也统一 LF *.md text eol=lf *.json text eol=lf *.yaml text eol=lf *.yml text eol=lf *.toml text eol=lf *.ini text eol=lf # 需要明确保持 CRLF 的特殊文件（极少见） *.bat text eol=crlf *.cmd text eol=crlf # 二进制文件不要做任何转换 *.png binary *.jpg binary *.jpeg binary *.gif binary *.ico binary *.pdf binary *.zip binary *.tar.gz binary *.exe binary *.dll binary *.so binary *.class binary

这里面的关键字段有三个：text、eol、binary。

text标记表示“这个文件以文本方式对待，允许 Git 进行换行符归一化”。它可以带值，比如text=auto表示让 Git 自己 detect 文件是文本还是二进制；不带值时表示强制按文本处理。eol字段则指定了“该文件在工作区 checkout 时的换行符类型”，可选的只有两个合法值：lf和crlf。这里有个容易混淆的点：eol=lf只影响 checkout 输出，不影响提交入库时 Git 采用什么换行符。真正决定“入库时是什么换行符”的，是在text标记作用下，Git 会把工作区里的换行符统一转换成LF再入库，除非你显式加上-text。

binary等价于-text -diff，表示这个文件不参与任何文本归一化，也不做 diff 文本比对。对于二进制文件来说，这是绝对必要的，否则 Git 的 autocrlf 机制可能把图片里的某个字节序列误判为换行符，导致文件损坏。我见过一个真实案例：某设计师把 PNG 图标提交进 Git 仓库，因为.gitattributes里漏写了*.png binary，而他又开着core.autocrlf true，结果每次 checkout 之后图标文件都会变小几个字节，图片直接打不开。后来排查半天才发现是换行符归一化把它里面碰巧出现的0x0D 0x0A序列给“好心”地改掉了。

3.3 文件级规则生效的验证方法：git check-attr

配置.gitattributes之后，怎么确认某个文件到底有没有被正确匹配？我见过很多人直接把文件拉到另一个系统上试，效率太低。正确的验证姿势是用 Git 自带的git check-attr命令：

# 检查某个文件的换行符属性 git check-attr text -- path/to/file git check-attr eol -- path/to/file # 检查整个仓库里所有文件的 text 属性 git ls-files | xargs git check-attr text

如果输出显示text: set，说明文件被命中了 text 规则；如果输出text: unspecified，说明没有配置命中。这里要特别强调一个细节：.gitattributes的匹配规则遵循“最精确匹配优先”，也就是说*.bat text eol=crlf会覆盖* text=auto对.bat文件的规则。所以如果你发现某个文件没有按预期统一为 LF，先用git check-attr看看是不是有更精确的规则抢先命中了。

另外一个容易踩的坑是：.gitattributes只对“已经追踪的文件”产生规则影响吗？不是的。它对新加入的文件的生效方式是：在git add时，Git 会按照当时的.gitattributes规则把工作区内容转换后写入索引。所以如果你新写了一个.gitattributes，已经存在于仓库里的文件不会自动发生转换，你需要手动让 Git 重新检视一遍所有文件，这个步骤我们放到第四节详细说。

4. 仓库已经被污染了？一套完整的仓库清洗流程

4.1 先确认污染范围：CRLF入库的文件有哪些

换行符问题最头疼的不是配置本身，而是“历史包袱”。很多团队在意识到要统一换行符之前，仓库里已经混入了大量 CRLF 结尾的文件。这时候如果你直接加一个.gitattributes，提交时会看到几百个文件全部变成“modified”，如果不处理，下次别人一拉代码就全乱了。所以第一步不是修改，而是摸清污染范围。

我常用的快速排查方法是用file命令和git grep配合，但更高效的是直接让 Git 自带的功能来做判断。你可以先创建一个临时分支，在这个分支上使用git add --renormalize，然后查看git status，看看到底有多少文件显示为 modified。这个命令是 Git 2.16 之后引入的，作用就是“按当前.gitattributes规则，重新标准化所有已追踪文件的换行符”。

# 先创建一个临时分支，避免影响主分支状态 git checkout -b fix/newline-normalize # 添加 .gitattributes 文件（假设原来没有） # 然后在仓库根目录执行： git add --renormalize . git status

执行完git status后，你会看到两类信息：一类是.gitattributes本身，另一类是被重新归一化后产生差异的文件列表。文件列表的数量直接反映了污染严重程度。如果只有零星几个文件，说明仓库整体还算干净；如果看到几百个文件，说明历史问题的确积重难返，但这并不意味着要手动去改每个文件，后面的流程会一次性解决。

4.2 标准清洗流程：改对.gitattributes，然后统一renormalize

现在正式进入清洗步骤。先确保你的.gitattributes内容已经正确覆盖了所有需要处理的文件类型，然后执行完整的归一化操作。这是一套我在多个仓库上验证过完全可行的流程：

1. 备份当前工作区：先确保没有被修改的未提交文件，git status干净后再继续。
2. 写入.gitattributes** 规则**：把上一节给的模板按需修改后放入仓库根目录。
3. 执行归一化：

# 让 Git 按照新规则，重新标准化所有已跟踪文件 git add --renormalize . # 查看变更清单，确认里面没有二进制文件被误伤 git status # 如果有二进制文件被误伤，回到步骤2，补充 binary 规则 # 确认无误后，提交 git add .gitattributes git commit -m "chore: normalize line endings to LF"

这里有一个极其重要的原则：清洗换行符的提交，应该只涉及换行符变化，不要夹带任何业务代码改动。一旦你把“修复 CRLF”和“顺手改了个变量名”混在一起，review 的人将无法用 diff 工具定位真实变化，出了问题时责任也说不清。我自己的做法是：先单独提交换行符标准化，再在后续提交里做真正的功能改动。这看起来多花了一次提交，但收益非常明显——之后你可以随时用git log --follow追溯历史，不会因为换行符污染而丢失文件的真实变更记录。

4.3 清洗之后还要补一发：重新checkout验证工作区状态

提交完成之后，还差最后一步验证。有人清洗完提交就以为大功告成，结果分支合并回主分支后，其他人 pull 下来发现工作区仍然带着 CRLF。这是因为：git add --renormalize处理的是索引和仓库对象，而工作区里的文件换行符不会因为你提交一次就自动改变。工作区的状态受 checkout 阶段的行为决定，由core.autocrlf和.gitattributes共同控制。

所以正确的收尾动作是要让 Git 重新 checkout 一遍所有文件。最简单的方式是：

# 保证工作区干净 git status # 然后删除所有已追踪文件，再重新拉取 git rm -r --cached . git reset --hard HEAD # 检查工作区文件是否已经是 LF # Windows 上可以用 PowerShell 查看 Format-Hex -Path path/to/example.txt | Select-Object -First 2

注意git reset --hard HEAD会丢弃未提交的改动，所以这一部必须在工作区绝对干净的情况下执行。如果你有本地未提交的修改不想丢，建议先git stash，等 reset 后git stash pop再手动处理冲突。另外，使用git rm -r --cached . && git reset --hard HEAD这种操作，本质上是在重建整个索引与工作区，耗时较长，仓库特别大的话需要耐心等待，但这是确保工作区换行符状态干净的可靠办法之一。

4.4 针对持续集成的补充：CI流水线里的换行符验证

清洗完仓库之后，很多人都忽略了一个“防止问题复发”的重要环节——在 CI 流水线里加一道换行符检查。我从一个开源项目的配置里抄过一个很轻量的做法：在 CI 脚本里跑一个 grep 检查，禁止 CRLF 出现在关键文件类型中。

# 检查所有 .py 文件是否混入 CRLF if grep -rU $'\r$' --include="*.py" .; then echo "CRLF found in Python files, please use LF." exit 1 fi

这段逻辑可以放进 CI job 的早段，一旦有人误提交了 CRLF 文件，流水线直接失败，迫使开发者立刻处理。比这更正规的做法是直接借助 Git 的git diff --check，它会在 diff 输出中检测到“空白错误”，包括换行符末尾的异常空白。把这个命令挂在 CI 或者提交前钩子里，能防住一大部分该问题。当然，对于已经规范化的新项目来说，.gitattributes本身就足以拦截大多数情况，CI 这道检查属于双保险。

5. 编辑器与工具链的连环坑：VS Code、Notepad++与PowerShell

5.1 VS Code右下角的“CRLF/LF”切换与工作区配置

处理完 Git 层面的问题，工具链层面的坑依然不少。首当其冲的是 VS Code，因为它是目前 Windows 上最主流的代码编辑器。VS Code 右下角状态栏会显示当前文件的换行符类型，点击就可以在CRLF和LF之间切换。这功能本身没毛病，但问题在于很多开发者根本没有留意过它的存在，于是默认的 CRLF 就一路跟着文件进了仓库。

就算你手动把文件切成了 LF，VS Code 可能会在你下次打开时又变回 CRLF，因为 VS Code 的“默认换行符”设置项files.eol默认值是auto。auto的含义是“跟随文件当前状态”。听起来合理，但如果文件里既有 LF 又有 CRLF 的混合换行符，它就会二选一的“自动纠正”，而 Git 在 diff 时又会把这个纠正当成真实内容变化。所以我的建议是，在团队项目里直接在.vscode/settings.json中固定默认值：

{ "files.eol": "\n", "files.encoding": "utf8", "editor.renderWhitespace": "all" }

把files.eol强制设成\n之后，VS Code 在 Windows 上新建文件、保存文件时都会尽量使用 LF。这会从源头减少误提交 CRLF 的概率。renderWhitespace: all是辅助项，开启后能看到行尾的CR、LF符号，方便你在编辑时直观判断哪些文件的换行符不符合预期。

5.2 Notepad++注意“编辑→EOL转换”和不可见的CR字符

老一辈 Windows 程序员对 Notepad++ 都有感情，但 Notepad++ 对换行符的处理同样是个陷阱。它的状态栏会直接显示当前文档是Windows (CRLF)还是Unix (LF)，菜单里有“编辑 → 行尾转换 → Unix (LF)”这个操作，看起来很简单对吧？但这里有个历史遗留问题：如果你从别的编辑器粘贴了一段带 CRLF 的文本进 LF 文档，Notepad++ 并不会主动做转换，而是原样保留混合状态。而这种混合换行符文件，比纯 CRLF 文件更容易制造 diff 混乱。

所以如果你在团队里还在用 Notepad++ 编辑脚本文件，建议先养成两个习惯：第一，打开文件后先看状态栏的 EOL 类型，不是 LF 就先转换；第二，开启“视图 → 显示符号 → 显示行尾”，这样每个换行符都会以符号形式可见，CRLF 和 LF 一眼可辨。很多人觉得我小题大做，直到有一次一个 shell 脚本运行时报bad interpreter: /bin/bash^M的错误，他才意识到 Notepad++ 默认保存时把整个文件写成了 CRLF，而脚本第一行从此多了一个“看得见的隐身字符”。

5.3 PowerShell重定向时躲不开的CRLF

这一条可能更冷门，但非常实际。Windows 上的 PowerShell 在做输出重定向时，默认编码是 UTF-16 LE，而且换行符默认就是 CRLF。这意味着如果你在 PowerShell 里执行Get-ChildItem > filelist.txt，然后把这个文件提交到 Git 仓库，它就大概率带着 CRLF。如果你在 Linux 上再用 shell 脚本去逐行读取这个 filelist.txt，每一行末尾都会跟着一个\r，轻则匹配不到内容，重则整个脚本逻辑错乱。

解决这个问题，我一般用两条路：如果你只是临时重定向，可以用：

# 先将结果转为字符串数组，再用 LF 拼接写入 (Get-ChildItem | ForEach-Object { $_.Name }) -join "`n" | Set-Content -NoNewline -Encoding utf8 filelist.txt

如果你希望全局避免 PowerShell 默认 CRLF 干扰 Git 操作，建议在$PROFILE里设置默认输出编码：

# 设置默认编码为 UTF-8 [Console]::OutputEncoding = [System.Text.Encoding]::UTF8 $OutputEncoding = [System.Text.Encoding]::UTF8

顺带一提，PowerShell 5.1 的Set-Content默认编码是Default（ANSI），跟跨平台 UTF-8 之间又隔了一层编码坑。对这些细节的处理经验，我的总结是：Windows 上的一切命令行输出类工具，只要是“写字到文本文件”，你都默认怀疑它会写 CRLF，然后用工具验证一下，能省去很多半夜排查的时间。

5.4 脚本文件（sh、py等）为什么切忌CRLF

说到换行符对脚本的“杀伤力”，我必须单独开一段细聊。Shell 脚本对 CRLF 的敏感不是“可选错误”，而是“致命错误”。在 Windows 上写好并提交了一个.sh文件，拉取到 Linux 容器里一执行，第一行#!/bin/bash后面如果跟着\r，操作系统在解析 shebang 时会拿着/bin/bash\r去找解释器，百分百找不到。你看到的错误是：

/usr/bin/env: 'bash\r': No such file or directory

或者更迷惑的：

: No such file or directory

这种报错的最大迷惑性在于：大多数人看到它不会联想到换行符，而是怀疑路径配置、怀疑环境变量、怀疑自己是不是拼错了什么。我曾经帮一个同事排查这个问题，他花了整整一个下午给容器里装各种依赖、改 PATH、重启服务，最后我让他把文件末尾用xxd看一眼，他立刻看到了 0d0a，当场恍然。

Python 脚本对 CRLF 的敏感程度取决于运行方式和依赖。如果你用python script.py直接跑，解释器通常能容忍行尾的 CR，但如果你把脚本作为模块导入、用#!/usr/bin/env python的 shebang 执行，或者在容器里以 UNIX 方式运行，CRLF 就可能引发各种奇怪的解析错误。更麻烦的是，当 Python 代码里包含多行字符串时，CR 会混入字符串内容，导致 Hash 值、断言、日志格式全都不一样。所以最稳妥的策略还是那句话：跨平台的脚本类文件，一律仓库内 LF，工作区 LF，严禁 CRLF。

5.5 补充建议：让.editorconfig也参与换行符管理

除了 Git 自身的规则之外，还有一个很容易和.gitattributes混淆但完全互补的东西：.editorconfig。它的作用不是给 Git 看，而是给编辑器看——告诉编辑器，这个仓库里的文件应该用哪种换行符、缩进风格、字符编码。因为它被各类主流编辑器原生支持，所以能在文件写入阶段就从源头避免错误换行符的产生。

一份基础的.editorconfig模板长这样：

root = true [*] charset = utf-8 end_of_line = lf insert_final_newline = true trim_trailing_whitespace = true indent_style = space indent_size = 2 [*.bat] end_of_line = crlf

注意：.editorconfig对 Git 没有强制力，它只是编辑器行为规范。Git 是否遵守它，取决于你是否在.gitattributes里配置了对应的换行符规则。正确的关系是：.editorconfig负责让开发者在写代码时就输出 LF；.gitattributes负责在 Git 层面兜底，就算有人用某个不认.editorconfig的编辑器，Git 在入库阶段仍然能把换行符统一回来。两个文件一起放到仓库根目录，才算真正把换行符问题堵死。

6. 长期实践下来的几点个人经验

处理换行符问题那么多年，如果只让我浓缩成几条提醒，我会选这几条：第一，别把core.autocrlf true当万能药，跨平台项目里它带来的麻烦往往比解决的更多；第二，仓库级的.gitattributes是所有换行符治理的基石，个人配置永远没法替代制度；第三，git add --renormalize .是清洗仓库的利器，但一定要在隔离分支上操作，并且单独提交。

诊断和处理顺序上，我的建议永远是：先看.gitattributes是否覆盖了出问题的文件类型；然后看仓库里该文件的已提交版本到底是什么换行符，可以用git show HEAD:path/to/file | file -来确认；最后再看本地工作区的实际内容，用 VS Code 或者命令行工具确认。绝大多数换行符疑难杂症，按“规则 → 仓库 → 工作区”这个顺序排查，基本都能在三步内定位。

最后补一个细节技巧：在 Windows 上写.gitattributes本身的时候，也请务必用 LF 保存。你可能会觉得这是轮回——为了防止换行符问题，结果配置文件自己又引入了换行符问题。但实际情况就是，如果.gitattributes内混入了 CRLF，Git 在解析它的时候虽然通常能容忍，但在某些版本上会出现规则命中失败的诡异现象。写完这个文件之后，建议用git check-attr text -- .gitattributes验证一下状态，保证这个“规则的规则”也是干净的。