去年，我眼睜睜看著一個(gè)客戶把內(nèi)部儀表盤的截圖轉(zhuǎn)發(fā)給供應(yīng)商。截圖里是本該留在公司內(nèi)部的財(cái)務(wù)數(shù)據(jù)。沒人能證明是誰拍的。

如果屏幕上每個(gè)像素都帶著該用戶的郵箱或ID，以淡淡的斜線文字形式存在，我們五秒鐘就能知道答案。

這就是水印的核心邏輯：它不阻止泄露，它讓泄露可溯源。

最簡單的實(shí)現(xiàn)是在頁面頂部蓋一個(gè)

問題是：任何會(huì)按F12打開DevTools的人，兩下點(diǎn)擊就能刪掉這個(gè)

?；蛘吒采w它的CSS?；蛘咴谒∧_本運(yùn)行前就截圖。

這種天真方案只能防老實(shí)人。對真正想泄露的人毫無作用。

最后這點(diǎn)是大多數(shù)團(tuán)隊(duì)會(huì)忽略的，卻恰恰最重要。

我寫了watermark-shield，一個(gè)基于watermark-js-plus的小庫，后者處理canvas渲染做得很好。我在其之上加了：

1. 框架無關(guān)的核心，純JavaScript，帶Angular、React、Vue 3綁定

2. 整體gzip后約6KB，開啟DevTools防護(hù)時(shí)另有6KB懶加載代碼塊

安裝后直接調(diào)用：

你會(huì)得到：平鋪的用戶ID水印、主動(dòng)的DevTools檢測器、以及始終開啟的被動(dòng)防護(hù)。默認(rèn)配置合理，無需額外設(shè)置。

幾點(diǎn)值得注意的設(shè)計(jì)：

身份歸屬服務(wù)端。審計(jì)請求體里沒有userId。服務(wù)端從session cookie或JWT解析用戶身份，絕不信任客戶端發(fā)送的內(nèi)容。

DevTools檢測是多層的。代碼大小檢測、debugger陷阱、控制臺(tái)方法重寫——組合使用，沒有單點(diǎn)失效。

被動(dòng)防護(hù)始終運(yùn)行。即使檢測被繞過，MutationObserver也在監(jiān)視水印DOM。被刪？0.3秒內(nèi)重建。CSS被覆蓋？重新應(yīng)用。截屏快捷鍵？部分瀏覽器可攔截或混淆。

這不是安全邊界，是歸因機(jī)制。水印的存在本身就會(huì)改變行為——知道會(huì)被抓住的人，更可能先停下來。

技術(shù)債在這里：MutationObserver有性能開銷，我們節(jié)流到100ms批量處理；canvas渲染在4K屏上可能模糊，我們用devicePixelRatio縮放；字體加載延遲會(huì)導(dǎo)致首次渲染失敗，我們監(jiān)聽document.fonts.ready。

最有趣的反饋來自一家律所：他們在敏感文檔預(yù)覽頁部署后，內(nèi)部轉(zhuǎn)發(fā)截圖的行為下降了70%。不是技術(shù)阻止了泄露，是"會(huì)被發(fā)現(xiàn)"的預(yù)期阻止了嘗試。

代碼在GitHub，MIT協(xié)議。如果你也在處理類似的歸因問題，可以直接用，也可以拆走需要的部分。