引言
超鏈接是互聯網最突出的功能之一，添加超鏈接也是所有網絡用戶需要掌握的基本功。
然而，「會用」超鏈接并不等于能「用好」超鏈接。或許是因為操作太過容易，我們在添加超鏈接的時候往往頗為隨意，而不會仔細考慮做成超鏈接的內容和地址是否合理。
回想一下，你是否遇到過下面這樣的超鏈接用法，或者自己這樣用過：
- 將操作指示作為鏈接文本：「點擊這里」「查看相關信息」「」
- 將網址作為鏈接文本：http://example.com/
- 為連續的詞語添加超鏈接作為列舉手段：「蘋果在過去幾個月和開發者可謂 沖 突 不 斷。」
- 將一長串話作為鏈接文本。
這些用法都是值得商榷的。
超鏈接的正確用法并不是個新話題。早在 2004 年，谷歌工程師 Jed Hartman 就撰文討論過鏈接文本的合理用法；上面列舉的幾種不當用例正是來源于該文。
一些開發文檔也涉及了這個問題。谷歌的《開發文檔風格指南》（Developer Documentation Style Guide）就為此專設一節，并指出鏈接文本應該「描述讀者點擊鏈接后將會看到的內容」，如被引文檔的標題或對其內容的描述。Mozilla 維護的 MDN 文檔庫也討論了「鏈接最佳實踐」（link best practices），同樣建議回避上述幾種做法。
但正如我們所見，時至今日，超鏈接的使用在實踐中仍然是很隨意的；不少網站超鏈接的外觀設計也往往不盡人意。
為此，我想從鏈接文本和鏈接地址的選擇、鏈接外觀的設計等方面，討論自己認為較優的用法，希望能為超鏈接的規范使用提供一些參考。
鏈接文本的選擇——追求「名副其實」
從 html 標準看鏈接文本的要求
要回答鏈接文本如何設置，首先要從什么是超鏈接說起。
根據 HTML 標準，超鏈接是「指向其他資源的鏈接，通常由用戶代理（一般即為瀏覽器——筆者注）展示給用戶，使用戶可以令用戶代理導航到這些資源」。
此外，超鏈接通常是通過「錨」（anchor）元素（a）構造的；當一個錨元素含有 href 屬性時，該元素就代表一個由其內容標記（label）的超鏈接。
這些定義固然晦澀，但我們仍然可以從中得出一些有用結論：
- HTML 元素是有「語義」（semantics）、也即內在含義的。例如，錨元素的存在就說明「此處有鏈接，點擊可跳轉到相關信息」。
- 錨元素的內容（即鏈接文本）和其 href 屬性（即鏈接地址）之間是標記和被標記的關系。換言之，鏈接文本要「名副其實」，能夠說明鏈接地址的內容。
在此基礎上，我們就可以說明為什么前面提到的幾種「流行」用法是有待商榷的：
第一種用法（將操作指示作為鏈接文本）的主要問題在于贅余。既然錨元素的存在本身就說明有鏈接、可點擊，再加入「點擊」「更多」之類的描述，就好像是在說「這是一個有鏈接的鏈接」一樣，成了同義反復。
早年，并非人人都「認識」超鏈接，這么寫或許還有些教育用戶的意義，但這在今天已經不是個問題了。此外，這樣的鏈接文本也無法說明被鏈接的內容。因此，不妨刪去「點擊」「更多」，代之對被引內容的說明：
要進一步了解某話題，可以參閱某文章。
第二種用法（將網址作為鏈接文本）同樣會讓讀者無從知曉其內容。此外，從排版角度，冗長的網址也會給斷行、對齊的處理造成不便，影響版面的整潔度。因此，更好的做法仍然是描述鏈接地址的內容，而不是直接把地址寫進正文（當然，因行文需要展示鏈接地址的場合除外）。
第三種用法（將超鏈接的連用作為列舉手段）可謂有利有弊。一方面，這么做確實具有一定「修辭」功能，可以傳達俏皮、諷刺等意味。但正如那些被濫用的「梗」一樣，其新意和趣味會隨著反復使用而磨損，最終引起讀者的厭倦；這么做也違反了「名副其實」的原則，給閱讀造成不便。因此，最好還是把「文采」留給別處，用更清晰的方式來列舉超鏈接。
例如，與其使用上述那種抖機靈寫法：「蘋果在過去幾個月和開發者可謂 沖 突 不 斷」，不如原原本本地把具體內容呈現給讀者：
蘋果在過去幾個月和開發者可謂沖突不斷，先后拒收了電郵服務 Hey 的官方 App、下架了人氣游戲 Fortnite、強迫 wordPress/ target=_blank class=infotextkey>WordPress 通過內購銷售域名，并「言而有信」地關停了 Epic 的開發者賬號。
第四種用法（鏈接文本過長）是否不值得鼓勵，現有討論并未達成共識，但我的觀點仍然是應該盡量避免。理由是，如果鏈接文本很長，它很可能是在摘錄或描述被引內容的局部，而非全文；如果給這樣的局部引用加上指向原文整體的超鏈接，不僅不具有對應關系，也不便于讀者跳轉之后找到相關段落。
因此，更好的做法是把鏈接加在文章標題上（同時說明被引段落的位置），然后用普通文本做摘錄和總結：
根據某文章 [某節] 的觀點，「……」。
另外，不合規范的鏈接用法還會產生一些較為間接、但同樣不容忽視的負面影響。例如，這會降低網頁的可訪問性（accessibility），給依賴于讀屏器的用戶造成不便，使他們很難通過聽到的鏈接文本判斷目標頁面的內容（參見不同讀屏器對于鏈接文本的處理方式）。又如，搜索引擎在索引網站時，常常通過鏈接來判斷網站的關鍵詞。如果一個網站的鏈接文本都是「跑題」的，它給搜索引擎的「印象分」就會大打折扣，導致搜索排名降低。
先問「加不加」，再問「加在哪」
從上文的討論可以看出，要修正超鏈接的「問題用法」，只靠給鏈接換個位置可能是不夠的，往往還需要調整甚至重寫相關表述。
這是因為，超鏈接的質量間接反映了寫作的質量：如果你發現難以從文本中找出合適的部分做成鏈接，那么很可能是因為行文表述不夠具體、充分，信息標注不夠明確、規范。
這里，超鏈接的便捷再次埋下了隱患。過去，我們用括號、腳注提示相關信息，用引注、參考文獻表明內容來源。到了面向網頁的寫作中，這些傳統注記方式的職能在很大程度上被超鏈接包攬了。但與此同時，那些原本需要研究、檢索支撐的工作，被簡化成了復制粘貼網址；原本寫成白紙黑字、受讀者審視的引文，被藏到了鏈接背后。在方便的同時，這也為我們提供了「縱容」自己降低寫作標準、濫用超鏈接的借口。
因此，比起「在哪里添加超鏈接」，一個更優先的問題或許還是「要不要添加超鏈接」。
如果文章討論的話題線索復雜、眾說紛紜，那么我們就有責任先梳理、溯源，篩選出盡可能一手、高質量的來源做成鏈接，而不是將大把鏈接一股腦塞給讀者，同時產生「內容充實」的良好自我感覺。如果被引文章篇幅較長、內容艱深，或與當前段落的關系并不一目了然，那么我們也有責任作出必要的標注和解釋，而不是拋出一個超鏈接，讓讀者自己點開「細品」「領悟」。
例如，前段時間，美國國會召集四大科技公司 CEO 的反壟斷聽證會受到了媒體的廣泛關注（可參閱我介紹此事的文章）。不少報道在行文中提及了微軟 20 年前受到的司法部指控，以此介紹美國法院的反壟斷判案標準。
這個案例引用當然是切題的，但到了為其添加超鏈接時，很多文章就頗為隨意，一般都選擇鏈接到自己網站的其他文章，或是當年的媒體報道。然而，這并不符合前面介紹的「名副其實」原則（最相關的文件應當是判決書，或至少是對判決結果的報道），也不足以使讀者了解判決邏輯是什么、從何而來。
實際上，如果遵循法律引注的要求，提及判例應當附上相關案件的完整索引信息和必要的解釋說明：
United States v. Microsoft Corp., 253 F.3d 34, 59 (D.C. Cir. 2001) (holding that a balancing approach under the rubric of the “rule of reason” is applied for the analysis under §2 of the Sherman Act).
這樣，讀者不僅能了解案件的當事方（聯邦政府訴微軟公司）、審理的時間地點（2001 年由聯邦法院哥倫比亞特區巡回法庭審理），主要的判決理由（法院可以通過衡量利弊判斷壟斷行為是否合法），而且如有興趣進一步探究，還可以自己找到判決原文閱讀（《聯邦案例匯編》第三輯第 253 卷，第 34 頁以下，相關段落位于第 59 頁）。
誠然，出于效率和簡潔的考慮，網上寫作沒有必要像學術寫作那樣一板一眼地遵循引注規范（Bluebook 等引注標準確實也因為繁瑣、封閉而頗受詬病）。但功夫有時需要下在那些看不見的地方；如果下筆前對寫作對象做了充分的研究，寫作時做了充分的說明和標注，「超鏈接加在哪」幾乎不會是個問題。
鏈接地址的選擇——精簡而不失具體
要做出好的超鏈接，除了關注鏈接文本的選擇，鏈接地址的規范性也不應忽視。
一方面，做成超鏈接的地址應當盡量精簡，即在不影響鏈接功能的前提下，包含盡量少的無關信息。直接從瀏覽器地址欄復制的 URL 未必適合直接拿來做成鏈接，因為其中可能包含了很多無關的參數（parameter）。
例如，搜索結果頁和郵件通訊中很多 URL 都含有 utm_source 等用于流量分析的參數：
https://example.com?utm_source=news4&utm_medium=email&utm_campaign=spring-summer
將其留在超鏈接中不僅沒有實際功能，而且不利于保護讀者的隱私。
又如，在插入商品銷售頁的鏈接時，應當從中刪除無關的引薦代碼（affiliate token）；如果要加入自己的引薦代碼，則應當作出明確披露。
另一方面，鏈接地址又應當足夠具體，即盡可能精準定位到相關資源。如果引述的內容集中于文章的某一節，那么插入的 URL 最好具體到片段（fragment）。
例如，如果撰文討論常見的網頁標準，那么在插入相關維基詞條的鏈接時，就可以具體到：
https://en.wikipedia.org/wiki/Web_standards#Common_usage
這樣，讀者在點擊后就可以直接跳轉到其中最相關的「Common Usage」一節。
類似地，如果文章涉及 GitHub 代碼或 YouTube 視頻，也不妨利用它們為特定行號或時間戳創建鏈接的功能。
前不久，谷歌還為 Chrome 瀏覽器開發了一個名為「鏈接到文本片段」（Link to Text Fragment）的插件，可以幫助用戶制作出指向頁面上任意文本的鏈接。遺憾的是，這個插件背后的標準仍處于早期草案階段。在它被廣泛采納之前，更務實的做法或許還是像上文建議的那樣，不怕啰嗦地向讀者盡量具體描述引文的位置。
鏈接外觀的設計——平衡謹慎與活潑
最后，超鏈接的質量并不只取決于文章作者；網站的設計者對此也有一份責任，那就是合理地設計超鏈接的外觀。
傳統網頁中的超鏈接是其貌不揚的，始終以藍色文字加下劃線的形態示人。但在近年，給鏈接文本加粗、添加夸張的下劃線、換用高飽和度的顏色似乎蔚然成風；超鏈接儼然成了很多網站彰顯個性的秀場。
Vox 的超鏈接；彩色粗體的設計在鏈接密集時讓版面不整潔且缺乏層次
然而，網頁元素的外觀應該與其功能相匹配。正如前文反復強調的，超鏈接只能說明鏈接文本存在一個關聯頁面，而不能說明它相對于上下文更加重要。因此，也就沒有理由使其在視覺上過分突出。此外，過度設計超鏈接還會進一步放大前述濫用行為的危害，讓版面效果變得凌亂而沒有層次。
當然，這并不是說超鏈接的設計就只能是死氣沉沉的。我就曾見過不少既恰如其分、又不失新意的超鏈接設計。試舉兩例：
一是排版設計師 Matthew Butterick 的 Butterick’s Practical Typography 網站。這個網站實際是一本電子書，深入淺出地講解了很多實用的排版技巧和關注點。它的設計拋棄了「下劃線 = 超鏈接」的傳統做法，轉而通過 css 的 :after 在每個超鏈接之后加上一個小紅圈，同時鏈接文本會在鼠標懸停時被淡紅底色高亮。這樣的設計既降低了侵略感，又保留了視覺提示功能，與中國傳統的「圈點」批注有著微妙的相似。
Practical Typography 的鏈接設計
二是軟件工程師 Jestem Króliczkiem 的個人博客 beepb00p。作為一個技術向、長篇說明文為主的博客，它的設計亮點在于為常用的外部網站（例如 GitHub、維基百科等）的鏈接添加了 SVG 圖標，并為跳轉到文內其他段落的鏈接添加了上下箭頭。這些圖標的加入不僅使鏈接對象一目了然，也給原本「素面朝天」的文本頁面平添了幾分趣味。
beepb00p 的鏈接設計
結語
你可能已經注意到，本文在討論各種鏈接用法時，一直回避使用「正確」「錯誤」等定性的標簽，而代之以「合適」「更好」等評價。的確，超鏈接的用法和設計并沒有成文的標準，而更多是一種「風格」（style）。既然是風格，就沒有絕對的對錯之分，而是會隨著時代、技術、觀念等外部因素而變，并且體現著不同寫作者、設計者的個性。
然而，隨性不等于隨意。從小處說，鏈接的質量體現了作者的態度，反映了文章的質量。往大處說，互聯網是由超鏈接織成的，它的價值也很大程度上取決于超鏈接的廣度、深度和精度。在筑籬修渠成為科技巨頭的發展要務、互聯網的開放價值備受威脅的今天，用高質量的超鏈接拓展信息的邊界，或許就是我們作為普通用戶守護互聯網為數不多的方式之一。
