用硬链接｜软链接｜符号链接方便你的工作流

日常最需要区分的是这三类：

• 硬链接 hard link
• 符号链接 symbolic link / symlink / 软链接 soft link
• Windows junction 目录联接

“软链接”和“符号链接”基本是同一个东西，只是叫法不同。

硬链接 hard link

在 macOS / Linux 里，常用命令是：

ln 原文件 链接名

默认创建硬链接。

硬链接是：给同一个文件对象再起一个名字，没有谁是“原文件”，谁是“快捷方式”。

假设有：

echo "hello" > a.md
ln a.md b.md

这时：

a.md ─┐
      ├── 同一个 inode / 同一份真实数据
b.md ─┘

a.md 和 b.md 地位平等，有点像创建了两个指向相同内存的指针，删了一个不会影响另一个指针访问这块内存。而且采用的是引用计数算法，也就是如果指向这块内存的所有指针都没了，内存会被释放。这时候文件才是真的被删了。

这就是为什么硬链接不像“快捷方式”。它更像“同一份文件的多个正式名字”。

特点	说明
是否占用两份空间	不会，数据只有一份
修改一个，另一个是否变化	会
删除一个，另一个是否还在	还在，只是少了一个名字
能不能跨磁盘 / 跨文件系统	通常不能
能不能链接目录	通常不能
目标不存在时能不能创建	不能

Linux 文档明确说，硬链接不能指向目录，也不能跨文件系统；原因之一是 inode 编号只在同一个文件系统内有意义。(man7.org)

---

符号链接 / 软链接 symlink

ln -s <被指向的真实路径> <新建出来的链接路径>

本质：一个特殊文件，里面存着另一个路径。

比如：

ln -s /Users/leif/project/docs docs-link

结构是：

docs-link  →  "/Users/leif/project/docs"  →  真实 docs 目录

Linux 文档把 symbolic link 描述为一种特殊文件，内容是另一个文件的路径；它指向的是“另一个名字”，不是直接指向底层文件对象。(man7.org)

这点非常关键：

硬链接：指向文件对象
软链接：指向路径字符串

特点	说明
是否占用两份空间	不会，只存一个路径
修改目标文件	会影响真实文件
删除软链接本身	不会删除目标
删除目标文件	软链接会变成失效链接
能不能链接目录	可以
能不能跨磁盘 / 跨文件系统	可以
目标不存在时能不能创建	可以

Linux 文档也明确说，符号链接可以指向目录，也可以跨文件系统；而且它引用的路径不要求创建时就存在，不存在时就是 dangling link，也就是悬空链接 / 失效链接。(man7.org)

其他常用命令

查看链接

ls -l

你会看到：

my-project-docs -> /Users/leif/Developer/my-project/docs

读取软链接真实指向

readlink my-project-docs

删除软链接

rm my-project-docs

如果是链接到目录，注意不要写成：

rm -r my-project-docs/

更稳的是不要带结尾 /：

rm my-project-docs

MacOS / Windows / Linux 的一些其他差异

Finder 的“替身”不是 symlink

macOS Finder 里有“制作替身”。它更像 macOS GUI 层面的 alias，不等同于 Unix symlink。你的开发场景、Obsidian 场景，优先用终端的 ln -s，不要用 Finder alias。

---

Windows 上的情况

Windows / NTFS 里常见三种：

hard link
symbolic link
junction

Microsoft 文档里，mklink 命令可以创建文件/目录符号链接、硬链接和目录 junction；参数分别是 /d、/h、/j。(Microsoft Learn)

junction 是比较老的东西，现阶段可以不用。

Windows 创建命令

在 CMD 里：

mklink link.txt target.txt

创建文件 symlink。

mklink /D LinkFolder TargetFolder

创建目录 symlink。

mklink /H link.txt target.txt

创建硬链接。

mklink /J LinkFolder TargetFolder

创建 junction。

