Markdown 粗體、斜體與刪除線：完整強調語法

用一個星號寫斜體

把符號從兩個減成一個就是斜體，兩種字元一樣都可以用：

請先看完*整份*更新日誌。
請先看完_整份_更新日誌。

輸出是 <em>，意思是「語氣上的強調」，也就是你唸出來會加重的那個詞。

斜體該用在哪、不該用在哪

部分螢幕閱讀器設定會把 <em> 讀出來，所以請留給真正有語氣的文字。書名、外文詞與介面名稱是另一回事：

• 真的要加重語氣：用 *星號*。
• 書名或片名：原始 HTML 的 <cite> 才表達得準確。
• 正在下定義的術語：用斜體沒問題，讀者也習慣。
• 按鈕或選單名稱：純文字或 <i> 比強調合適。

符號的建議同樣是優先用 *。滿篇 _斜體_ 的檔案，只要貼進一個 Python 變數名稱就會出事。

粗斜體、巢狀、連結與標題

三個符號可以同時得到粗體與斜體，而混用兩種字元是最好讀的寫法：

***又粗又斜***
___又粗又斜___
**_又粗又斜_**

三種都渲染成粗斜體。最後一種值得養成習慣，因為 ***字*** 在 diff 裡真的很難一眼數清楚有幾個星號。

把強調套在強調裡面

只要內外層的符號不同，強調就可以巢狀：

**警告：*不要*重新啟動服務。**
*大致是斜體的一行，其中有一個**粗體**詞。*

內外層用同一種字元不會照你想的方式運作。*外層 *內層* 外層* 會讓解析器把前兩組配成一對，結果一團亂。請交替使用兩種字元，或在星號組裡面放底線組。

放在連結與標題裡

強調可以寫在連結文字裡，也可以包住整個連結：

