符號連結硬連結 Junction 差在哪?mklink 實作教學

系統需求:Windows 10 / Windows 11,且來源與目標都在 NTFS 磁碟區——官方文件是把這三種連結定義為 NTFS 檔案系統的功能。
權限需求:建立符號連結需要「建立符號連結」使用者權限(SeCreateSymbolicLinkPrivilege),預設只有 Administrators 群組擁有;硬連結與 Junction,官方文件並未列出對應的使用者權限需求。
需要工具:內建的命令提示字元(mklink)或 PowerShell(New-Item),不必安裝任何第三方軟體。
預計耗時:約 15 分鐘看完並實作三種連結各一次。
難度門檻:只要會開「以系統管理員身分執行」的命令提示字元、會打路徑就能做完。

🔍 為什麼你需要這個?

C 槽爆滿、Steam 遊戲想搬到 D 槽卻怕啟動器找不到、專案裡同一份素材被複製了七八份佔掉幾十 GB——這些情境的共同解法都是「檔案連結」:讓同一份實體資料在檔案系統裡出現在好幾個路徑上,而不是真的複製好幾份。

問題是 Windows 一口氣給了三種連結,名字又長得很像。多數中文教學直接把它們混為一談,結果讀者照著做完,遇到「跨槽失敗」「刪掉連結順便把原始資料一起刪了」才發現選錯型別。這篇把三者的能力邊界一次講清楚,並附上官方的建立與正確刪除方式——刪除方式選錯,是這個主題唯一會真的弄丟資料的地方。

順帶一提,站長先前那篇把「桌面、下載、文件」搬到 D 槽用到的就是本文的技巧;想單純壓縮系統檔省空間的人,則可以改看 CompactOS 到底能省多少。

🛠️ 實戰步驟

步驟一:先分清楚三者的能力邊界

先講結論:選哪一種,取決於你要指的是「檔案」還是「目錄」,以及要不要跨磁碟區。 依 Microsoft 官方文件,NTFS 檔案系統支援三種檔案連結:硬連結(hard link)、Junction、符號連結(symbolic link)。三者的差異如下表。

比較項目	硬連結 Hard Link	Junction(目錄連結)	符號連結 Symbolic Link
可指向的對象	只能是檔案	只能是目錄	檔案與目錄都可以
跨磁碟區	❌ 必須同一磁碟區	✅ 同一台電腦的不同本機磁碟區	✅ 可跨磁碟區,亦可用 UNC 直接指向遠端
對應網路磁碟機	❌ 不允許	❌ 不允許	✅ 可用 UNC 路徑

三點重點摘要:

硬連結是「同一份檔案的第二個名字」。官方定義是:同一個磁碟區內,由多個路徑指向單一檔案的檔案系統表示法。因此它不能指向目錄,也不能跨磁碟區——C:\dira\ethel.txt 連到 D:\dirb\lucy.txt 是不被允許的。
Junction 是目錄專用,且透過重解析點(reparse point)實作。官方允許 C:\dirx 連到 D:\diry(兩個本機磁碟區),但不允許連到對應的網路磁碟機 Z:\dir2,也不允許直接指向檔案。
符號連結最自由,代價是權限最嚴。它可以用絕對或相對路徑,相對符號連結限制在單一磁碟區內;而且它是唯一能用 UNC 路徑直接指向遠端檔案或目錄的型別。

Windows 三種檔案連結比較:硬連結、Junction、符號連結的可指向對象與跨磁碟區能力

步驟二:用 mklink 建立三種連結

mklink 是內建於命令提示字元的指令,官方語法只有一行:

mklink [[/d] | [/h] | [/j]] <link> <target>

參數只有三個,對應上表三種型別:/d 建立目錄符號連結(不加參數時預設建立的是檔案符號連結)、/h 建立硬連結、/j 建立目錄 Junction。<link> 是要產生的連結名稱,<target> 是它要指向的相對或絕對路徑。

實際操作路徑:按開始 → 輸入 cmd → 在「命令提示字元」上按右鍵 → 以系統管理員身分執行。

mklink /h C:\work\report-link.docx C:\work\report.docx
mklink /j C:\Games\Steam D:\SteamLibrary
mklink /d C:\Projects\assets D:\shared\assets
mklink C:\work\note-link.txt C:\work\note.txt

