window.zoomlevel是唯一持久控制整个ui缩放的配置项，整数级最清晰；非整数易模糊，多屏需手动配置，被工作区设置或硬件加速参数覆盖时会失效。
window.zoomLevel 是唯一能持久控制整个 UI 缩放的配置项，改它才有效；Ctrl + +/- 和 Ctrl + 滚轮只是临时操作，关掉窗口就丢。
为什么改了 window.zoomLevel 没反应？
不是配置写错了，而是被更高优先级设置覆盖或渲染机制卡住了。
- 检查工作区
.vscode/settings.json是否也写了window.zoomLevel——它会压过用户级设置，删掉或统一修改 - 确认没加
--disable-hardware-acceleration启动参数，硬件加速关闭时缩放可能不触发 - Linux（尤其是 Wayland）下标题栏缩放支持弱，可试加启动参数：
code --force-device-scale-factor=1.25 - macOS 开启了“用粗体显示字体”系统选项时，缩放后文字发虚，容易误判为失效
window.zoomLevel 和 editor.fontSize 别混用
两者作用域完全不同：一个缩 UI 元素（菜单、侧边栏、状态栏），一个只调代码字体大小。混用会导致视觉割裂——比如菜单小得看不清，代码却大得占满屏幕。
-
window.zoomLevel默认是0（100%），每 ±1 ≈ 放缩 20%，支持小数但非整数易模糊（如0.5可行，0.55会被截断） -
editor.fontSize是绝对像素值，设成14就永远是 14px，和缩放无关 - 外接 4K 屏时典型组合：
"window.zoomLevel": 1（UI 放大） +"editor.fontSize": 14（代码字体按需微调）
多显示器 DPI 不一致时怎么处理
VSCode 不支持 per-display 缩放，拖到不同 DPI 屏上不会自动切换 window.zoomLevel，这是当前版本（1.118）的硬限制。
- 手动维护两套
settings.json配置，用符号链接或脚本切换（Windows 可用批处理 + 快捷方式参数启动） - 更底层稳定的方案是设
electron.zoomFactor（如"electron.zoomFactor": 1.25），它绕过 VSCode 层直接交由 Electron 处理，但启用后window.zoomLevel会被忽略，二者不可共存 - 某些插件（如 Custom CSS and JS Loader）或远程开发环境会干扰缩放行为，需单独验证
快捷键失效的常见原因
Ctrl + 鼠标滚轮 和 Ctrl + = / - 都该调 window.zoomLevel，但经常没反应，问题通常不在 VSCode 本身。
- 焦点在终端面板（Terminal）时，
Ctrl + 滚轮传给 shell 而非 VSCode 窗口 - macOS 触控板「缩放手势」开启时会劫持
Cmd + 双指捏合，需在系统偏好设置里关掉 - Logitech Options、Razer Synapse 等键盘驱动会全局拦截
Ctrl + 滚轮，临时退出软件可验证 -
editor.mouseWheelZoom控制的是代码字体缩放，和窗口缩放无关，名字容易混淆，确保它是false
真正难的不是怎么设，而是意识到 VSCode 的缩放模型是静态的：它不响应窗口尺寸变化，也不感知显示器 DPI 切换。所谓“自动适配”，目前只能靠外部脚本或手动干预补位。
