widget.shadow 是唯一能控制悬停框阴影的颜色配置项，仅支持纯色值如 "#00000026"，不接受 box-shadow CSS 规则；VSCode 悬停提示框受 Shadow DOM 保护且自 1.84 起禁用样式注入，无法通过 CSS 自定义偏移、模糊等效果。
widget.shadow 是唯一能控制悬停框阴影的颜色配置项
VSCode 的悬停提示框（Tooltip）本身不支持自定义 box-shadow CSS 规则，也不接受任意 CSS 属性注入。它只暴露了一个主题色配置项：widget.shadow，用于设置整个悬停面板的阴影颜色（注意：是“颜色”，不是完整 shadow 值）。这个值必须是纯色，比如 "#00000026" 或 "rgba(0, 0, 0, 0.18)"，不能写成 "0 2px 8px rgba(0,0,0,0.15)" —— 后者会被完全忽略。
常见错误现象：
- 在
workbench.colorCustomizations中误写"widget.shadow": "box-shadow: ..."→ 无任何效果 - 试图用
vscode-custom-css注入.monaco-editor-hover相关选择器 → VSCode 1.84+ 已禁用该类 DOM 操作，样式不生效或被重置
实操建议：
- 只在
settings.json的workbench.colorCustomizations下配置："widget.shadow": "#0000001a"
- 该颜色会叠加在悬停框默认背景上，实际视觉深度受
widget.background和透明度共同影响 - 若想加圆角或内边距等效果，
widget.shadow无法实现——VSCode 不提供对应配置项
为什么不能像编辑器区域那样注入 CSS 阴影
悬停提示框由 VSCode 内部的 HoverWidget 组件渲染，其 DOM 节点（如 .monaco-editor-hover）被包裹在 Shadow DOM 或受严格样式隔离保护，且从 VSCode 1.84 开始，--enable-proposed-api 已不再允许插件修改这类核心 UI 组件的样式。即使你定位到正确选择器并写入 box-shadow，窗口重载后也会被清空或覆盖。
关键限制：
-
vscode-custom-css插件对.monaco-editor-hover、.hover-row等节点的样式注入，在当前版本（2026年10月）已失效 - 开发者工具中手动修改样式可临时看到效果，但刷新/切换文件后即丢失，无法持久化
- 语言服务器（如 Pylance、Volar）生成的悬停内容会动态插入 HTML 片段，其外层容器不受用户 CSS 控制
替代方案：靠配色 + 边框模拟“立体感”
既然无法改 shadow 偏移、模糊度或扩散，就只能通过组合其他颜色配置来逼近类似效果：
- 把
widget.background设为略带透明的深色（如"#1e1e1eee"），让阴影色更明显 - 用
widget.border加一道细边框（如"#333"），强化轮廓感 - 同步调整
editorHoverWidget.foreground和editorHoverWidget.background，避免文字发灰或对比不足 - 如果使用高对比度主题，
widget.shadow建议用更低透明度（如"#0000000a"），否则阴影会过重
示例片段（放入 workbench.colorCustomizations）：
{
"widget.shadow": "#00000012",
"widget.background": "#1e1e1eee",
"widget.border": "#2d2d2d"
}
容易被忽略的细节：不同悬停来源表现不一致
VSCode 的悬停提示有三类来源：编辑器原生 hover、语言服务器（LSP）提供、第三方扩展渲染。它们共享 widget.shadow，但渲染容器和层级不同：
- JS/TS 文件中函数悬停 → 使用
.monaco-editor-hover容器，受widget.*控制最稳定 - Python docstring 悬停 → Pylance 可能绕过部分 widget 配置，尤其在启用
pylance.hover.documentation时 - Tailwind CSS IntelliSense 的类名提示 → 完全走扩展自己的 DOM，
widget.shadow对它无效
验证是否生效最简单的方法：打开一个空的 .js 文件，写 /** */ 并悬停光标，观察提示框边缘是否有轻微晕染——那是 widget.shadow 唯一能表达的“阴影”。其他所有“立体感”都得靠背景、边框、字体权重协同完成。