💡 為什麼要這樣做? 四行分別是硬連結、Junction、目錄符號連結、檔案符號連結。注意參數永遠寫在連結名稱前面,而且順序是「先寫要生出來的連結,後寫既有的目標」——這個順序跟 Linux 的 ln -s target link 相反,是最常見的打錯點。

如果只是要建硬連結,fsutil 也能做,參數順序與 mklink 相同,一樣是先寫要生出來的新連結、後寫既有的目標:

fsutil hardlink create C:\work\report-link.docx C:\work\report.docx

步驟三:改用 PowerShell 建立(跨版本差異要注意)

PowerShell 的 New-Item 在檔案系統磁碟機上支援五種 -ItemType:File、Directory、SymbolicLink、Junction、HardLink。

# 建立目錄 Junction:-Path 是連結、-Target 是目標
New-Item -ItemType Junction -Path 'C:\Games\Steam' -Target 'D:\SteamLibrary'

# 建立符號連結(Windows 上預設需要提升權限)
New-Item -ItemType SymbolicLink -Path 'C:\Projects\assets' -Target 'D:\shared\assets'

# 建立硬連結
New-Item -ItemType HardLink -Path 'C:\work\report-link.docx' -Target 'C:\work\report.docx'

💡 為什麼要這樣做? New-Item 的好處是能直接把結果丟進管線做驗證,缺點是版本差異比 mklink 多。官方文件明載三個門檻:PowerShell 6.2 之前符號連結的目標必須是完整路徑;PowerShell 7.1 起才能在 Windows 上用相對路徑建立指向資料夾的符號連結;PowerShell 7.4 起 -Force 才能覆寫既有的 Junction,在那之前會噴「cannot be removed because it is not empty」。

符號連結的權限問題怎麼解? 官方給的路是開發人員模式:自 Windows 10 Creators Update 起(功能首次出現在 Insider build 14972),由具備系統管理員權限的使用者先啟用「開發人員模式」之後,這台電腦上的任何使用者都能在未提升權限的命令列執行 mklink 建立符號連結。啟用位置:Windows 11 25H2 起在設定 → 系統 → 進階,往下捲到「開發人員專用」區段;25H2 之前則是獨立的「開發人員專用」設定頁。

⚠️ 微軟自己在資安文件裡把話講得很白:「建立符號連結」這項權限只應該給受信任的使用者,因為符號連結攻擊可被用來變更檔案權限、損毀或摧毀資料,甚至作為 DoS 攻擊手法。別為了省事就把這個權限發給一般使用者帳戶,開發人員模式也不建議在日常上網、收信的機器上長期開著。

步驟四:驗證結果

建立完別急著關視窗,先確認連結型別對不對:

Get-Item 'C:\Games\Steam' | Select-Object Name, LinkType, Target

LinkType 欄位會告訴你它究竟是 Junction、SymbolicLink 還是 HardLink,Target 則是它實際指到哪裡。想反查「這個檔案總共有幾個硬連結名字」,用官方的:

fsutil hardlink list C:\work\report.docx

🔬 底層機制:三種連結到底差在系統哪一層?

直接講結論:硬連結差在「目錄項目」那一層,Junction 與符號連結差在「重解析點」那一層。

硬連結沒有任何額外機制——依官方定義,硬連結就是「檔案的一筆目錄項目」,同一份檔案多了一個名字而已。所以透過任一個硬連結修改內容,其他連結立刻看得到;檔案屬性的變更也會反映到每一個硬連結上。但官方特別點出一個容易誤判的細節:目錄項目的大小與屬性資訊,只會在「你做變更的那個連結」上被明顯更新。舉例來說,你在某個硬連結上清掉唯讀旗標好把它刪掉,其他硬連結仍會顯示唯讀屬性還在,而那並不是事實。

Junction 與符號連結則不同,它們是靠重解析點(reparse point)實作的:檔案系統在解析路徑時遇到這個標記,就把路徑的前半段換成目標路徑,再把剩下的部分接上去。官方的絕對符號連結範例把這件事講得很清楚:路徑 C:\alpha\beta\absLink\gamma\file 中的 absLink 若指向 \\machineB\share,整條路徑會被改寫成 \\machineB\share\gamma\file。

要注意的是,官方對符號連結的定位是「對使用者透明」——連結看起來就像一般檔案或目錄。真正造成行為差異的不是連結本身,而是呼叫端用了哪個旗標:官方那份「符號連結對檔案系統函式的影響」逐一列出來,例如 CreateFile 指定 FILE_FLAG_OPEN_REPARSE_POINT 時拿到的是連結的控制代碼、沒指定時拿到的是目標的控制代碼。所以同一個符號連結,在不同程式手上的行為可以完全不同。

