提示面板的z-index已經設到9999，仍被另一個區塊蓋住，先看它的父層是否建立了獨立的堆疊情境。子元素的數字只能參與所在情境裡的排序，不能直接拿9999跨過另一個父層。把數字繼續加大，通常改不了這個關係。
這個問題容易出現在卡片上的選單、側欄提示或固定工具列。你看到的是兩個子元素重疊，瀏覽器比較的卻可能是各自的父層。本文用兩個相交區塊觀察前後順序，再把排查重點放在真正建立層級的元素上。
先看一組能重現的例子
<div class="panel">
<div class="child">提示面板</div>
</div>
<div class="neighbor">相鄰區塊</div>.panel {
position: absolute;
left: 40px;
top: 40px;
width: 240px;
height: 180px;
z-index: 1;
}
.child {
position: absolute;
inset: 20px;
z-index: 9999;
}
.neighbor {
position: absolute;
left: 100px;
top: 100px;
width: 240px;
height: 180px;
z-index: 2;
}為了看清結果，可給三個元素不同背景色。在交疊的區域，neighbor會蓋在child上面。panel與neighbor在同一外層情境裡按1與2排序，child即使是9999，仍跟著panel這個整體處在較低的順序。
把它想成兩個獨立資料夾：其中一個文件排在自己資料夾最上面，不代表整個資料夾就排到另一個前面。這個比喻只幫你理解父子排序，真正要修的仍是CSS建立的堆疊情境，不是元素在畫面上看起來有多高。
實測改的是父層，不是子層數字
在Chromium154的合成頁面裡，父panel為1、neighbor為2時，交疊點的最上層元素是neighbor。把panel改成3、child仍保持9999後，同一點就命中child。沒有把子層改成更大的數字，前後順序也改變了。
console.log(document.elementFromPoint(150, 150)?.className);
document.querySelector('.panel').style.zIndex = '3';
console.log(document.elementFromPoint(150, 150)?.className);elementFromPoint可幫助確認某個視窗座標上命中的元素，但它也受pointer-events等因素影響，不能一概當成所有視覺遮擋的唯一判斷。這組示範沒有加入那種設定，所以結果能和實際畫面前後順序對照。你自己的頁面若有透明覆蓋層，還要一起查命中規則。
此例中的150,150是固定測試座標，不是通用的網站檢查點。正式排版有不同大小、捲動位置和容器，應在真正相交的位置檢查，並保留對應畫面。不要把一次命中結果套到整個網站的所有浮層。
往上查哪些元素建立了情境
position配上非auto的z-index，是這個例子建立情境的原因。其他CSS也可能建立自己的情境，例如transform、某些opacity值或isolation。排查時從提示元素往祖先查，看看哪一層開始讓它的排序和外部元素分開。
用開發者工具查看計算樣式，而不只看你剛寫的那份CSS。模板、元件和動畫可能都給同一元素設定屬性，最後生效的結果未必與你以為的一樣。像為了動畫加上的transform，也可能讓一個原本能蓋過鄰區的子元素出現不同堆疊關係。
z-index也不是對所有元素都以相同方式生效。普通未定位元素和定位元素、flex或grid項目的規則需要分清。看到計算值不是auto，不代表你就能按全頁最大數字排序；應結合元素佈局與它所屬的情境判斷。
調整父層前，先看影響範圍
在最小示範中把panel改成3很容易，但實際網站可能讓整個panel包含圖片、文字、按鈕和其他提示。提升父層等於提升這整個區塊，不只你要顯示的child。它可能又蓋住導覽或相鄰內容，所以修正要觀察整塊區域。
如果浮層應該越過當前元件邊界，可以評估把它放到較合適的DOM層級，讓它與需要比較的元素處於同一情境。這往往涉及定位、焦點和事件關係，不能只移走HTML就當完成。先在測試版型確認開啟、關閉與定位都符合原功能。
使用框架的浮層工具時，也要查它如何處理這些關係。有些工具會把浮層放到另一個容器，有些則留在原元件內部。選擇方式應依你的功能，不需要為了一個提示面板重寫整套版型。
裁切問題和堆疊問題分開查
如果面板是在父容器邊緣整齊被切掉，還要看overflow等裁切規則。堆疊順序提高不一定能越過裁切邊界。相反，若面板完整存在，只是在相交區域被別的元素蓋住，才更像這篇示範的排序問題。
先區分這兩種現象，可以避免一邊改z-index、一邊改overflow，最後不知道哪一項修好了問題。測試時一次只改一個影響因素，保留修改前後畫面。若移除裁切會讓整張卡片的圓角或捲動行為變差，就要尋找符合元件用途的處理方式。
瀏覽器的頂層機制也有自己的規則，例如某些原生對話框。它不是把普通元素的z-index設成更高就能完全模仿。因此不要把這個兩區塊案例擴成所有彈窗的通用解法；先知道你用的是哪種浮層，再按對應機制處理。
保留少量清楚的層級
修好後，讓層級數字對應明確用途，例如內容、局部選單與固定導覽，而不是每發現一次遮擋就增加一個零。數字無上限地增長，會讓後續元件更難理解，也容易掩蓋真正的父層情境。
這不需要一開始設計一張涵蓋全站所有元素的複雜表。先把受影響區域的父子順序說清楚，記錄為什麼需要這個層級，讓下一個維護者知道不能只改child。若多個元件確實共享層級約定，再把共同規則集中管理。
驗收要包含操作與相鄰內容
如果浮層只在動畫開始或結束時被蓋住，再檢查動畫期間的transform、opacity是否改變了情境。不要只核對靜止後的計算樣式，就排除動畫造成的關係變化。保留能重現的開關操作，觀察遮擋發生在哪一個時刻，再把對應的父層設定與靜止狀態比較。
對局部提示而言，也要確認關閉後沒有留下透明的命中區域。視覺上看不到，不代表元素不能擋住點擊；如果關閉只改透明度而仍參與命中，使用者可能點不到下方按鈕。按元件設計正確處理可見、命中和焦點，比單靠z-index把所有東西頂到最上層更完整。
調整後除了看面板能否出現，也要點它的按鈕、關閉它並走過鍵盤操作，確認焦點沒有被不相關覆蓋層擋住。再看相鄰區塊、導覽與不同容器尺寸，不要只截一張展開狀態就結束。
若遮擋來自第三方外掛，先辨識對應元素和樣式，再由負責維護的人確認調整範圍。理解父層情境後，在測試版型修好單一元件，再套到實際頁面，比較容易避免把新的遮擋問題帶到其他區域。
評論0