pointer-events: none 是必选项，因水印层默认拦截所有事件导致底层交互失效；需确保整个水印结构（含子节点）均应用该属性，Canvas 和 background-image 方案亦有各自透传与适配要点。
水印层遮挡点击：为什么 pointer-events: none 是必选项
水印层默认会拦截所有鼠标和触摸事件，底层按钮、输入框、链接全部失效——这不是 bug，是浏览器渲染层的正常行为。关键不是“要不要加水印”，而是“加了之后用户还能不能操作”。pointer-events: none 就是让该元素彻底退出事件捕获流，连 mouseover 都不会触发，底层 DOM 才能照常响应。
常见错误是只给水印容器设 pointer-events: none，但里面嵌套了按钮或文字节点；实际必须确保整个水印结构（包括所有子节点）都继承该行为，否则子元素仍可能抢事件。更稳妥的做法是直接在最外层水印 <div> 上声明，不依赖继承。
HarmonyOS 中的 hittestbehavior(hittestmode.transparent) 与 Web 的差异
HarmonyOS 的 hittestbehavior(hittestmode.transparent) 和 Web 的 pointer-events: none 功能等价，但机制不同：前者是声明式透传策略，后者是 CSS 渲染层开关。二者都不能解决“滚动穿透”问题——比如手指在水印层上滑动，底层页面不跟着滚。Web 端需额外对可滚动容器动态控制 pointer-events，而 HarmonyOS 目前不支持滚动事件透传的细粒度干预。
-
hittestmode.transparent只影响点击/长按类事件，不影响onTouch或手势识别 - 若水印组件内含
button或input，即使设了transparent，这些子控件仍会响应自身事件——必须单独禁用或移除 - Webview 内嵌页中叠加水印时，
hittestbehavior仅作用于 ArkTS 层，不影响 Webview 内部 DOM 的事件流
Canvas 水印的透传陷阱：为什么 pointer-events: none 不够用
Canvas 绘制的水印看似简单，但容易漏掉两个关键点：一是 canvas 元素本身默认 pointer-events: auto，必须显式设为 none；二是如果 canvas 被包裹在 position: fixed 容器里，该容器也得设 pointer-events: none，否则容器挡事件，canvas 再透明也没用。
立即学习“前端免费学习笔记（深入）”；
更隐蔽的问题是高分屏适配：canvas.width 和 canvas.height 必须乘以 window.devicePixelRatio，否则绘制区域缩放错位，导致部分区域未覆盖或重复覆盖，视觉上像“漏光”，实际是 canvas 像素画布没填满视口。
- 旋转文字时，必须先
ctx.translate()再ctx.rotate()，否则旋转中心在左上角，文字飞出屏幕不可见 - 用
ctx.fillText()绘制时，fillStyle推荐用rgba(0,0,0,0.1)，低于0.08基本不可见，高于0.15干扰阅读 - 监听
resize重绘 canvas，但不要监听scroll——fixed定位天然跟随滚动，额外计算反而引发抖动
background-image 水印为何最难被绕过
用 background-image 实现水印，本质是把水印塞进渲染管线底层，而非叠加 DOM 层。截图工具（包括浏览器自带“截取可见区域”）通常无法分离背景图层，所以防截图效果最强。但它也有硬约束：水印必须是带 alpha 通道的透明 PNG 或 base64 SVG，且 opacity 不能设在容器上——那会把整个背景（包括渐变、阴影）一起变淡。
真正起作用的是图片自身的透明度，background-attachment: fixed 必须加上，否则滚动时水印随文档流移动，“滑走”后露出干净空白区，失去覆盖感。平铺间距建议从 200px 200px 起调，太密加重 GPU 渲染压力，太疏则留白明显。
最后提醒一句：无论哪种方案，防篡改都极度有限。用户禁用 JS 后，所有动态生成的水印、MutationObserver 监听、canvas 绘制全部失效；而 background-image 方案虽难删，但开发者工具里清空 background-image 样式一行就搞定。真要防导出，得靠服务端 PDF 生成或 DRM 控制，前端水印只是第一道视觉提示。