企業環境還有一道閘門:系統管理員可以用 fsutil behavior set symlinkevaluation 控制這台電腦允許哪幾種符號連結,分成本機到本機(L2L)、本機到遠端(L2R)、遠端到本機(R2L)、遠端到遠端(R2R)四類。公司電腦上 mklink 建得出來卻用不動,多半就是卡在這裡,而不是你指令打錯。

🔙 萬一翻車:回退步驟

刪除連結是這個主題唯一真的會弄丟資料的環節,務必照型別對應的方式刪。 動手前先確認兩件事:①你刪的是連結本身、不是目標資料夾;②目標資料夾裡的東西已經有另一份備份或還原點。只要不確定手上這個路徑是連結還是本體,就先跑一次步驟四的 Get-Item ... | Select LinkType, Target 再動手。

情境一:建錯了,想把連結移掉

依官方文件的示範,兩種對象用兩個不同指令:目錄型連結(目錄符號連結、Junction)用 rd,檔案型連結(檔案符號連結、硬連結)用 del。

rd C:\Projects\assets
del C:\work\report-link.docx

⚠️ 停止條件——符合任一項就先別動手:不確定該路徑是連結還是本體、目標資料夾裡的資料沒有第二份備份、該連結是安裝程式或遊戲啟動器自己建立的(先從該程式的介面移除)、或指令輸出與本文描述不符。

⚠️ 不加參數的 rd 是官方示範的做法,不要自己加上 /s。好消息是,官方 RemoveDirectory API 文件明載:移除目錄 junction 不會影響目標目錄——因為目標及其內容仍可透過自己的正規路徑存取,所以不論目標資料夾是空是滿,RemoveDirectory 都只移除那個連結。壞消息是,rd 指令文件對 /s(刪除整棵目錄樹,含所有子目錄與檔案)並未說明它遇到重解析點時的行為——官方沒定義的行為就不該拿讀者的資料去賭。所以:照官方範例用不帶參數的 rd;真的不確定手上是連結還是本體,先回步驟四查一次 LinkType 再說。

情境二:誤刪了硬連結,原始檔案還在嗎?

在。官方講得很明確:NTFS 上一個檔案可以有多個硬連結,而檔案要等到指向它的所有連結都被刪除之後,才會真正從檔案系統中移除。所以只刪掉其中一個名字,資料還在其他名字底下;把它建回來即可:

fsutil hardlink create C:\work\report-link.docx C:\work\report.docx

情境三:開發人員模式想關掉

回到上面步驟三所述的「開發人員專用」區段(25H2 起在設定 → 系統 → 進階底下),把開發人員模式開關切掉即可。官方文件只說明開發人員模式影響「建立符號連結是否需要提升權限」,關掉之後要再建新的就得回到系統管理員命令列;至於既有連結能不能被解析,官方是交給另一套機制(fsutil behavior 的 symlinkevaluation 與群組原則)管,與這個開關無關。

💡 總結:進階玩法與底層邏輯

站長我最常用的組合是這樣的:遊戲庫、模型檔、node_modules 這類「整包目錄」一律用 Junction——因為官方沒有對它設下符號連結那樣的權限門檻、也不必開開發人員模式,跨本機磁碟區同樣沒問題;只有需要指向網路位置、或需要相對路徑跟著專案走的場合才動用符號連結;硬連結則留給「同一份大檔要出現在兩個資料夾」的去重情境,例如同一份 ISO 同時要在下載區與備份區出現。

一個容易被忽略的踩雷點:「複製」與「列舉」對連結的處理方式不一樣,而官方把差異寫得很細。以符號連結為例,官方的行為對照表明載:CopyFile 遇到來源是符號連結時,實際複製的是連結的目標;要複製連結本身,得改用 CopyFileEx 並指定 COPY_FILE_COPY_SYMLINK 旗標。反過來,FindFirstFile 列舉時拿到的卻是連結本身的資訊、不是目標的。

【站長推論,非官方陳述】既然預設的複製語意是「跟著連結走到目標」,那麼用一個採 CopyFile 預設行為的工具去複製內含符號連結的資料夾,理論上就會把目標的實體資料再抄一份——備份完容量暴增,多半是這麼來的。官方文件只定義 API 行為、沒有描述檔案總管實際怎麼做,所以這段請當推論看:做備份或搬移前,自己先拿一個小資料夾試一次,確認你的工具打算怎麼處理重解析點。