• 三者区别

类型	命令	用途
文件符号链接	mklink link target	类 Unix symlink
目录符号链接	mklink /D link target	指向目录
硬链接	mklink /H link target	同卷内文件多路径
Junction	mklink /J link target	目录联接，常用于本机目录重定向

Windows symlink 权限问题

Windows 的 symlink 以前经常需要管理员权限。Microsoft 的安全策略文档说明，创建 symlink 是一个用户权限，默认管理员组拥有该权限；也提醒 symlink 可能带来安全风险，应只授予可信用户。(Microsoft Learn)

后来的 Windows 10 开发者模式改善了这个问题。Microsoft Windows Developer Blog 说明，启用 Developer Mode 后，mklink 可以在非管理员提升的命令行里创建 symlink。(Windows Blog)

所以 Windows 上经常是：

普通用户不能创建 symlink
但可以创建 junction

这也是为什么很多 Windows 教程推荐用 junction 移动游戏目录、缓存目录、软件数据目录。

---

symlink 和 Windows 快捷方式 .lnk 的区别

Windows 快捷方式 .lnk 是 Shell 层面的快捷方式，主要给资源管理器、桌面、开始菜单用。

symlink / junction 是文件系统层面的链接。

区别很大：

项目	.lnk 快捷方式	symlink / junction
层级	GUI / Shell 层	文件系统层
命令行是否当真实路径	通常不会	通常会
程序访问	程序需要理解 .lnk	大多数程序直接当路径
适合开发工具	不适合	适合

所以开发场景不要用 .lnk 或 Finder 替身，应该用 symlink / junction。

---

高频应用场景

场景一：把外部目录挂进工作区

Obsidian 场景就是典型例子：

ln -s ~/Developer/my-project/docs ~/Documents/ObsidianVault/my-project-docs

适合：

一个真实目录
需要从另一个地方访问
不想复制
不想维护同步

场景二：dotfiles 配置管理

很多开发者会有一个 dotfiles 仓库：

~/dotfiles
├── zshrc
├── gitconfig
└── nvim

然后链接到真实配置位置：

ln -s ~/dotfiles/zshrc ~/.zshrc
ln -s ~/dotfiles/gitconfig ~/.gitconfig
ln -s ~/dotfiles/nvim ~/.config/nvim

这样配置文件可以被 Git 管理，同时系统仍然从标准位置读取。

场景三：把大目录迁移到外置硬盘或其他磁盘

例如某个缓存目录太大：

~/Library/Application Support/SomeApp/cache

可以把真实目录移走，然后在原位置放 symlink：

mv "cache" "/Volumes/External/cache"
ln -s "/Volumes/External/cache" "cache"

但这类操作要谨慎。外置盘没挂载时，链接会失效。

场景四：开发工具链和包管理器

很多包管理器、版本管理器会用 symlink。例如 Node 生态里，命令行工具、workspace 包、全局包入口经常会通过 symlink 暴露。Microsoft 也在介绍 Windows symlink 改进时提到，Git、npm 等现代开发工具会识别并保留 symlink。(Windows Blog)

你平时看到的某些：

node_modules/.bin/vite
node_modules/.bin/eslint

背后就经常和链接机制有关。

场景五：备份和去重

硬链接常用于“看起来有多份备份，实际相同文件只存一份”的场景。

粗略模型：

backup-2026-06-01/a.md
backup-2026-06-02/a.md
backup-2026-06-03/a.md

如果文件没变，可以用硬链接让多个备份目录里的 a.md 指向同一份底层数据。这样浏览起来像每天都有完整备份，但磁盘占用不会爆炸。

这也是硬链接少数非常强的用途之一。

场景六：兼容旧路径

比如某个程序只认旧路径：

/old/path/config

但你现在真实目录在：

/new/path/config

可以：

ln -s /new/path/config /old/path/config

这样旧程序不用改配置，也能访问新位置。

---