授权与合规声明
本文全部操作对象均为自建隔离靶场（本机容器或隔离虚拟机），涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款，须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离，不含任何攻击步骤、利用载荷与绕过手法，请勿将文中环境指向任何非自有系统。
一、一个具体场景：文件就在那儿，名字却对不上
1.1 排查顺序里最靠后的那一项
从别人那里拷来一个环境包，或者把一个仓库克隆到本机，照着说明敲下命令，结果它说找不到这个东西。你的第一反应通常是内容有问题：是不是哪一行写错了，是不是参数不对。第二反应是版本：是不是我这边装的是旧的。第三反应才是环境没装全。这三条都值得查，但在它们之前，还有一个更靠前、也更容易被跳过的问题：你说的那个名字，在这台机器上到底指的是哪一个东西。
名字这件事看起来没什么可怀疑的——文件明明就在那个目录里，眼睛看得见。可"看得见"本身是有条件的：你看见的是你打开的那个窗口里显示出来的样子，而命令要解析的是另一回事。
1.2 名字是解析出来的结果，不是文件本身
路径不是文件，路径是一串名字。你敲下的每一段路径，都要经过一次解析：从哪一个位置出发、经过哪几层名字、最后落到哪个对象上。这次解析发生在你按回车的那一刻，用的是那一刻的环境，而不是你以为的那个环境。所以"文件就在那儿"和"这个名字能不能落到它身上"，是两个不同的问题。
名字层上有三样东西最容易让同一条路径走出两种结果：名字里字母的大小写、路径里的分隔符与绝对相对的写法、以及你到底站在哪一个目录里敲的这条命令。本文就按这三层往下走。
1.3 本文要回答的三个问题是什么
这一篇不教你给文件改名，也不替你决定该用哪种写法——那是替你的环境拍板，做不到，也不该做。本文只回答三个问题：
- 同一个名字，为什么在两台机器上落到不同的结果？
- 绝对写法与相对写法，差别到底落在哪里？
- 为什么同一段相对路径，换一个终端就指向别处？
边界划在前面：本文只讲名字层。文件里那些你在编辑器里看不见的字符属于内容层，不在本文范围；两个路径指向同一个本体这件事属于身份层，也不在本文范围。本文同样不给任何改名、移动、写入的操作示范，四个只读动作就够用了。
二、大小写这一层：官方原文是怎么写的
2.1 Git 官方把哪些文件系统列为不区分大小写
截至 2026-09-25，Git 官方文档在core.ignoreCase这一条里，第一句是这么写的（逐字）：
Internal variable which enables various workarounds to enable Git to work better on filesystems that are not case sensitive, like APFS, HFS+, FAT, NTFS, etc.
翻成好懂的话：Git 用这个内部变量来打开若干兼容处理，好让 Git 在不区分大小写的文件系统上工作得更顺，它列举的例子里有 APFS、HFS+、FAT、NTFS 等。要强调的正是这份列举：**在不区分大小写这件事上，给出名单的是 Git 的官方文档。**这句话后面还跟着一个具体例子（逐字）：
For example, if a directory listing finds “makefile” when Git expects “Makefile”, Git will assume it is really the same file, and continue to remember it as “Makefile”.
2.2 官方举的那个例子说明了什么
例子说的是：目录里实际存在的那一项，名字全是小写的 makefile；而 Git 期待的名字是首字母大写的 Makefile。官方给的处理是，Git 会认为这两个写法指的是同一个文件，并且继续按 Makefile 这个写法把它记下来。
这里有两件事值得初学者停下来看一眼。第一，名字的"写法"和文件系统里"实际存的那串字符"可以是两回事，而解析的一方愿意把两种写法当成同一个对象。第二，"当成同一个"这个判断是替你做出来的：不是文件系统主动告诉你它们是同一个，而是 Git 在自己的逻辑里做了一次兼容。
把这个例子放回你的机器上想：如果目录里那一项叫 makefile，你敲的是 Makefile，在这类文件系统上它很可能照样跑通；可一旦这份东西被搬走、被合并、被交到另一台机器上，那个"通"就可能不再成立。
2.3 Apple 官方那一页写了什么，以及两条纪律
Apple 官方开发者文档里关于文件系统的那一页，能逐字引到的是这一句：
Apple File System replaces HFS Plus as the default file system for iOS 10.3 and later, and for macOS High Sierra and later.
它说明的是：Apple File System 取代了 HFS Plus，成为 iOS 10.3 及以后、以及 macOS High Sierra 及以后的默认文件系统。请注意，这一句讲的是"谁成了默认文件系统"，它并没有说这个文件系统区分或者不区分大小写。
由此有两条纪律必须写清楚，因为这两句经常被写串。
第一条：凡是要说 APFS 不区分大小写，出处只能落在 Git 官方那份列举上，写成"Git 官方把它列为不区分大小写的文件系统"；不要把这句话记到 Apple 名下——Apple 那一页讲的是默认文件系统，里面没有关于大小写敏感性的表述。
第二条：不要把这件事概括成一句"某个系统区分、另一个系统不区分"，再当作官方规定来用。有的文件系统不区分大小写，这话有出处；“某个平台一律如此”，截至 2026-09-25 本文没有核到逐条列举各平台默认行为的官方依据。宁可把话说小，也不要把一句话说成规则。
在自己机器上想看名字的原始写法，可以先做一个只读动作：
⚠️代码待验证
# 把当前目录里的每一项按名字逐条列出来，注意名字的原始大小写（只读）ls-la这里多出来的两个字母只是让显示更全：一个把以点开头的名字也列出来，一个多给几栏信息。这一步只看名字，不改任何东西。
三、为什么这件事对初学者是真坑
3.1 在一个地方唯一的写法，换一个地方可能有歧义
在把大小写当成同一个的文件系统上，同一个目录里不可能同时躺着 makefile 和 Makefile——你想新建第二个的时候，解析的一方会认为你要动的是第一个。于是本地看起来"很干净"：一个名字就是一项，写法唯一。可这份东西一旦进到把两种写法当成两项的环境里，那两串字符就各自有了位置：一边是一个名字，另一边可能是两个。
这就是这个坑不容易在本地显形的原因。你不是在本地遇到了问题，你是在本地没遇到问题。
| 场景 | 名字层发生了什么 | 为什么在本地看不出来 |
|---|---|---|
| 两台机器之间搬运 | 一边认为是一个名字，另一边的清单里可能变成两项 | 本地只有一个写法，不产生冲突 |
| 合并两份改动 | 两边对同一个逻辑文件用了不同写法，可能被当成两个 | 各自的副本内部都是自洽的 |
| 到别人机器上跑 | 别人的环境按另一种规则解析，你写的那串字符落到别处 | 你的机器一直替你兜着 |
| 从仓库里检出 | Git 按它建库那一刻探测到的结果来处理这些名字 | 探测结果写在仓库配置里，不写在你的命令里 |
3.2 这个判断是自动探测出来的，不是你填的
同一条文档紧接着写（逐字）：
The default is false, except git-clone or git-init will probe and set core.ignoreCase true if appropriate when the repository is created.
中文意思是：默认是 false；但在 clone 或 init 建库的时候，Git 会探测，并在合适的情况下把它设成 true。
这条信息的分量在于：它不是一份你写下的配置，而是建库那一刻替你的环境做出的判断。所以两台机器上的差异，可能在你敲第一条命令之前，就写在各自的仓库配置里了。你看到的"同样一份仓库、两个结果"，很可能在这一层就分岔——而且它不会报给你看，它只是安静地按各自的理解走下去。
3.3 知道它存在，但不要去改这个值
这条文档的末句是（逐字）：
Git relies on the proper configuration of this variable for your operating and file system. Modifying this value may result in unexpected behavior.
中文：Git 依赖这个变量在你当前的系统与文件系统上保持正确的取值；修改这个值可能导致意外行为。
官方这句话把性质讲得很清楚：它是一个让 Git 适配当前环境的内部开关，不是一个给你排障用的旋钮。所以本文的建议只有一句：知道它存在、知道它是探测出来的，但不要去改。你手动改出来的那个"通"，换一台机器、换一次检出，很可能又变成别的结果。而在那一刻，你不会再记得自己动过它。
四、第二层：分隔符与绝对相对的写法
4.1 先把一条路径拆成名字与分隔符
路径是一串字符，它由两部分交替组成：名字，以及把名字隔开的分隔符。解析一条路径，本质上就是"从某个起点开始，逐个名字往下走"。所以看一条路径，不要把它当成一个整体去认，而要把它拆开数。
分隔符的写法在不同平台上并不统一，这是跨系统搬运时会先撞上的一层差异。截至 2026-09-25，本文没有核到逐条列举各平台分隔符默认写法的官方依据，所以这里不给你一张对照表，只留一个能带走的习惯：看到路径先数分隔符，因为它决定了这条路径被拆成几段、每一段的名字是什么。
⚠️代码待验证
一条路径的拆解骨架（每一段名字，连同它前面的分隔符，分别记下来） 起点：从根开始，还是从当前位置开始 分隔符：这条路径用哪一种写法把名字隔开 名字段：第一段 / 第二段 / …… / 最后一段 末段：最后这一段才是文件名，前面每一段都是"它在哪一层"这个骨架不需要任何工具，在纸上就能做。遇到"名字对不上"时，先把路径按它抄一遍，往往在抄的过程中问题就露出来了：少了一段、多了一段，或者某一段的写法和你想的不是一回事。
4.2 绝对从根开始，相对从当前位置开始
两种写法的差别只有一处，但这一处决定了一切。
- 绝对写法：从根开始，逐个名字往下走。起点是固定的，所以它在任何地方被解析，结果都一样。
- 相对写法：从当前所在的位置开始。注意它不是从"这个文件所在的目录"开始，也不是从"你上次编辑它的地方"开始，而是从你敲下这条命令那一刻所在的位置开始。
- 还有一类以点开头的写法，读起来像"就在附近"，但它同样是从当前位置算起的：你以为的"附近"，是相对你眼睛看到的那个目录；命令算的，是它自己的工作目录。这两个不一定是同一个地方。
| 写法 | 起点是什么 | 换个位置解析，结果会变吗 | 什么时候适合用 |
|---|---|---|---|
| 绝对写法 | 文件系统里的根 | 不变 | 希望结果固定时 |
| 相对写法 | 敲命令那一刻的当前位置 | 会变 | 就在当前目录附近工作时 |
| 以点开头的写法 | 当前位置本身 | 会变 | 指当前目录或它的上一层时 |
要确认当前位置，最直接的动作只有一个：
⚠️代码待验证
# 确认此刻的工作目录是哪个，不要凭印象（只读）pwd4.3 同一段相对路径，两个终端两个结果
这是初学者最常撞上的一幕：命令一模一样，参数一模一样，只有窗口不同，结果就不同。原因往往不在命令里，而在这两个窗口各自的工作目录不同。相对写法要拿当前位置当起点去算，起点不同，落点自然不同。
这里要立一条纪律：在同一个窗口里得到的结果，不能拿去做另一个窗口的结论。想跨窗口比较，就先把两边都换成绝对写法，或者先各自确认一次当前位置，再比。把结论记进自己的环境记录时，也顺手把"在哪个入口确认的"写在同一行——不然过几天你只会记得"我确认过了"，却不知道那次确认代表哪一个窗口。
五、第三层：工作目录不是你以为的那个
5.1 三种入口，各自给你一份工作目录
工作目录是从哪来的？答案不是"从我打字的那个地方来"。它有三条来路，而这三条不一定会给你同一个答案。
- 交互式终端：它会记住你在这次会话里走到过哪里。所以你敲命令时的工作目录，是这次会话走到此刻的结果，而不是窗口刚打开时那个。
- 脚本：脚本自己不带工作目录，它用的是启动它的那个进程所给的位置。从哪个目录启动它，它就站在哪个目录。
- 从别处启动：由服务、计划任务或图形界面拉起时，启动者给你的位置往往和你手边那个窗口毫无关系。你以为"我当然在项目目录里"，它却可能站在一个完全不同的地方。
| 入口 | 工作目录从哪来 | 常见误判 |
|---|---|---|
| 交互式终端 | 本次会话里你走到过的位置 | 以为新开的窗口会回到你想要的目录 |
| 脚本 | 从启动它的那个进程继承 | 拿终端里的结果去推断脚本里的结果 |
| 从别处启动 | 由启动者给出，与你的窗口无关 | 以为自己"刚才明明就在里面" |
这三类入口各自具体把工作目录设成什么值，截至 2026-09-25，本文没有核到逐条官方依据，所以不作结论。但有一句可以确定：工作目录是给出来的，不是想出来的。
5.2 相对写法相对的是当前位置，不是文件在哪
把第四章和上一节合起来看，就能解释一个反复出现的困惑：为什么我把路径写对了，它还是落不到那个文件上？因为在相对写法里，起点是工作目录；而你在心里算起点时，用的却是"那个文件在哪儿"。两边算的不是同一件事，结果当然对不上。
要把一条相对写法变成一个不随位置变化的答案，可以用一个只读动作把它展开：
⚠️代码待验证
# 把一条相对写法展开成绝对形式，看清它此刻到底指向哪里（只读）readlink-f./example-dir/example-file这条命令不创建、不删除、不移动任何东西，它只是把答案算给你看。里面的路径请替换成你环境里真实的那一条。如果展开出来的结果和你以为的不是同一个地方，那问题就定位了：不是命令写错，是起点不同。
5.3 落到靶场上：容器里的位置要重新确认
在容器里做隔离靶场的人，容易把宿主机终端上的经验直接搬过去。但容器是一个独立的进程环境，它的工作目录由镜像与启动方式决定，跟你宿主机上那个终端站在哪里是两件事。你在宿主机上敲一串相对写法，很可能根本没有进到容器内部去解析——它就在宿主机上按宿主机的位置找了一遍。
所以做靶场时有一条朴素的做法：进到容器里之后，第一条命令只问位置，不问别的。先把当前位置确认下来，再谈路径对不对。
⚠️代码待验证
# 同一个名字的两种写法：先按相对写法看一次，再按绝对写法看一次（只读）# 两条里的路径都请替换成你环境里真实的，它们指向同一个名字ls-l./example-dir/example-filels-l/srv/example/example-dir/example-file两条的结果如果不一样，那不代表其中一个错了，而是两者各自站在不同的起点上。这类问题在容器与宿主机之间来回切时会特别多，因为两边的工作目录互不影响，也不会互相提醒。想让容器与宿主机之间有一个共同的对照点，可以把两边的当前位置各记一行，放在同一份记录里。
配套资料：把位置、名字原文写法、绝对形式、类型四栏做成一张可以照抄的自检表，放在资料包里，扫码即可获取：
六、把这一层变成四个只读动作
6.1 四个只读动作，各自回答哪一问
这一章把前面的内容收成四个动作。四个都不写、不改、不启动任何东西，所以在排查里可以放心反复做。
- 问位置：确认当前的工作目录。任何时候，只要你的路径是相对写法，这一步都该先做；它的作用是把你心里的起点换成真实的起点。
- 问落点：把相对写法展开成绝对形式。这是把"我以为"换成"它实际"的那一步；展开出来的那一条，就是一个不随位置变化的答案，可以直接抄进记录。
- 问名字：按名字把目录里的一项一项列出来。大小写、以点开头的名字，都在这一步显形。它的价值在于：你看到的不是"应该叫什么"，而是"这台机器上实际存的是什么"。
- 问类型：确认这个名字指向的东西属于哪一类。名字对不上时，这一步能排掉"其实只是类型不同"这一种可能，让你不至于在写法上绕圈。
⚠️代码待验证
# 确认这个名字指向的东西属于哪一类（只读）file./example-dir/example-file这一步不需要你先知道答案，也不需要你改动什么。它的意义在于把"这个名字到底指什么"从猜测变成一次可以复述给你自己听的确认。
6.2 从现象到动作的一张对照表
| 现象 | 先确认名字的哪一项 | 用哪个只读动作 |
|---|---|---|
| 同一个仓库，别人那里能跑，我这里查不到 | 名字在本机的实际写法 | 按名字列目录内容 |
| 同一段命令，换个窗口结果不同 | 当前位置 | 确认工作目录 |
| 路径看起来没错，就是落不到那个文件上 | 相对写法的起点与落点 | 展开成绝对形式 |
| 大小写换来换去，有时通有时不通 | 名字在本机存成哪串字符 | 按名字列目录内容 |
| 名字指向的东西和我预期不一样 | 这个名字指向的对象类型 | 确认文件类型 |
| 容器里和宿主机里表现不同 | 两边各自的工作目录 | 两边各确认一次位置 |
这张表要从左往右读：先认清现象，再确定要问名字的哪一项，最后才挑动作。顺序反了，就容易变成四处乱敲命令，敲完一堆，还是不知道哪一条与问题有关。
七、一份自检表与本文的使用限制
7.1 一份可以带走的名字层自检表
| 步骤 | 动作 | 产出 |
|---|---|---|
| 一 | 确认我在哪个目录 | 相对写法的起点 |
| 二 | 看清目录里名字的原始写法 | 名字在本机的真实字符 |
| 三 | 把关键路径展开成绝对形式 | 一条不随位置变化的写法 |
| 四 | 确认名字指向的对象类型 | 排掉类型不同这一种可能 |
| 五 | 换一个入口时，重复第一步 | 两边各自的起点 |
| 六 | 把结论写进自己的环境记录 | 名字、写法、确认位置、确认日期 |
这张表不长，但它的每一步都不改任何东西，所以不怕越查越乱。真正会让人绕圈的，往往是跳过第一步直接改名字——改完之后现象消失了，可你还不知道为什么，下次换个入口它再来一次。
7.2 三条可以带走的习惯动作
- 启动或引用时优先用绝对写法。相对写法省事，但它的答案取决于你站在哪里。你希望结果固定的地方，就用一个不随位置变化的写法，这比事后排查便宜得多。
- 换入口就重新确认一次位置。终端、脚本、容器、别人的机器，各算各的。一边确认过的结果，不要搬到另一边当结论用。
- 遇到名字对不上，先看名字，再看内容。把"是不是文件写错了"这条怀疑往后放一放，先用四个只读动作把名字这一层问清楚，再决定要不要往内容层查。
7.3 本文的使用限制与待验证条目
- 官方事实：不区分大小写的文件系统名单、makefile 与 Makefile 那个例子、“这个变量默认是探测出来的"以及"修改这个值可能导致意外行为”，都出自 Git 官方文档的同一条目；APFS 成为 macOS 默认文件系统的表述出自 Apple 官方开发者文档。核验日期均为 2026-09-25。
- 本文的方法：四个只读动作、两条纪律、两张对照表与一份自检表，是本文从上述官方事实里整理的排查方法，官方文档并没有把它们写成一套固定流程。
- 待验证条目（本文未实测，不得当作结论使用）：各平台路径分隔符的默认写法，截至 2026-09-25 未核到官方依据；交互式终端、脚本与从别处启动这三类入口各自把工作目录设成什么值，截至 2026-09-25 未核到逐条官方依据；容器工作目录由镜像与启动方式决定的具体规则，本文未实测；这四条只读命令在不同 shell 上的具体回显格式，本文未实测。
- 本文不给的结论：不判断你该用哪一种写法，不建议你修改任何与大小写有关的配置，也不涉及任何非自有的环境。
把自检表做成一页可以打印的对照表，动手之前先过一遍：
配套资料：把名字层自检表与环境记录栏位做成一张可打印的对照表，放在资料包里，扫码即可获取：
附表 A：本文引用事实与官方出处对照表
| # | 事实（照口径） | 一手出处 | 核验日期 | 本文位置 |
|---|---|---|---|---|
| 1 | filesystems that are not case sensitive, like APFS, HFS+, FAT, NTFS, etc. ——Git 官方把 APFS、HFS+、FAT、NTFS 等明确列为不区分大小写的文件系统 | Git 官方文档 git-config，core.ignoreCase 条目：https://git-scm.com/docs/git-config | 2026-09-25 | 第 2 章 |
| 2 | For example, if a directory listing finds “makefile” when Git expects “Makefile”, Git will assume it is really the same file, and continue to remember it as “Makefile”. | 同第 1 行 | 2026-09-25 | 第 2、3 章 |
| 3 | The default is false, except git-clone or git-init will probe and set core.ignoreCase true if appropriate when the repository is created. | 同第 1 行 | 2026-09-25 | 第 3 章 |
| 4 | Git relies on the proper configuration of this variable for your operating and file system. Modifying this value may result in unexpected behavior. | 同第 1 行 | 2026-09-25 | 第 3 章 |
| 5 | Apple File System replaces HFS Plus as the default file system for iOS 10.3 and later, and for macOS High Sierra and later. | Apple 官方开发者文档，About Apple File System 页：https://developer.apple.com/documentation/foundation/file_system/about_apple_file_system | 2026-09-25 | 第 2 章 |
说明：第 1 至 4 行出自 Git 官方同一份文档的相邻条目，照其口径引用，未改写成更顺口的版本；第 5 行出自 Apple 官方开发者文档，本文只用它佐证 macOS 的默认文件系统是 Apple File System，不用它推断大小写敏感性——凡是"不区分大小写"的表述，出处一律是第 1 行。凡带时间属性的表述，本文统一锚定为截至 2026-09-25。
附表 B：术语速查表
| 术语 | 一句话解释 |
|---|---|
| 名字层 | 本文的轴：路径里的名字怎么被解析，哪些差异会让同一个名字走到不同结果 |
| 解析 | 从某个起点出发、逐个名字往下走，最后落到某个对象上的过程 |
| 大小写敏感 | 同一串字符换一种大小写写法，被当作两个不同的名字 |
| 不区分大小写的文件系统 | Git 官方文档列举的那一类文件系统，名单含 APFS、HFS+、FAT、NTFS 等 |
| 探测 | 建库时 Git 自己判断该不该打开兼容处理的动作，不是人填的 |
| 分隔符 | 把路径里的名字隔开的那类字符；看路径先数它，就知道名字被分成几段 |
| 绝对写法 | 从根开始写的路径，起点固定，换地方解析结果不变 |
| 相对写法 | 从当前所在位置开始写的路径，起点随位置变，结果也跟着变 |
| 以点开头的写法 | 从当前位置本身算起的相对写法，看着像就在附近，其实仍取决于工作目录 |
| 工作目录 | 敲下命令那一刻所处的目录；它是被继承或设定的，不是想出来的 |
| 只读动作 | 只看不改的诊断动作，本文四个动作都属于这一类 |
| 环境记录 | 记下名字、写法、确认位置与日期的自查记录，换入口就多记一行 |
| 截至 2026-09-25 | 本文对所有时间类表述的统一锚定日期 |
写在最后：这篇用到的资料
写这篇文章时，我把 Git 官方文档里关于大小写那一条的原文逐句读了一遍，又对着 Apple 官方开发者文档核了默认文件系统那句话，发现这一层真正能落地成动作的东西其实只有四个只读动作。于是顺手整理了几份配套资料：
- 路径名字自检表：位置、名字原文、绝对形式、类型四栏，遇到名字对不上先过一遍
- 靶场环境记录模板：名字、写法、确认位置、确认日期四栏，换一个入口就多记一行
- Web 安全学习路线图：从基础打牢到安全管理，四个阶段各学什么
资料是我自己整理的，放在下面这个码上，扫码即可获取：
添加时备注「靶场」，优先通过。
拿到之后建议先看路径名字自检表那一份，把自己最常用的那几个路径先确认一遍，再动手装环境。
