授权与合规声明
本文全部操作对象均为自建隔离靶场（本机容器或隔离虚拟机），涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款，须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离，不含任何攻击步骤、利用载荷与绕过手法，请勿将文中环境指向任何非自有系统。
一、同一份文件，两个系统上表现不一样
1.1 一个几乎人人都遇到过的场景
你在 Windows 上照着一份教程写好了一个小脚本，或者把教程里的一段配置复制下来存成一个文件。在原来那个环境里，它按预期走。把同一个文件拿到虚拟机的 Linux 里、或者挂进容器里，它就不按预期走了。
奇怪的地方在于：你打开它看，内容一模一样。字符一个不多一个不少，缩进对齐，括号配对，看着都对。你甚至把两边并排放在屏幕上逐字比过。
还有一类情形更常见，也更容易被忽略：复制粘贴。你从教程网页上把一段代码或者一段配置复制下来，粘进本地新建的文件里。粘贴这一步由谁完成、用什么编辑器完成、这个编辑器保存时的约定是什么，都要算进这份文件的最终形态。换一条复制路径，落到文件里的字节就可能不一样。
"看起来一样"这句话，在文件这一层并不成立。**你眼睛看到的是编辑器渲染出来的形状，文件本身是一串字节。**这两者之间隔着一层转换：编辑器把字节渲染成字符给你看，也把你敲下的字符渲染回字节存进文件。这层转换里有一些东西，默认对你是不可见的。
1.2 本文讲的是内容层
文件里那些你在编辑器里看不见、但它确实是文件内容的字符，本文统一称为内容层的问题。
要强调的是"确实是文件内容"这半句：它们不是编辑器的显示设置，不是主题配色，也不是字体宽度。把文件发给别人，把它提交进仓库，把它挂进容器——这些字符都跟着文件一起走，换一台机器打开，它们还在。
先把这件事说清楚，是因为初学者遇到"看起来一样却行为不一样"，往往会往几个完全不同的方向去找原因。这些方向都藏在"看起来一样"四个字底下，但解法毫无关系。
| 差异 | 藏在哪里 | 是否在本文范围内 |
|---|---|---|
| 行尾的形态、字符编码、文件开头的不可见标记 | 文件内容这一层 | 是 |
| 路径名字的大小写、分隔符、当前所在目录 | 名字这一层 | 否 |
| 一个路径到底是本体，还是指向别处的名字 | 身份这一层 | 否 |
1.3 为什么先看内容层
理由有两个，都很实在。
第一，**它的排查成本最低。**内容层的问题只要一条只读命令就能看到，不用改配置、不用重装、不用换环境。而另外两层往往要动路径、动目录，成本高得多。
第二，**它是唯一一层"你不专门去看，就永远看不到"的问题。**逻辑错了，程序会停下；依赖缺了，功能会缺一块。行尾多一个字符这种事，两边看起来完全一样，你不主动把不可见字符显示出来，它就一直在那儿。
还有一条经验：内容层的问题往往"改动很小、影响很大"。多出来的东西不改变可读性，却可能让所有按字节或按行判断的地方一起落空。所以在这一层，看一眼的成本最低，收益却最直接。
一条可以先记住的判断：如果同一份文件在不同系统上行为不同，而你没有改过任何逻辑，那么先怀疑内容层。
二、一个换行，在文件里可能是一个字符，也可能是两个
2.1 官方原话
Git 官方书在讲配置格式与空白字符那一节，把这件事说得很直接（逐字引文见附表 A 第 1 行）：
This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas macOS and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work; many editors on Windows silently replace existing LF-style line endings with CRLF, or insert both line-ending characters when the user hits the enter key.
这段话的要点是：Windows 在文件里用回车符加换行符两个字符表示换行，macOS 与 Linux 只用换行符这一个字符。
也就是说，"你在编辑器里按了一下回车"这件事，落到文件的字节上，可能是多了一个字符，也可能是多了两个。你在屏幕上看到的是"换行"这个效果，不是字符本身。
⚠️代码待验证
【同一次"按回车"，文件里多出来的东西可能不同】 Windows 上编辑保存： 行内容 + 回车符 + 换行符 macOS / Linux 保存： 行内容 + 换行符 在编辑器里看到：两种情况都显示成"换行"，看不出区别 在文件里实际是：一个字符，与两个字符的差别2.2 官方那句静默，比行尾本身更值得记住
上面那段引文里最容易读漏的是后半句：many editors on Windowssilentlyreplace existing LF-style line endings with CRLF。
主语是编辑器，动词是替换，副词是静默。合起来的意思是：**你不是主动改的。**你只是打开了一个文件、看起来什么都没动、保存了；行尾就是在这一步被换掉的。
这一点正好解释了初学者最想不通的地方：我明明只改了几个字，为什么整份文件的处理结果都变了。因为改的从来不只是那几个字——**一次保存动作本身，就会把文件里所有同形态的行尾统一重写。**你没有碰到那些行，是编辑器替你碰了。
换个角度看会更清楚：你在编辑器里只做了一个动作，编辑器却替你补完了后面一连串决定——用哪种行尾保存、用什么编码写出字节、要不要在文件末尾补上终止换行。这些决定你都没有参与，但它们都写进了文件。同一份文件被两个系统上的两个编辑器先后打开又保存，落进去的字节自然可能不一样；这不是你操作错了，而是这个过程里本来就有很多你没参与的决定。
Git 官方书接着说明了它自己的处理方向（逐字引文见附表 A 第 2 行）：
Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem.
入库时把 CRLF 转成 LF，检出到你的工作目录时反过来。注意这里的用词是 can——能做，而不是"一定会做"。后面第四章和第五章会说明，这两件事的差别正是问题所在。
2.3 POSIX 官方规范对行的定义
POSIX 官方规范在第 3 章"定义"里，先给换行符本身下了定义（逐字引文见附表 A 第 8 行）：
A character that in the output stream indicates that printing should start at the beginning of the next line. It is the character designated by ‘\n’ in the C language.
然后给"行"下定义（逐字引文见附表 A 第 9 行）：
A sequence of zero or more non- characters plus a terminating character.
关键在末尾那半句：plus a terminating<newline>character——零个或多个非换行字符，再加上一个终止换行符。换句话说，一段文字只有末尾带上终止换行符，在规范意义上才算一条完整的行。
更有意思的是，规范还专门给"末尾缺终止换行"这件事起了名字（逐字引文见附表 A 第 10 行）：
A sequence of one or more non- characters at the end of the file.
这个术语叫不完整行（Incomplete Line）。规范专门为一个状态起名字，说明它并不被认为是笔误，而是一种需要被单独标识出来的形态。
落到实操上的结论：**"文件最后一行没有换行"不是显示问题，它是文件内容的一个差异。**你在编辑器里看不出来，因为在编辑器里它一样显示成一行。
三、第二层：同样的字符，可以有不同的字节形态
3.1 字符和字节之间隔着一层编码
"编码"就是把字符映射成字节的一套约定。同一段文字，用不同的约定保存，文件里的字节序列就不一样；某些字符在不同约定下占用的字节数也可能不同。
这件事对纯英文的文件影响不大，一旦文件里出现中文、全角标点或者某些特殊符号，差异就会显形。这里要分清一个容易被混起来的判断：**"内容相同"和"字节相同"是两件事。**你在编辑器里读到的是前者，各种工具在文件层面处理的是后者。
落到初学者身上的含义是：读取这份文件的程序，是按某一种约定去解释那些字节的。字节序列变了，它读出来的字符就可能不是你以为的那些。这类差异不会报错，它只会让你的处理结果和预期不一致。
这里还有一个反过来用得上的判断：既然字节序列会随编码变化，那么**"内容看起来没变、两次保存后文件大小却不同"本身就是一个可观察的信号**。大小变了，说明写进去的字节序列变了；至于是行尾变了还是编码变了，再用下一节的只读动作去分。
3.2 有的编码会在文件开头加一段不可见标记
第二件要讲清楚的：某些编码形态会在文件的最开头写入一段标记，用来表明这份文件用的是哪种编码与字节顺序。这段标记通常被称为字节顺序标记（BOM）。它不承载任何可见字符，在编辑器里通常什么都不显示。
真正麻烦的是它的位置：**它在文件的第一行之前。**如果一份配置文件的读取逻辑是"第一行必须是某个固定内容"，或者干脆按固定字节位置去读，那么开头多出来的这几个字节就可能让这个判断落空。
这里必须先交代本文的边界：截至 2026-09-25，本文没有核到"哪种编码在什么情况下会写入这段标记"的官方逐字口径，所以本文只讲"存在这样一段不可见标记、它在文件开头"这个原理，不给任何具体结论（附表 A 第 12 行标了待验证）。你自己遇到时，用下一节的只读动作去看。
3.3 把不可见的东西显示出来
下面三条都是只读动作，不改动任何文件。
⚠️代码待验证
file<路径>cat-A<路径>ls-l<路径>file <路径>：只看一件事——这个文件被当前系统识别成什么类型。这个判断会影响后面所有的处理动作。cat -A <路径>：把文件内容里的不可见字符按可见形式显示出来。"我看不见"这一层，最直接的解法就是它。ls -l <路径>：看这个文件的基本属性，其中文件大小可以用来对照"两次保存之后有没有变"。
| 只读动作 | 它回答的问题 | 得到的判断 |
|---|---|---|
file <路径> | 这个文件被识别成什么类型 | 是文本还是二进制，决定后面能不能按文本处理 |
cat -A <路径> | 不可见字符长什么样、在哪个位置 | 行尾是一个字符还是两个、开头有没有多出标记 |
ls -l <路径> | 这个文件的体量有多大 | 两次保存前后对照，看内容有没有被动过 |
本文不贴这三条命令的实际输出，也不给任何转换工具的安装与用法（附表 A 第 13 行标了待验证）。你要做的只有一件事：把<路径>换成你自己的文件，逐条跑一遍，然后对着字符看，而不是对着文字看。
四、第三层：为什么工具不会自动帮你兜住
4.1 工具不是不想帮，是它分不清
很多人的期待是：既然行尾有两种形态，工具就应该自动帮我统一。Git 官方文档在core.safecrlf这一条里，把"为什么做不到"写得相当坦白（逐字引文见附表 A 第 6 行）：
CRLF conversion bears a slight chance of corrupting data. When it is enabled, Git will convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a mixture of LF and CRLF before the commit cannot be recreated by Git. For text files this is the right thing to do: it corrects line endings such that we have only LF line endings in the repository. But for binary files that are accidentally classified as text the conversion can corrupt data.
这段话里有三个结论，每一个都值得单独记住：
- **混用行尾的文件，Git 无法还原。**原文是 A file that contains a mixture of LF and CRLF before the commit cannot be recreated by Git，用词是 cannot be recreated——不能被重新造出来。这个转换动作在信息上是有损的。
- 对文本文件来说，这个动作是对的：它把行尾统一，使仓库里只剩下 LF。官方原话是 this is the right thing to do。
- **但被误判成文本的二进制文件，转换会损坏数据。**原文是 But for binary files that are accidentally classified as text the conversion can corrupt data。
第二条和第三条摆在一起，就是问题的全部：同一个转换动作，在一种文件上是对的，在另一种文件上会造成损坏。而工具在动手之前，并不知道手里这份是哪一种。
4.2 官方承认：这两件事区分不开
紧接着的一句，是这一层最硬的一条（逐字引文见附表 A 第 7 行）：
Unfortunately, the desired effect of cleaning up text files with mixed line endings and the undesired effect of corrupting binary files cannot be distinguished. In both cases CRLFs are removed in an irreversible way.
逐字读：**"清理混用行尾的文本文件"这个想要的效果，和"损坏二进制文件"这个不想要的效果，无法被区分。**在两种情况下，CRLF 都是以不可逆的方式被移除的。
这句话把"为什么工具不会自动帮你兜住"回答干净了：**不是工具偷懒，也不是某个开关没打开，而是这个动作本身在信息上就不足以判断后果。**你唯一能提前做的事，是在动手之前先确认自己手里是什么文件。
4.3 三个落到实处的提醒
- **不要把"提交成功了"当成"文件被正确处理了"。**提交成功只说明动作走完了，不说明结果无损。混用行尾的文件，官方明说无法还原。
- **二进制文件不该被当作文本处理。**图片、压缩包这类文件一旦被误判成文本，转换就会损坏数据。判断依据就是第三章里
file给出的那个结果。 - **文件里本来就混着两种行尾时，任何一次"统一"都是一次不可逆的动作。**这是官方自己给出的结论，不是推测。
把第四章这两条官方原文压成一张小对照，会更容易记住它为什么兜不住。
⚠️代码待验证
【同一个转换动作，两种结果】 对文本文件： 想要的效果 -> 行尾被统一，仓库里只剩下 LF 对二进制文件： 不想要的效果 -> 数据被损坏 而这一层的关键在于： 动手之前，无法区分手里这份是哪一种（官方原话） 两种情况下，被移除的 CRLF 都不可逆（官方原话） 一句话：不是开关没打开，是这一层在信息上就不足以判断后果。这张对照想说的不是"要小心工具"，而是这一层本来就不该指望工具替你兜底。工具能做的是按规则执行，做不到的是替你判断手里这份文件的意图。
五、Git 的两个开关，以及它们为什么互相覆盖
5.1 第一个开关：core.autocrlf
Git 官方 git-config 文档对core.autocrlf的原文（逐字引文见附表 A 第 3 行）：
Setting this variable to “true” is the same as setting the text attribute to “auto” on all files and core.eol to “crlf”. Set to true if you want to have CRLF line endings in your working directory and the repository has LF line endings. This variable can be set to ‘input’, in which case no output conversion is performed.
按官方措辞整理成对照表如下。
| 取值 | 官方口径 | 落到你身上的效果 |
|---|---|---|
| true | 等同于对所有文件设置text属性为 auto，并把core.eol设为 crlf | 工作目录里得到 CRLF 行尾 |
| input | 原话为 no output conversion is performed，即不做输出方向的转换 | 工作目录里的行尾不被改写 |
| false | 待验证：官方这一条只逐字给出 true 与 input 的口径，false 的逐字说明本次未核到 | 本文不写结论 |
表里第三行是有意留下的。没有核到逐字原文的取值，就不写结论——这是本文对所有事实的一贯处理方式，附表 A 里也照此标了待验证。
5.2 第二个开关：core.eol
同一个文档里对core.eol的原文（逐字引文见附表 A 第 4 行）：
Sets the line ending type to use in the working directory for files that are marked as text (either by having the text attribute set, or by having text=auto and Git auto-detecting the contents as text). Alternatives are ‘lf’, ‘crlf’ and ‘native’, which uses the platform’s native line ending. The default value is native.
三个要点：它管的是工作目录里用哪种行尾；它只对被标记为文本的文件生效；三个可选值是lf、crlf、native，其中 native 用的是平台的本地行尾，官方注明默认值是 native。
5.3 互相覆盖：为什么你改了却像没改
这个开关的条目末尾还有一句（逐字引文见附表 A 第 5 行）：
Note that this value is ignored if core.autocrlf is set to true or input.
逐字读：如果core.autocrlf被设成 true 或 input，这个core.eol的值就会被忽略。
这就是"我改了配置却没生效"在这一层的现成解释。你以为自己在用core.eol决定工作目录里的行尾，实际上只要core.autocrlf是 true 或 input，这个开关根本轮不到说话。
由此还能推出一条对初学者更实用的判断：**当你从教程里抄来一条行尾相关的配置时，先确认这条配置生效的前置条件在你这里成不成立。**同一句话，在别人的仓库里可能生效，在你这里可能被另一个开关盖住。这不一定是抄错了，而是两条配置的作用范围本来就不同——而官方那句尾句，本身就写清了范围。
⚠️代码待验证
【两个开关的关系（按官方措辞整理）】 core.autocrlf = true -> core.eol 被忽略，工作目录用 CRLF core.autocrlf = input -> core.eol 被忽略 core.autocrlf 未设成 true 或 input -> core.eol 才起作用（官方注明默认 native） 一句话：先看 autocrlf，再看 eol。顺序反了，就会得出错误结论。配套资料：把行尾的两种形态、文件开头那段不可见标记、以及本章这两个开关的覆盖关系压成一页对照表，和本文第一到第五章一一对应。放在资料包里，扫码即可获取：
六、把这一层变成动作
6.1 三条只读动作，对应三个问题
前面几章讲的是原理，这一节把它们压成三条动作。三条全部只读，不改任何东西。
⚠️代码待验证
# 动作一：这个文件被识别成什么类型file<路径># 动作二：把不可见字符显示出来cat-A<路径># 动作三：行尾转换开关当前是什么状态gitconfig--getcore.autocrlfgitconfig--getcore.eol三条动作的顺序不是随便排的，下一节说明原因。
6.2 一次只做一个判断，顺序不能乱
先看类型，再看字符，最后看开关。
先看类型，是因为如果这个文件在系统眼里根本不算文本，那后面看行尾就没有意义——按第四章的官方结论，把它当文本处理是有风险的。
再看字符，是因为只有先确认了行尾的实际形态（一个字符还是两个字符），你才知道这份文件里到底有没有问题。
最后看开关，是因为即使确认了行尾有问题，也要先分清是"开关没设"还是"开关被另一个开关覆盖了"。前者要去改设置，后者改了也没用——这正是第五章那条官方解释。
| 你看到的现象 | 落在内容层的哪一处 | 先做哪个只读动作 |
|---|---|---|
| 同一份文件在两个系统上行为不同 | 行尾的形态（一个字符还是两个字符） | cat -A看行尾 |
| 文件末行像是少了一点东西 | 行的定义是否成立（不完整行） | cat -A看最后一行的结尾 |
| 文件开头多出看不见的字节 | 编码形态与开头那段标记 | file看它被识别成什么类型 |
| 提交之后行尾又变回原样 | 行尾转换开关，以及开关之间的覆盖 | git config --get看两个开关 |
| 图片或压缩包提交前后对不上 | 这个文件是否被误判成了文本 | file看类型，ls -l看大小 |
6.3 明确不要做的一件事
**不要一上来就改配置。**第五章那条官方尾句说得清楚：两个开关之间会互相覆盖。在没看清手里是什么文件之前动开关，等于在不知道后果的情况下触发一个不可逆的动作（第四章的官方结论）。
所以本文的动作只有三个字：**先只看。**把现象记下来，把file与cat -A的结果对着看，确认之后再决定要不要动别的东西。
七、带走物与使用限制
7.1 一页自检表
⚠️代码待验证
【行尾与编码自检表 · 只看不改】 1. 这份文件被识别成什么类型？ file <路径> 2. 行尾是一个字符还是两个字符？ cat -A <路径> 3. 末行有没有终止换行？ 看上一项动作里最后一行的结尾 4. 文件开头有没有多出看不见的字节？ file <路径> 与 cat -A <路径> 对照看 5. 行尾转换开关现在是什么状态？ git config --get core.autocrlf 6. 它有没有被另一个开关覆盖？ git config --get core.eol（对照第五章）7.2 三条可以带走的动作
- 遇到"看起来一样却行为不一样"，先做
file与cat -A这两个只读动作，再谈别的。不要一上手就去改配置、换环境。 - 记牢两个开关的顺序：先看
core.autocrlf，再看core.eol；前者为 true 或 input 时，后者被忽略。 - 在动任何行尾转换动作之前，先确认手里这份是文本还是二进制——官方自己说了，这个动作"想要的效果"和"不想要的损坏"区分不开，而且不可逆。
7.3 这份清单不覆盖什么
第一，**它只覆盖内容层。**一个路径的名字为什么在另一台机器上找不到，是名字这一层的事；一个路径到底是本体还是指向别处的名字，是身份这一层的事，本文都不涉及。
第二，**它不覆盖"怎么把行尾改过来"。**截至 2026-09-25，本文没有核到任何转换工具的官方口径，因此不给安装、不给用法，只给只读诊断动作。
第三，**它不给任何"哪个系统默认用哪种行尾"的一刀切结论。**文中所有关于两个系统行尾形态差异的表述，都只依据 Git 官方书那一句原文；超出那句原文范围的概括，本文一律不写。
第四，**本文的代码块都是只读诊断动作，本机未实测。**命令的输出会随你的文件与环境不同，所以本文一条输出都没有贴。
第五，**本文不判断"哪种行尾更好"。**行尾该用哪一种，取决于你的目标环境与协作方，本文只提供"怎么看清现状"的动作，不给"应该改成什么"的答案。
配套资料：把第五章的两个开关覆盖关系，加上本章这份自检表，合成一页可以先打印出来对着用的清单。放在资料包里，扫码即可获取：
附表 A：本文引用事实与官方出处对照表
| # | 事实（照口径） | 一手出处 | 核验日期 | 本文位置 |
|---|---|---|---|---|
| 1 | 逐字：This is because Windows uses both a carriage-return character and a linefeed character for newlines in its files, whereas macOS and Linux systems use only the linefeed character. This is a subtle but incredibly annoying fact of cross-platform work; many editors on Windows silently replace existing LF-style line endings with CRLF, or insert both line-ending characters when the user hits the enter key. | Git 官方书（8.1 Git Configuration · Formatting and Whitespace）— https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration | 2026-09-25 | 第 2 章 |
| 2 | 逐字：Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem. | 同第 1 行 | 2026-09-25 | 第 2 章 |
| 3 | core.autocrlf逐字：Setting this variable to “true” is the same as setting the text attribute to “auto” on all files and core.eol to “crlf”. Set to true if you want to have CRLF line endings in your working directory and the repository has LF line endings. This variable can be set to ‘input’, in which case no output conversion is performed. | Git 官方 git-config 文档 — https://git-scm.com/docs/git-config | 2026-09-25 | 第 5 章 |
| 4 | core.eol逐字：Sets the line ending type to use in the working directory for files that are marked as text (either by having the text attribute set, or by having text=auto and Git auto-detecting the contents as text). Alternatives are ‘lf’, ‘crlf’ and ‘native’, which uses the platform’s native line ending. The default value is native. | 同第 3 行 | 2026-09-25 | 第 5 章 |
| 5 | core.eol尾句逐字：Note that this value is ignored if core.autocrlf is set to true or input. | 同第 3 行 | 2026-09-25 | 第 5 章 |
| 6 | core.safecrlf逐字：CRLF conversion bears a slight chance of corrupting data. When it is enabled, Git will convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a mixture of LF and CRLF before the commit cannot be recreated by Git. For text files this is the right thing to do: it corrects line endings such that we have only LF line endings in the repository. But for binary files that are accidentally classified as text the conversion can corrupt data. | 同第 3 行 | 2026-09-25 | 第 4 章 |
| 7 | core.safecrlf续，逐字：Unfortunately, the desired effect of cleaning up text files with mixed line endings and the undesired effect of corrupting binary files cannot be distinguished. In both cases CRLFs are removed in an irreversible way. | 同第 3 行 | 2026-09-25 | 第 4 章 |
| 8 | 换行符定义逐字：A character that in the output stream indicates that printing should start at the beginning of the next line. It is the character designated by ‘\n’ in the C language. | POSIX 官方规范（POSIX.1-2017 第 3 章 Definitions）— https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html | 2026-09-25 | 第 2 章 |
| 9 | "行"的定义逐字：A sequence of zero or more non- characters plus a terminating character. | 同第 8 行 | 2026-09-25 | 第 2 章 |
| 10 | 不完整行定义逐字：A sequence of one or more non- characters at the end of the file. | 同第 8 行 | 2026-09-25 | 第 2 章 |
| 11 | core.autocrlf取值为 false 时的逐字口径 | 待验证：官方该条只逐字给出 true 与 input 两种取值口径，false 的逐字说明本次未取到 | 2026-09-25 | 第 5 章（待验证） |
| 12 | "哪种编码在什么情况下会在文件开头写入不可见标记"的官方逐字口径 | 待验证：本次未核到公开官方依据，正文只讲原理、不写具体结论 | 2026-09-25 | 第 3 章（待验证） |
| 13 | 各类换行符转换工具的官方口径 | 待验证：本次未核到公开官方依据，正文不给安装与用法 | 2026-09-25 | 第 3 章（待验证） |
附表 B：术语速查表
| 术语 | 一句话解释 |
|---|---|
| 内容层 | 本文口径：文件里你看不见、但它确实是文件内容的那些字符 |
| 行尾 | 一行文字结束时，文件里用来表示换行的那个或那些字符 |
| LF | 换行符，一个字符；文中 macOS 与 Linux 的形态依据为 Git 官方书那句原文 |
| CRLF | 回车符加换行符，两个字符；文中 Windows 的形态依据同上一行 |
| 终止换行符 | POSIX 官方规范给"行"下定义时，要求末尾必须具备的那个换行符 |
| 不完整行 | POSIX 官方规范给出的术语：文件末尾一段没有终止换行符的字符 |
| 字符编码 | 把字符映射成字节的一套约定；约定不同，同一段文字的字节序列不同 |
| 字节顺序标记 | 有的编码会写在文件最开头的一段不可见标记，通常缩写为 BOM |
| core.autocrlf | Git 的行尾转换开关；取 true 或 input 时，会让 core.eol 被忽略 |
| core.eol | 决定工作目录里用哪种行尾的开关；官方注明默认值为 native |
| 只读诊断 | 本文允许的动作范围：只看不改，不含任何写入、删除、安装命令 |
| 待验证 | 本文中表示"截至 2026-09-25 未核到官方依据"的标记 |
写在最后：这篇用到的资料
写这篇文章时，我把 Git 官方书、Git 官方 git-config 文档与 POSIX 官方规范里跟行尾有关的那几条对着读了一遍。同一份文件换个系统就不对，多数时候真不是逻辑问题，而是内容层那几个看不见的字符，于是顺手也整理了几份配套的东西：
- 行尾与编码自检卡：CRLF 与 LF 的两种形态、文件开头那段不可见标记、两个开关的覆盖关系
- Web 安全学习路线图：从基础打牢到安全管理，四个阶段各学什么
- 靶场环境对照表：DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径
资料是我自己整理的，放在下面这个码上，扫码即可获取：
添加时备注「靶场」，优先通过。
拿到之后建议先看行尾与编码自检卡那一份，先分清"看不见的字符"和"看得见的文字"，再决定要不要动开关。