最後把誠信話講在前面:本文的指令語法、權限規定、版本門檻與 API 行為逐項取自 Microsoft Learn 官方文件與 Windows 開發者部落格,屬官方事實(E3),並非站長的第一手實測;上面那段「站長我最常用的組合」是使用習慣的取捨建議,不是實測結論。文中刻意不放任何效能數字或耗時測量——連結本身幾乎不佔空間、建立也很快,但省下多少空間完全取決於你的檔案結構,任何人給你一個通用數字都該打折扣。

❓ 常見問題

Q:Junction 和目錄符號連結看起來功能一樣,到底該選哪個?

先看權限:官方對符號連結明訂了 SeCreateSymbolicLinkPrivilege,對 Junction 則未定義對應的使用者權限。再看範圍:兩者都能跨本機磁碟區,但只有符號連結能指向 UNC 網路路徑,而 Junction 官方明確不允許指向對應的網路磁碟機。所以在本機搬資料夾的情境,Junction 通常是比較省事的選擇。

Q:為什麼我的 mklink 說「您沒有足夠權限執行此作業」?

你建的是符號連結(沒加 /j 或 /h),而符號連結需要「建立符號連結」使用者權限(SeCreateSymbolicLinkPrivilege),預設只有 Administrators 群組有。三個解法:改用系統管理員身分開命令提示字元、由管理員啟用開發人員模式,或者——如果你要連的是目錄,直接改用 mklink /j。

Q:硬連結可以跨磁碟區嗎?可以指向資料夾嗎?

都不行。官方明列的不允許案例就包含「C:\dira 連到 C:\dirb」(指向目錄)與「C:\dira\ethel.txt 連到 D:\dirb\lucy.txt」(跨磁碟區)。要跨磁碟區指目錄請用 Junction,要指檔案又要跨磁碟區,只剩符號連結一途。

Q:這些連結在 exFAT 或 FAT32 隨身碟上能用嗎?

官方文件是把硬連結、Junction、符號連結三者定義為 NTFS 檔案系統的功能,微軟並未替 exFAT/FAT32 列出對應能力。實務上要用連結,就把磁碟區格式化成 NTFS——如果你正在煩惱隨身碟該格成哪種格式,可以參考站長的隨身碟格式化教學再決定。

Q:這個方法在舊版本也適用嗎?

mklink 的三個參數自 Windows Vista 時代就沒變過,官方文件同時標註適用於 Windows 10、Windows 11 與 Windows Server 2016 以後各版本。真正有版本差異的是 PowerShell 那條路(6.2 / 7.1 / 7.4 三道門檻,見步驟三)與開發人員模式(Windows 10 Creators Update 起)。舊系統若沒有開發人員模式,就回到「系統管理員命令列 + mklink」這條永遠有效的路。

🔗 延伸閱讀

📎 參考資料來源

📖 第一級|廠商官方:

mklink — Microsoft Learn — 2026-08-05 查證
Hard links and junctions — Microsoft Learn — 2026-08-05 查證
Symbolic Links — Microsoft Learn — 2026-08-05 查證
Creating Symbolic Links — Microsoft Learn — 2026-08-05 查證
fsutil hardlink — Microsoft Learn — 2026-08-05 查證
fsutil behavior — Microsoft Learn — 2026-08-05 查證
Create symbolic links(使用者權限指派)— Microsoft Learn — 2026-08-05 查證
New-Item(PowerShell 7.5)— Microsoft Learn — 2026-08-05 查證
Symlinks in Windows 10! — Windows Developer Blog — 2026-08-05 查證
Settings for developers(開發人員模式)— Microsoft Learn — 2026-08-05 查證
RemoveDirectoryW function — Microsoft Learn — 2026-08-05 查證
Symbolic Link Effects on File Systems Functions — Microsoft Learn — 2026-08-05 查證
rd / rmdir — Microsoft Learn — 2026-08-05 查證

⚠️ 本文核心事實以第一級官方文件為準;文中未引用第二級來源。

📅 本文查證戳記:2026-08-05 依 Microsoft Learn 現行文件與 PowerShell 7.5 說明整理,屬官方事實(E3),非站長第一手實測。
若你在後續版本遇到步驟失效,歡迎在留言區回報,站長會更新文章。