[**下載安裝程式**](https://example.com/setup.exe)
**[下載安裝程式](https://example.com/setup.exe)**

兩種都會變粗體。第一種把符號留在連結內部，之後改網址時比較乾淨，其餘連結語法請見連結參考。

粗體不等於標題

標題裡的強調會正常渲染，但在產生錨點 ID 時會被剝掉，所以 ## The **important** part 得到的是 #the-important-part，完整的 ID 規則在標題參考。

請不要用粗體代替標題。粗體那一行產生不出大綱條目、沒有錨點，目錄產生器也找不到它。

用兩個波浪號寫刪除線

兩側各放兩個波浪號，文字上就會畫一條線：

~~週五出貨~~ 改成週一出貨。

它渲染成 <del>，語意是「被刪除的內容」，所以用在改過的價格、完成的待辦或被取代的日期上都讀得通。

哪裡能用、要放幾個波浪號

刪除線不屬於原始 Markdown，也不在 CommonMark 核心裡，它是以 GFM 延伸語法的身分出現的，所以數量依平台而異：

• 兩個波浪號：GitHub、GitLab、Discord、Reddit、Obsidian、Notion 與多數筆記軟體。
• 一個波浪號：GFM 也接受，而 Slack 剛好只用一個。
• 兩種都不行：嚴格的 CommonMark 渲染器會把波浪號原樣印出來。

在沒有這個延伸語法的地方，只要允許行內 HTML，<del>文字</del> 到哪都有效。

螢光標記、底線、上標與下標

螢光標記

==螢光標記== 不是標準 Markdown。它在 Obsidian、Typora，以及啟用 pymdownx.mark 的 MkDocs Material 上有效，GitHub 則會把等號原樣印出來。通用的寫法是 <mark>螢光標記</mark>。

底線

Markdown 沒有底線語法，而且是刻意不做的：在網頁上底線代表連結，替一般文字加底線會誤導讀者。

真的需要時就用 <u>文字</u>；若是標示「新增的修訂」，<ins>文字</ins> 更合適。Discord 是那個常害人踩雷的例外，因為它把 __文字__ 讀成底線，而其他工具都讀成粗體。

上標與下標

<sup> 與 <sub> 是最可靠的做法，在 GitHub 上也有效。Pandoc 與部分 markdown-it 設定另外提供 ^文字^ 與 ~文字~，但下標寫法會跟單一波浪號的刪除線打架，共用的檔案裡最好避開。

E = mc<sup>2</sup>，還有 H<sub>2</sub>O

所有強調語法與支援範圍

下表列出每一種符號、它產生的 HTML，以及看得懂它的平台。

中日韓文字的強調問題

最常聽到的抱怨是 **粗體** 有時候不會生效。這不是字型問題，也不是編輯器有 bug，而是 CommonMark 的一條規則遇上了全形標點。

單純的中文粗體沒問題

簡單的情況在任何現代 CommonMark 或 GFM 解析器上都正常，整行完全不留空格也可以：

這是**粗體**文字   -> 正常變粗體

加了引號為什麼就失敗

CommonMark 是看符號兩側各是什麼字元，來決定它能不能開啟或結束強調。「內側是標點、外側是文字」的組合，兩件事都不准做。全形引號正是標點，所以會變成這樣：

他說**「這樣」**才對    -> 星號原樣印出來
他說「**這樣**」才對    -> 正常變粗體

這兩行在編輯器裡幾乎看不出差別，變的只有引號的位置，而這就是「粗體正常」與「四個星號裸奔」之間的全部差距。

三種修法，由好到差

1. 把標點移到符號外面。寫 「**這樣**」，不要寫 **「這樣」**。其他什麼都不用改，句子讀起來也一樣。
2. 在開頭符號前加一個空格。有效，但會改變中文句子的間距，多數編輯台不會接受。
3. 退回原始 HTML。只要允許行內 HTML，<strong>「這樣」</strong> 永遠有效。

中文用底線失敗的機率更高

有些引擎把中日韓文字當成單字字元，於是 __粗體__ 緊貼著前後文時，就被看成單字中間的強調，而底線本來就不准這樣做。比較舊的中文部落格系統是常見的犯人。

注意：最保險的組合是「用 ** ＋ 標點放在符號外面 ＋ 發佈前先預覽」。本站編輯器渲染中文的方式與 GitHub 一致，你看到的就是讀者看到的。用中文寫作的人也會想順便看一下連結參考裡的全形括號陷阱，那是同一個問題換了一個元素。

常見錯誤與修正寫法

幾乎所有渲染不出來的強調，都出在這六個錯誤：

1. 符號內側有空格，符號因此無法開啟或結束。
2. 在單字中間用底線，CommonMark 根本不視為強調。
3. 符號數量不對稱，星號留在畫面上。
4. 用粗體代替標題，沒有大綱條目也沒有錨點。
5. 在不支援延伸語法的地方用刪除線。
6. 讓強調去做結構的工作，結果什麼都沒突顯。

空格與不對稱的符號

錯誤寫法與正確寫法：

** 重要 **通知

**重要**通知

兩個開頭符號配一個結尾符號，星號會留在畫面上，而且常常把後面整句一起吃掉。錯誤寫法與正確寫法：

**注意：API key *是必填的。

**注意：**API key *是*必填的。

在單字中間用底線

什麼都不會發生，因為底線無法在單字中間開啟強調。錯誤寫法，以及改用星號的正確寫法：

re_start_ the service

re*start* the service

該用標題的地方用了粗體

粗體那一行看起來像標題，行為上卻什麼也不是。錯誤寫法與正確寫法：

**設定**

### 設定

用強調代替結構

一段裡放六個粗體片語，等於什麼都沒強調。一個概念挑一個詞加粗；內容真的是條列就用清單，真的是引述就用引言區塊。

刪除線也屬於同一類問題。如果波浪號原樣印出來，那個渲染器就是純 CommonMark，改用 <del>已取代</del>，或先查GFM 參考確認平台支援哪些語法。

強調怎麼都不生效時的除錯法

把那一行貼進編輯器，一個字元一個字元刪到它正常為止，元凶幾乎都是一個空格或一個沒配對的符號。

語法速查表把這些全部濃縮在一頁，Markdown 完整指南把強調放回其他元素之間，Markdown 是什麼則解釋了這個格式為何堅持讓格式標記本身也保持好讀。